Matt का skill सोर्स खंगाला: अच्छा skill लिखने की चार लोहे की कसौटियाँ (और वह जगह जहाँ उसने caveman उड़ा दिया)

30 सेकंड में सार

भरोसेमंद skill लिखने का एक ही मक़सद है: predictability (अंदाज़े पर खरा उतरना) — एक ही हालत में AI हर बार एक ही flow चले। चारों कसौटियाँ इसी की सेवा में हैं, हर एक के साथ एक उल्टा उदाहरण:

trigger कैसे हो: model ख़ुद तय करे कि कब चलाना है (और इसकी क़ीमत में context घेरे), या सिर्फ़ तभी चले जब आप नाम लेकर बुलाएँ। ग़लत चुना = context बेकार घिरा।

डालें कितना: SKILL.md में सिर्फ़ वही रहे जो हर रास्ते पर काम आए, बाक़ी नीचे एक्सटर्नल लिंक में उतर जाए। उल्टा उदाहरण: sprawl, sediment।

शब्द कौन से: AI के दिमाग़ में पहले से मौजूद concept को leading word (पकड़ शब्द) बनाइए, एक शब्द एक पूरा व्यवहार खींच लाए। उल्टा उदाहरण: no-op, duplication।

समेटें कैसे: हर step का एक verifiable completion criterion (पूरा होने की कसौटी) हो। उल्टा उदाहरण: काम पूरा हुए बिना सरक जाना।

चारों Matt Pocock की writing-great-skills से; चारों उल्टे उदाहरण उसकी अपनी रिविज़न हिस्ट्री से निकाले असली केस।

मैंने Matt का पूरा skill सोर्स खंगाल डाला

एक ही / मारिए — कोई skill हर बार काम निपटा देता है, कोई कभी-कभी अटक जाता है। फ़र्क़ क़िस्मत का नहीं, लिखावट का है।

किसी के पास skill सोर्स खंगालने का वक़्त नहीं — मैंने आपके लिए खंगाल दिया। मेरी नज़र Matt Pocock पर थी, AI सहयोग के skill का पूरा सेट बनाने वाला। उसने एक बढ़िया चीज़ लिखी है: एक ऐसा skill जो सिर्फ़ यही सिखाता है कि अच्छा skill कैसे लिखें (writing-great-skills)। इसे, और उसके दर्जनों skill का सोर्स व commit इतिहास, साथ खंगालकर मैंने चार कसौटियाँ निकालीं।

चार ही, पर हर एक के साथ एक उल्टा उदाहरण लगाया है — और एक भी गढ़ा हुआ नहीं, सब Matt के अपने commit रिकॉर्ड से उठाया: ख़ुद की हुई ग़लती, ख़ुद से ठीक की। जब उसे तक पलटकर सुधारना पड़ा, तो समझ लीजिए ये गड्ढे असली हैं।

ये चार सीख लीजिए: ख़ुद skill लिखें तो कम ठोकर खाएँ; न लिखें, तो भी उसकी ‘रैंडम AI को तय बनाने’ वाली सोच चुरा लें।

अच्छे skill की एक ही कसौटी: predictability

model stochastic (रैंडम) है — एक ही बात दो बार पूछिए, जवाब एक जैसा हो ज़रूरी नहीं। skill का पूरा मतलब इसी रैंडम मशीन में से तय (determinism) निचोड़ना है: हर बार एक ही flow चलवाना।

“A skill exists to wrangle determinism out of a stochastic system.” — Matt, writing-great-skills

ध्यान दीजिए — flow, output नहीं। brainstorming हर बार अलग आइडिया फेंके यह ठीक है, पर खुलने का तरीक़ा स्थिर रहना चाहिए।

skill अच्छा है या बुरा, बस यही एक पैमाना है: predictability। नीचे की चारों कसौटियाँ इसी की सेवा में हैं।

कसौटी 1 · trigger कैसे हो: आप नाम लेकर बुलाएँ, या model ख़ुद तय करे?

skill लिखते वक़्त पहला फ़ैसला यही है: इसे model ख़ुद तय करके चलाए कि कब इस्तेमाल करना है, या सिर्फ़ तभी चले जब आप नाम लेकर बुलाएँ? तकनीकी तौर पर बस एक स्विच है — description लिखें या नहीं:

model-invoked (model ख़ुद चलाए, description के साथ): AI इसे ख़ुद पढ़ सकता है, ख़ुद तय करता है कब चलाना है। क़ीमत — यह description हर एक turn में context में टँगा रहता है, token खाता है, ध्यान खाता है। इसे कहते हैं context का बोझ।
user-invoked (आप नाम लेकर बुलाएँ, disable-model-invocation सेट): description हटा दिया जाता है, model को यह दिखता ही नहीं, सिर्फ़ आपके हाथ से नाम टाइप करने पर चलता है। AI का एक भी context नहीं खाता, क़ीमत आप पर आ जाती है: आपको ख़ुद याद रखना पड़ता है कि यह मौजूद है — यह दिमाग़ी बोझ है।

उसूल: सिर्फ़ तब model-invoked रखिए जब model (या कोई दूसरा skill) को इस तक ख़ुद पहुँचना ज़रूरी हो; वरना manual रखिए और मुफ़्त में शून्य context बोझ कमाइए।

उल्टा उदाहरण: एक ऐसा skill जिसे असल में आप हाथ से ही बुलाएँगे, फिर भी उसमें description पड़ा रहे और वह हर turn में आपका context बेकार घेरता रहे।

असली उदाहरण: यह ट्रेड-ऑफ़ Matt ने ख़ुद बार-बार तौला। grill-with-docs का disable-model-invocation स्विच उसने पहले हटा दिया — model को ख़ुद trigger करने की छूट दे दी; फिर ताज़ा वर्शन में उसे वापस जोड़ दिया, सीधा manual पर लौटा दिया। एक ही स्विच, हटाया भी, जोड़ा भी। यानी “auto या manual” सचमुच तौलने वाला फ़ैसला है, यूँ ही सेट कर देने की चीज़ नहीं।

ख़ुद इस्तेमाल: default में manual रखिए, पहले context बचाइए; सिर्फ़ तब description दीजिए जब आपको सचमुच चाहिए कि model ख़ुद भाँपे “अभी इसे चलाना है”। एक लाइन की जाँच: “इस skill तक किसे पहुँचना है?” जवाब “सिर्फ़ मुझे” — तो manual।

manual skill ज़्यादा जमा हो जाएँ तो आप ख़ुद याद नहीं रख पाते — यानी दिमाग़ी बोझ फट गया। इलाज: एक और routing skill लिखिए — एक manual skill जो बाक़ी skill गिनाए, बताए कब कौन-सा इस्तेमाल करना है। Matt का ask-matt यही करता है।

कसौटी 2 · डालें कितना: SKILL.md में सिर्फ़ “हर रास्ते पर काम आने वाला”

information ladder (जानकारी की सीढ़ी): जो हर इस्तेमाल-रास्ते पर काम आए वह SKILL.md के मुख्य हिस्से में; जो सिर्फ़ कुछ हालात में चाहिए उसे अलग एक्सटर्नल लिंक फ़ाइल में उतार दीजिए, मुख्य हिस्से में बस एक लाइन का पॉइंटर “ज़रूरत पड़े तो वहाँ देखिए”। मक़सद — ऊपरी परत हमेशा साफ़ रहे; चीज़ें ढेर हो जाएँ तो AI को जो असल में करना है वह दब जाता है।

उल्टे उदाहरण दो हैं, दोनों के नाम हैं:

sprawl (फैलाव): सब कुछ एक ही फ़ाइल में ठूँसते जाना, फ़ाइल लंबी होती जाए। हर लाइन सही भी हो, दोहराव भी न हो, तब भी निरा “लंबा” होना ही बीमारी है — AI को असल काम तक पहुँचने से पहले शब्दों के ढेर से गुज़रना पड़ता है।
sediment (तलछट): पुराना content सिर्फ़ जुड़ता जाए, हटता नहीं, परत-दर-परत जमता जाए, बाद वाले को archaeology की तरह खोदना पड़े तब कहीं जो अब भी काम का है वह मिले।

असली उदाहरण: grill-with-docs शुरू में एक मोटा monolith था — पूछताछ का तर्क, document का फ़ॉर्मैट, ADR का template, सब एक ही फ़ाइल में ठुँसे। Matt ने इसे तीन में बाँटा: पूछताछ वाला आधा अलग होकर grilling, document लिखने वाला आधा अलग होकर domain-modeling, और ADR व शब्दावली के फ़ॉर्मैट वाली फ़ाइलें भी domain-modeling में उतर गईं; grill-with-docs के पास बस एक लाइन का पतला खोल बचा जो दोनों को जोड़ देता है। यही है information ladder से फूले हुए skill का वज़न घटाना।

ख़ुद इस्तेमाल: लिखने के बाद पलटकर काटिए। हर लाइन से एक सवाल पूछिए “क्या यह हर रास्ते पर चाहिए?” नहीं — तो या तो एक्सटर्नल लिंक में उतारिए, या सीधे काट दीजिए। एक मोटा पर काम का अंदाज़ा — SKILL.md जितनी छोटी, जितनी सिर्फ़ मूल ढाँचे तक सिमटी, आम तौर पर उतनी ही भरोसेमंद।

कसौटी 3 · शब्द कौन से: AI के दिमाग़ में पहले से मौजूद concept उधार लीजिए

यह सबसे उल्टी समझ वाली है — मुझे ख़ुद देर तक माथापच्ची के बाद बात पल्ले पड़ी।

leading word (पकड़ शब्द): एक ऐसा तैयार concept जो AI ने training में पहले ही सीख रखा है, अपने साथ एक पूरा जुड़ाव लिए। सिर्फ़ तकनीकी शब्द ही नहीं — game, सेना, चिकित्सा, रोज़मर्रा के मुहावरे, सब चलते हैं, बस AI देखते ही समझ जाए। skill में लिख दीजिए, आपको समझाना नहीं पड़ता, वह वो पूरी की पूरी व्यवहार-शृंखला खींच लाता है।

उदाहरण (सब उधार के, एक भी Matt का गढ़ा नहीं):

fog of war (युद्ध का कोहरा, game/सेना से) → AI तुरंत समझता है “आगे साफ़ नहीं दिखता, हाथ की अधूरी जानकारी के भरोसे आगे बढ़ो”।
tracer bullets (ट्रेसर गोलियाँ, The Pragmatic Programmer से) → “पहले एक सबसे पतली end-to-end राह जोड़ो, दिशा पक्की करके फिर मसाला डालो”।
triage (छँटाई, अस्पताल की इमरजेंसी से), caveman (आदिमानव = कम बोलना), grilling (कस-कसकर पूछताछ) — तैयार concept उठाया और इस्तेमाल किया।

कहाँ ढूँढें: पहले जो व्यवहार चाहिए उसे साफ़ कहिए, फिर उल्टा पूछिए “कौन-सा तैयार शब्द या किस्सा ख़ुद ही इसी मतलब का है?” मुहावरों, मशहूर किताबों, methodology, game-सेना, चिकित्सा-खेल में ढूँढिए। AI ने जो पढ़ रखा है, वही आपकी शब्दावली है।

कैसे परखें — no-op टेस्ट: इस शब्द को अकेले लिख दीजिए, बिना समझाए, क्या AI वही कर देता है जो आप चाहते थे? कर दिया = असली leading word है, AI का पहले से जमा ज्ञान मुफ़्त में काम आ रहा है; और अगर आपको समझाना पड़े तभी समझे = वह कुछ कर ही नहीं रहा, उल्टे उदाहरण में गिर गया:

no-op (बेअसर लाइन): लिखी, पर AI वैसे भी वही करता। जैसे “be thorough (सावधानी से करो)” — AI default में थोड़ा सावधान रहता ही है, यह लाइन न लिखे जैसी है। इलाज समझाना नहीं, एक ज़्यादा कड़ा शब्द लाना है: “be thorough” → “relentless (पीछे पड़ जाने वाला)”।
duplication (दोहराव): एक ही बात कई जगह लिखी। रखरखाव भी महँगा (एक जगह बदलो तो हर जगह बदलना पड़े), और उस बात का वज़न AI की नज़र में ज़रूरत से ज़्यादा चढ़ा देती है।

असली उदाहरण: इन दोनों पर Matt ने सचमुच चाकू चलाया। उसने review skill कसा, commit नोट में साफ़ लिखा “single-sourced rules, no-op cuts” — दोहराई नियम एक जगह लाए, बेअसर लाइनें काटीं। उसने तो पलटकर ख़ुद writing-great-skills पर ही हाथ साफ़ किया, ख़ास तौर पर “no-op को वाक्य के स्तर तक खदेड़ा”।

ख़ुद इस्तेमाल: जो व्यवहार चाहिए उसे एक पूरे वाक्य से वर्णन मत कीजिए, एक तैयार शब्द ढूँढकर उससे काँटा डालिए; फिर हर विशेषण-क्रियाविशेषण उठाकर no-op टेस्ट कीजिए — इसे हटा दें तो AI का व्यवहार बदलेगा? न बदले, तो वह पानी है, काटिए।

कसौटी 4 · समेटें कैसे: हर step का एक verifiable completion criterion हो

skill अक्सर steps की एक शृंखला होती है। हर step सचमुच पूरा हुआ या नहीं, यह completion criterion (पूरा होने की कसौटी) से तय होता है।

अच्छी completion criterion में दो बातें होती हैं: एक, verifiable हो — AI objectively तय कर सके कि “हो गया” या “नहीं हुआ”, अंदाज़े से नहीं; दो, जहाँ ज़रूरी हो वहाँ exhaustive हो — जैसे “हर बदले हुए model का हिसाब देना है”, न कि धुँधला “बदलावों की एक लिस्ट बना दो”।

उल्टा उदाहरण · premature completion (वक़्त से पहले समेट लेना): completion criterion धुँधली रखी (“सहमति बन गई”, “समझ आ गया”), AI को एक साफ़ सीमा हाथ नहीं आती, और उसका ध्यान “काम निपटाने” से फिसलकर “जल्दी निपटा घोषित करने” पर चला जाता है, सचमुच पूरा हुए बिना अगले step पर सरक जाता है।

एक जुड़ी हुई बात भी है: AI को अगर दिख रहा हो कि आगे और कौन-कौन से steps क़तार में हैं, तो “जल्दी निपटाकर आगे बढ़ें” वाली खिंचाई और तेज़ हो जाती है। एक इलाज — आगे के steps को किसी दूसरे skill में छिपा दीजिए, इस step को आगे की राह की चिंता ही न हो।

असली उदाहरण: grilling (वही पूछताछ वाला आधा जो grill-with-docs से अलग हुआ) की पहचान वाला अंदाज़ यही है — एक-एक सवाल, आप एक का जवाब दें तभी अगला आए — इसका leading word ही “relentless (पीछे पड़ जाने वाला)” है। पूछताछ और document लिखना दो अलग skill में बाँटना भी इसी वजह से था: AI जब आपको कस रहा हो तो उसे यह न खटके कि “पूछ-पूछकर जल्दी document लिखने जाना है”, वरना वह कच्चा समेट देगा। अलग कर दीजिए, तो पूछताछ वाले step में सिर्फ़ पूछताछ बचती है।

ख़ुद इस्तेमाल: हर step की समेटने की शर्त को verifiable, और हो सके तो exhaustive लिखिए (“हर X को…”, न कि “बस लगभग हो गया”); और अगर देखें कि AI किसी step पर बार-बार दौड़ पड़ता है, तो आगे के steps किसी दूसरे skill में सरका दीजिए।

इन चार से एक अजीब बात देखिए: उसने caveman क्यों हटाया?

इन चार को लेकर एक असली घटनास्थल पर चलते हैं।

हमारी पहली कड़ी वाला caveman (AI को चुप करवाकर सिर्फ़ मतलब की बात कहलवाना) अब Matt की मूल repo में मिलता ही नहीं — हटा दिया गया। हटाने का रिकॉर्ड सीधा-सादा है:

मई के आख़िर में, उसने पूरी caveman SKILL.md हटा दी, commit नोट बस इतना — “productivity skill को streamline किया”।
आधे महीने बाद, README और plugin लिस्ट में बचे हवाले भी साफ़ कर दिए।
कोई नया skill उसकी जगह लेने नहीं आया। सीधे हटा दिया।

क्यों? चार से नापते ही समझ आ जाता है: caveman एक manual skill है, यह आपका दिमाग़ी बोझ घेरता है — आपको याद रखना पड़ता है कि यह मौजूद है। पर जो ज़रा-सा काम यह करता है (कम बोलना, औपचारिकता हटाना) वह एक instruction से, या एक global output style से, माँगा जा सकता है, इसके लिए “एक जिसे आपको याद रखना पड़े” वाला अलग ख़ाना घेरना घाटे का सौदा है। इसे हटाना दरअसल पूरे skill सेट के स्तर पर छँटाई है, बेफ़ायदा बोझ काटना।

एक बात साफ़ कर दूँ: Matt के commit नोट में बस “streamline” लिखा था, खोलकर कुछ नहीं — यह इस framework से की हुई मेरी व्याख्या है। पर framework एक अपने-आप में पूरी उतरने वाली व्याख्या दे देता है — और यही तो इसका फ़ायदा है।

ये चार सिर्फ़ skill लिखने की चेकलिस्ट नहीं, ये असल दुनिया में किसी skill के जीने और मरने की वजह भी समझा देते हैं।

झटपट कार्ड

कसौटी	क्या करें	उल्टा उदाहरण	एक लाइन की जाँच
trigger कैसे हो	description सिर्फ़ तब जब model को ख़ुद पहुँचना हो, वरना manual	context बेकार घिरा	”इस skill तक किसे पहुँचना है?”
डालें कितना	SKILL.md में सिर्फ़ हर रास्ते पर ज़रूरी, बाक़ी एक्सटर्नल लिंक में उतारें	sprawl / sediment	”क्या यह लाइन हर रास्ते पर चाहिए?”
शब्द कौन से	AI का तैयार concept leading word बनाएँ, एक शब्द एक व्यवहार खींचे	no-op / duplication	”यह लाइन हटा दें तो AI बदलेगा?”
समेटें कैसे	हर step का verifiable, हो सके तो exhaustive completion criterion	premature completion	”यह step हुआ या नहीं, AI objectively तय कर सकता है?”

एकमात्र कसौटी: predictability — एक ही हालत में AI हर बार एक ही flow चले। चारों इसी की सेवा में हैं।

आख़िर में

चार बातें, skill लिखें तो सीधे इन्हीं पर चलिए। और अगर ज़िंदगी भर skill लिखना ही न हो, तब भी पीछे की वह सोच — “रैंडम AI को तय कैसे बनाएँ” — आपको रोज़मर्रा का AI और स्थिर ढंग से चलाने देती है। आख़िरकार उस्ताद से चुराने का असली फ़ायदा यही है: आपके हाथ कुछ नियम नहीं, उसके दिमाग़ की वह परख आती है।

सोर्स: यह लेख Matt Pocock की writing-great-skills (और उसकी GLOSSARY.md) को खोलता है, repo mattpocock/skills, MIT लाइसेंस, वर्शन 6eeb81b। लेख के “असली केस” सब इसी repo के commit इतिहास में जाँचे जा सकते हैं (commit लिंक साथ लगे हैं)।

इसी सीरीज़ में: पहली कड़ी · caveman · दूसरी कड़ी · grill-with-docs