10 घंटे वाला Skill हमेशा 10 मिनट वाले को हरा देता है

मुझे लगता था कि Skill लिखना मतलब एक SKILL.md फाइल किसी फोल्डर में डालो और काम खत्म। दस मिनट, हो गया। यह तब तक ठीक चलता रहा जब तक मैंने देखा कि हर invocation में वही गलतियां दोहराई जा रही हैं — और मेरे पास यह जांचने का कोई तरीका नहीं था कि Skill वाकई वो कर रहा है जो मैं चाहता हूं।

फिर Thariq, जो Anthropic में Claude Code बनाने वाले engineers में से एक हैं, ने कुछ ऐसा लिखा जिसने पूरी सोच पलट दी: “Skills को ठीक से इस्तेमाल करना खुद एक skill है।”

यह लाइन दिमाग में अटक गई क्योंकि यह बिल्कुल वही था जो मैं देख रहा था। एक जल्दी बनाई markdown फाइल और एक ठीक से structured Skill folder के बीच का फर्क असली output quality में दिख रहा था — सिर्फ theory में नहीं।

Skill एक फाइल नहीं, एक फोल्डर है

सबसे आम गलतफहमी यह है कि Skill मतलब एक SKILL.md फाइल। असल में, Skill एक ऐसा फोल्डर होता है जिसमें scripts, reference code, configuration, और वो markdown फाइल होती है जो सबको आपस में जोड़ती है।

Anthropic का internal approach जिसे वो “progressive disclosure” कहते हैं, उस पर काम करता है। सब कुछ एक ही prompt में ठूंसने की बजाय, files को इस तरह arrange किया जाता है कि Claude सिर्फ वही पढ़े जो उसे उस वक्त चाहिए। एक references/api.md फाइल में function signatures होते हैं जिन्हें Claude जरूरत पड़ने पर pull करता है। एक assets/ directory में output templates होते हैं ताकि prompt में formatting describe न करनी पड़े। Validation scripts Claude को allow करते हैं कि वो अपना output return करने से पहले खुद test कर सके।

skill-creator repo खोलें तो यह principle action में दिखता है। agents/, references/, और scripts/ directories SKILL.md के साथ-साथ रखे जाते हैं। Skills बनाने वाला tool खुद एक Skill के रूप में बनाया गया है।

Gotchas, prompt body से ज़्यादा ज़रूरी हैं

Thariq ने Gotchas section को Skill का “highest-signal content” कहा। Main instructions नहीं, examples नहीं। Gotchas।

यह मेरे अनुभव से मेल खाता है। मैंने एक Skill बिना Gotchas section के बनाई और एक ही error तीन बार लगातार मिली। जैसे ही मैंने उस specific failure pattern को document करने वाली एक लाइन add की, वो error बंद हो गई।

इसकी वजह सीधी है। Claude वो ज़्यादातर बातें पहले से जानता है जो आप prompt body में लिखेंगे। उसे बताना कि TypeScript कैसे लिखते हैं या JSON कैसे format करते हैं — यह वो चीजें हैं जो वो by default अच्छे से handle करता है। लेकिन यह बताना कि आपके specific context में क्या नहीं करना है — यह genuinely नई information है।

Thariq के post से कुछ principles जो मुझे reliable लगे हैं: obvious बातें मत लिखो क्योंकि redundant instructions actually performance खराब कर सकती हैं; overly specific steps से Claude को railroad मत करो क्योंकि इससे उसकी adapt करने की क्षमता खत्म होती है; और याद रखो कि description field humans के लिए documentation नहीं है, यह वो input है जिससे Claude decide करता है कि Skill कब trigger करनी है।

Skill Creator “शायद काम कर रहा है” को “verified” में बदलता है

Skill Creator का दो हफ्ते पहले का update मेरी Skill quality के बारे में सोचने का तरीका बदल गया। आप test prompts define करते हो, expected outcomes set करते हो, और tool verify करता है कि Skill actually सही results दे रही है या नहीं। यह prompts के लिए unit testing है।

मैंने एक Skill जो हफ्तों से use कर रहा था उसमें evals add किए। दो test cases जिनके बारे में मुझे लगता था कि pass होंगे, immediately fail हो गए। fixes छोटे थे, लेकिन उन्हें apply करते ही output quality में साफ फर्क दिखा।

दो तरह की Skills के बीच एक useful distinction है। Capability uplift Skills Claude को वो कुछ सिखाती हैं जो वो अकेले अच्छे से नहीं कर सकता। Encoded preference Skills किसी team के specific workflow या standards को enforce करती हैं। पहले type की एक natural expiration date होती है क्योंकि model improvements eventually उसे unnecessary बना देते हैं। दूसरे type की value तब तक बनी रहती है जब तक workflow exist करता है। Evals आपको वो moment पकड़ने में मदद करते हैं जब capability uplift Skill dead weight बन जाती है।

Tooling में benchmark mode है pass rates और token usage को model updates के across track करने के लिए, testing के दौरान context contamination avoid करने के लिए multi-agent parallel execution, और एक comparator agent जो Skill के साथ और बिना Skill के output के blind A/B comparisons करता है।

Compound return

सैकड़ों Skills जो मैंने देखी हैं और दर्जनों जो मैं maintain करता हूं, उनमें एक pattern हमेशा दिखता है: Skill की value iteration से आती है, initial draft से नहीं।

Folder structure यह है कि आप Claude की context window को कैसे shape करते हो। Gotchas आपकी failures को reusable knowledge में convert करते हैं। Evals measure करते हैं कि वो knowledge अभी भी काम कर रही है या नहीं।

एक SKILL.md लिखने में दस मिनट लगते हैं। Real failures से Gotchas add करने, eval cases बनाने, और validation scripts include करने में करीब दस घंटे लगते हैं। यह investment हर बार pay back होती है जब Skill run होती है। आज रात एक setup करें। सुबह तक वो वो काम कर चुकी होगी जो आपको नहीं करना पड़ा।