Learning Opportunities - Claude Code और Codex में जानबूझकर skill development में मदद करने वाला स्किल

• agentic coding करते समय सिर्फ प्रोजेक्ट ही नहीं, बल्कि यूज़र की विशेषज्ञता बढ़ाने में मदद करने वाला Claude Code और Codex के लिए एक skill
• नई फ़ाइल बनाना, schema बदलना, refactoring जैसे architecture tasks पूरे होने के बाद Claude 10–15 मिनट के वैकल्पिक learning exercises सुझाता है
• ये exercises prediction, generation, retrieval practice, spaced repetition जैसी learning science तकनीकों का उपयोग करते हैं और यूज़र के वास्तविक प्रोजेक्ट कार्य से आधे-हल किए हुए उदाहरण बनाते हैं
• इसे इस तरह डिज़ाइन किया गया है कि AI coding tools के कारण होने वाली generated code acceptance, fluency illusion, लंबे समय तक लगातार काम, metacognition की कमी, और self-testing में कमी जैसी समस्याओं को कम किया जा सके
• Claude, “क्या हम इस विषय पर एक छोटा learning exercise करें? इसमें लगभग 10–15 मिनट लगेंगे” जैसी शैली में पूछता है, और यूज़र की सहमति पर interactive exercise चलाता है
• मुख्य design principle यह है कि Claude अपने ही सवालों का जवाब नहीं देता और यूज़र इनपुट का इंतज़ार करता है, ताकि तेज़ agentic coding से अलग reflection और exploration का मोड बनाया जा सके
• exercise types में prediction→observation→reflection, generation→comparison, execution path tracing, debugging prediction, नए developer को समझाना, और पिछले sessions की retrieval check शामिल हैं
• फिलहाल सुझाई गई suppression conditions यह हैं कि अगर एक session में exercise पहले ही ठुकरा दिया गया हो, या उसी session में 2 बार exercise पूरी हो चुकी हो, तो learning opportunity दोबारा न सुझाई जाए
• Codex में इसे codex plugin marketplace add https://github.com/DrCatHicks/learning-opportunities.git से marketplace में जोड़ा जा सकता है, और इसमें learning-opportunities, learning-opportunities-auto, orient शामिल हैं
• Claude Code में इसे Claude Code plugin marketplace के ज़रिए जोड़ने के बाद /plugin install learning-opportunities@learning-opportunities से install करके restart के बाद activate किया जाता है
• learning-opportunities-auto Linux और macOS पर git commit के बाद Claude को exercise suggestion पर विचार करने देने वाला एक optional hook है, और Windows पर भी अतिरिक्त सेटअप के साथ इस्तेमाल किया जा सकता है
• orient skill नया repository सीखते समय orientation.md बनाता है, और program understanding तथा codebase navigation research पर आधारित recommended lessons देता है
• इसे Learning-Goal के साथ उपयोग करना अच्छा बताया गया है; इस skill का परिचय MCII तकनीक के ज़रिए अर्ध-संरचित interactive learning goal setting में मदद करने वाले रूप में दिया गया है
• team experiments के लिए MEASURE-THIS.md भी साथ इस्तेमाल किया जा सकता है, जो validated survey items, result interpretation guide, leadership sharing के लिए “team boast” template, और Claude.md statistical rigor nudges प्रदान करता है
• यह Creative Commons Attribution 4.0 International License के तहत लाइसेंस प्राप्त है

[GN⁺]

Hacker News राय

• मुझे Skills के बारे में ज़्यादा नहीं पता, लेकिन repository देखकर लगा कि commit के बाद चलने वाली bash script के अंदर एक छोटे prompt की तुलना में सजावटी code और text काफ़ी ज़्यादा है
  असल बात लगभग यह है कि user ने अभी commit किया है, इसलिए अगर नई file, schema change, architecture decision, refactoring, या कोई अनजान pattern है तो 10~15 मिनट की learning exercise सुझाओ

  • Skills दोहराए जा सकने वाले workflow को standard तरीके से describe करने, progressive disclosure से context बचाने, prompt share करने, और कम इस्तेमाल होने वाले लेकिन non-deterministic हिस्सों को script जैसी deterministic procedure में बाँधने में उपयोगी हैं
    अवधारणात्मक रूप से इसे किसी और का बनाया जादू लाकर इस्तेमाल करना नहीं, बल्कि धीरे-धीरे बढ़ने वाला software समझना चाहिए https://alexhans.github.io/posts/series/evals/building-agent...
    coding harness में अक्सर SkillBuilder agent skill होता है, इसलिए इन्हें बनाना आसान है और लगातार विकसित भी किया जा सकता है
    अपनी परेशानी के हिसाब से खुद बनाने की सलाह दूँगा, और evaluation के ज़रिए automation की accuracy काफ़ी बढ़ाने वाला एक simple example भी है https://alexhans.github.io/posts/series/evals/sketch-to-text...
  • ऐसे ज़्यादातर tools आखिरकार prompt में जोड़ी जाने वाली एक और Markdown file ही होते हैं, और large language model के काम करने के तरीके को देखते हुए यह सामान्य संरचना है
    इसलिए मैं यह सलाह देना चाहूँगा कि Claude से अपना ऐसा ही tool खुद बनवाओ। शुरुआत में tokens खर्च होंगे, लेकिन बाद में अपने tool से किसी meaningful काम के लिए ज़रूरी tokens और calls काफ़ी कम किए जा सकते हैं
    tool calls को ज़्यादा safely lock भी किया जा सकता है, agent के काम को retryable बनाया जा सकता है, और failure modes भी कम किए जा सकते हैं। अगर काम के दौरान laptop बंद हो जाए, तो agent कहाँ तक पहुँचा था यह फिर से reconstruct करने में बहुत tokens जलाने वाली स्थिति से भी बचा जा सकता है

• यह देखकर हैरानी हुई कि कुछ Skills में न तो सटीक procedure लिखा है, न क्या करना है, बस किसी खास काम में model से बेहतर text निकलवाने के लिए motivational speech जैसा priming ही है
  Claude का frontend design skill भी लगभग बस इतना कहता है कि अच्छे fonts चुनो और design को consistent रखो; कौन-से fonts हों या color palette और layout कैसे बने, इस पर कोई specificity नहीं है
  https://github.com/anthropics/claude-code/blob/main/plugins/...

• code-writing agents से iterative debt पैदा हो सकता है। अगर coding assistant का output सही है या नहीं यह जाँचे बिना स्वीकार करते रहो, तो अपने codebase की समझ खोने लगते हो
  CLAUDE.md जैसी context files, migration protocol, और auth protocol तभी ठीक चलते हैं जब आप उन्हें सही तरह update करने लायक पर्याप्त समझ रखते हों
  ऐसा हुआ है कि agent के लिखे code को दो घंटे तक आँख बंद करके स्वीकार करता रहा, फिर codebase कैसे काम करता है यह इतना भूल गया कि नई context file ही नहीं बना पाया। ऐसी skill debt diff में दिखती नहीं, लेकिन जब agent को lead करना होता है तब सामने आती है

  • iterative से ज़्यादा recursive कहना सही नहीं होगा?
    बड़े feature change के समय, agent से code लिखवाने से पहले chat में जिस business domain problem को solve करना है उस पर सहमति बना लेना बेहतर है। यह कुछ वैसा है जैसे किसी outsourced dev shop के contact के साथ बैठकर अपनी ज़रूरतें साफ़ करना
    उसके बाद agent के साथ hierarchical bullets वाला design document एक असली .md file के रूप में लिखो, जहाँ ज़्यादातर generation और edits agent करे, लेकिन problems और ambiguous decisions को बारीकी से परखो ताकि design-level decisions यहीं पहले खत्म हो जाएँ
    फिर design spec को BDD spec test bundle के skeleton में बदलने को कहो, और implementation के दौरान उसे भरने दो
    implementation phase में unit tests और integration tests जोड़े, बदले, या हटाए जा सकते हैं, लेकिन design spec file और उससे निकली BDD test structure fix रहनी चाहिए। पूरा होने से पहले BDD tests label के मुताबिक logic से भरे होने चाहिए और सब pass भी करने चाहिए
    अगर project बहुत बड़ा हो, तो नए business requirement definition, design revision, और BDD bundle addition जैसे steps को दोहराने वाले sprint चलाए जा सकते हैं। या फिर step 2 और 3 के बीच design को milestones में बाँटकर सिर्फ current milestone के लिए BDD items बनवाकर solve कराया जा सकता है
    आखिर में बात यह है कि LLM पर waterfall approach लागू करो। अगर पूरी process एक घंटे के अंदर पूरी हो सकती है, तो waterfall भी काफ़ी आरामदायक हो सकता है
    मुख्य बात यह है कि project या milestone खत्म होने के बाद agent से chat में उसके लिखे code की व्याख्या कराओ, लेकिन उसे कहो कि जो बातें design में पहले से साफ़ थीं उन्हें explain न करे
    फिर हैरान करने वाले हिस्सों की व्याख्या को code comments में बदला जा सकता है, और नतीजा formal कचरा comments नहीं बल्कि ऐसे comments होते हैं जैसे कोई इंसान लिखे

• benchmark और evaluation के बिना यह कैसे पता चले कि यह /create-skill से बेहतर नतीजे देता है? naive test से भरोसा नहीं बनता

  • शायद यहाँ बात इंसान की skill development की हो रही है। यह user को learning opportunities देने वाली feature है
    इसमें कहा गया है कि architecture वाला काम खत्म होने पर Claude evidence-based learning science पर आधारित optional 10~15 मिनट की exercises सुझाता है। इसमें prediction, generation, retrieval practice, और spaced repetition जैसी techniques से अपने project work से आधे-अधूरे examples दिए जाते हैं
    नाम थोड़ा confusing है
  • लगता है LLM में इतने डूब गए हैं कि जुड़े हुए terms दिखते ही Pavlovian reaction निकल आती है
  • evaluation की बात उठाना अच्छा है, लेकिन अभी जानना चाहता हूँ कि आप क्या इस्तेमाल कर रहे हैं या क्या ढूँढ रहे हैं। क्या खुद बना रहे हैं, या कोई existing evaluation framework इस्तेमाल कर रहे हैं?

• जो लोग अभी तक इस rabbit hole में नहीं उतरे, उनके लिए: Skills ऐसी structured Markdown files हैं जो बताती हैं कि किसी narrow-scope task को कैसे handle करना है
  उदाहरण के लिए, अगर आप API endpoint किसी खास तरीके से लिखते हैं, तो वह procedure skill में लिख सकते हैं। बाद में अगर agent को लगे कि यह skill मौजूदा chat context से relevant है, तो वह इसे load करके दिए गए निर्देशों के अनुसार काम करेगा
  यह tool call जैसा है, लेकिन callable function नहीं, बल्कि उस “skill” को करने के लिए instructions हैं
  कम-से-कम जिस Cline का मैं इस्तेमाल करता हूँ, उसमें Skills को global या project-level local रूप में define किया जा सकता है

  • Skills में frontmatter नाम का header भी होता है, और उसका कुछ हिस्सा CLAUDE.md file की तरह context की शुरुआत में share होता है
    जैसा मैंने सुना है, skill load context पर अलग असर डाल सकता है, जैसे compression के बाद भी उसका असर बना रहना
    कई skills load हों तो वे session में permanently loaded जैसी स्थिति में रह सकती हैं
    मुझे लगता है यह subagent के साथ अच्छी तरह फिट बैठता है। अगर subagent कोई skill load करके काम पूरा करे और सिर्फ result दे, तो orchestrator agent को उसका पूरा विवरण जानने की ज़रूरत नहीं होती

• adaptive dynamic textbook approach असल में क्या है, यह साफ़ नहीं है। एक example चाहिए
  generated code को बस स्वीकार करते रहना और खुद कम code लिखना, जिससे समझ बनाने वाली active processing छूट जाती है — यह बात सच में सही लगती है

• समझ नहीं आता कि लोग इतनी शानदार idea बनाते हैं और फिर demo या sample output का link न देकर यह अतिरिक्त मेहनत क्यों करते हैं। HN पर यह रोज़ दिखने वाला pattern है
  क्या यह देखने का एकमात्र तरीका कि यह skill सच में कैसा दिखता है, इसे खुद download करके चलाना है? मेरा ऐसा करने का मन नहीं है

  • अभी skill usage, AGENTS.md में साफ़ instructions की तुलना में, काफ़ी कम reliable लगता है
    यह idea समझ में आता है कि जब relevant न हो तो skill add न करके context bloat से बचा जाए, लेकिन अगर AGENTS.md में explicit instruction न हो तो agent skill इस्तेमाल करेगा इसकी कोई guarantee नहीं। तब यह बस किसी referenced Markdown file से बहुत अलग नहीं रह जाता
    https://www.agentkanban.io बनाते हुए, जो GitHub Copilot integration वाला work board है, मैंने यह बहुत experiment किया कि instructions कहाँ रखी जाएँ
    AGENTS.md से एक level नीचे की structure काफ़ी अच्छी चली। task-specific IDs agent reliably उठा सके, इसके लिए मैंने tool-managed file के अंदर INSTRUCTION.md रखने का तरीका अपनाया, और इससे AGENTS.md का pollution भी कम हुआ
    Skills पर भी experiment किया, लेकिन वे बहुत बार skip हो जाते थे, इसलिए मौजूदा तरीके जितना reliably tool को चलाना मुश्किल था
  • SKILL.md तो वहीं है, बस उसे पढ़ लो, उससे पता चल जाएगा कि वह क्या करता है

• idea सच में बहुत पसंद आया। मैंने Claude से open source textbooks और docs का इस्तेमाल करके मौके पर textbook बनवाई है
  जानना चाहता हूँ कि क्या इस skill को ज़्यादा सामान्य learning और application domain तक बढ़ाया जा सकता है, या यह code के लिए ही specialized है

• यहाँ की प्रतिक्रियाएँ दिलचस्प हैं, लेकिन लगता है ज़्यादातर लोग असली point miss कर रहे हैं
  मेरे लिए बड़ा takeaway यह है कि दूसरे लोग Skills का इस्तेमाल कैसे करते हैं इसे देखकर सीखा जाए। कल मैं Matt Pocock की agent-usage class देख रहा था, जहाँ उन्होंने product requirements document को evolve करने के लिए “grill-me” skill जैसा example दिखाया
  मैं वह ठीक उसी तरह नहीं करूँगा, लेकिन requirements बनाने और implement करने के तरीके को लेकर मुझे अपने ideas मिले
  Anthropic engineers के शब्दों में, Claude एक talented engineer जैसा है लेकिन उसमें deep expertise की कमी है। Skills वे folders और files हैं जिनसे expertise तैयार की जाती है
  Pocock से सीखी एक और बात यह थी कि context या token size जितना लंबा होता है, responses उतने ही dumb होने लगते हैं। इसलिए Skills, problem को LLM के सामने compressed form में पेश करके optimized response पाने का एक और तरीका हैं
  Claude में behavioral traits भी हैं। अगर कोई बार-बार skill बनाता है, तो बहुत संभव है कि वह दूसरे users पर अच्छी तरह transfer न हो। क्योंकि हर व्यक्ति Claude से अलग तरीके से बात करता है
  इसलिए मैं अपनी skill folder को coworkers के साथ share करने में हिचकता हूँ। उसकी जगह मैं जो बनाया है उसे demo के रूप में दिखाऊँगा, ताकि लोग संभावनाएँ देखें और फिर अपना workflow खुद खोजें
  असली value इस बात में है कि दूसरे लोग Claude से चीज़ें कैसे बनवाते हैं, यह देखकर फिर उसे अपने तरीके से imitate करना। यह वैसा ही है जैसे शुरू में programming सीखते समय Kernighan और Ritchie की C book से code टाइप करके, उसे समझने के लिए बदलना, और बाद में अपने उद्देश्य के अनुसार उसे ढालना
  behavioral traits का ज़िक्र इसलिए भी किया, क्योंकि author psychologist है, इसलिए Claude के साथ interaction का उनका तरीका programmers से काफ़ी अलग हो सकता है — यह दिलचस्प है
  इसी संदर्भ में, मैंने सुना कि author और अलग-अलग domains के कई experts बहुत पहले Twitter छोड़ चुके हैं, इसलिए मैं bsky या Mastodon सेट करके उन्हें follow करने की सोच रहा हूँ। मुझे लगता है यह देखना ज़रूरी है कि expert लेकिन non-programmer लोग LLM का इस्तेमाल कैसे करते हैं

• idea अच्छा लगा, इसलिए आज सुबह मैंने इसे थोड़ा explore किया
  AI का बहुत ज़्यादा इस्तेमाल करते-करते मुझे सचमुच brain drain जैसा एहसास हुआ है, और यह पूरी तरह का समाधान तो नहीं है, लेकिन मेरा मानना है कि रोज़ कुछ exercises कर लेना भी काफ़ी मददगार हो सकता है