grill-with-docs का इस्तेमाल कैसे करें — AI को सिर हिलाना बंद करवाकर पहले आपका प्लान कसवाएँ

30 सेकंड में सार · पूरा पढ़ने का वक़्त नहीं? बस इतना पकड़ लीजिए

दिक़्क़त: AI ज़रूरत से ज़्यादा हाँ-में-हाँ मिलाता है। अधपका प्लान थमाइए → वह कोड लिख देता है → आपकी उलझन प्रोजेक्ट के साथ शिप हो जाती है।

grill-with-docs उल्टा करता है: यह आपको कसता है। आपके प्रोजेक्ट की CONTEXT.md glossary + सोर्स लेकर आपके प्लान में एक-एक करके छेद ढूँढता है।

कैसे कसता है: एक बार में एक सवाल, पहले सुझाया हुआ जवाब; जो कोड से पता चल सके वहाँ पूछता नहीं; शब्द तय हुआ → CONTEXT.md में; मुश्किल से पलटने वाला फ़ैसला → एक ADR।

लगाना: npx skills@latest add mattpocock/skills · इस्तेमाल: “grill-with-docs से मेरा प्लान कसो: <प्लान>”

सबसे अच्छा कब: किसी पके हुए प्रोजेक्ट में कोई पेचीदा फ़ीचर जोड़ना, जहाँ कुछ शब्दों के मतलब अलग-अलग लोगों के लिए अलग हैं। मत करिए: ख़ाली repo / मामूली बदलाव / यह उम्मीद कि कोड वही लिख देगा।

1. हाँ-में-हाँ मिलाने वाला AI एक छिपा हुआ ख़तरा है

AI के साथ pair करके कोड लिखने में सबसे ख़तरनाक बात यह है कि वह लगभग कभी पलटकर नहीं बोलता।

आप उसे एक अधपका प्लान फेंकते हैं — “एक फ़ीचर जोड़ो: यूज़र किसी ऑर्डर में से कुछ आइटम कैंसिल कर पाए, फिर उनका रिफ़ंड मिल जाए” — और वह पलक तक नहीं झपकाता: “बिलकुल!” और कोड बहने लगता है। पर उस एक वाक्य में बहुत कुछ है जो आपने तय ही नहीं किया था, और उसने एक भी बात नहीं पूछी: “कैंसिल” शिपिंग से पहले या बाद? रिफ़ंड किसकी ज़िम्मेदारी है? यह वही चीज़ है जिसे आपका codebase पहले से cancellation कहता है, या कुछ और? वह पूछता नहीं। वह आपकी जगह मान लेता है, और उन धारणाओं को कोड में पक्का कर देता है।

तीन हफ़्ते बाद पता चलता है कि वही एक शब्द — “कैंसिल” — product के लिए कुछ और है, कोड के लिए कुछ और, और database के लिए कुछ और। codebase खिचड़ी बन चुका है।

बात यह नहीं कि AI समझदार नहीं है। बात यह है कि वह मदद करने को इतना बेताब है कि रुककर आपसे सोचवाता ही नहीं।

grill-with-docs उल्टा करता है: AI को सिर हिलाना बंद करवाता है और पहले आपका प्लान कसता है (grill का मतलब है आँच पर रखकर भूनना, यानी कस-कसकर पूछताछ करना)। शब्द धार पर आने तक आप आगे नहीं बढ़ते।

2. यह कैसे काम करता है: एक इंटरव्यू जिसे आपका प्रोजेक्ट याद है

तंत्र एक लाइन में: यह आपके प्रोजेक्ट की अपनी भाषा और फ़ैसलों से आपके नए प्लान को कसता है।

कुछ ख़ास बातें (लेखक ने इस व्यवहार को दो skill में बाँट दिया है — grilling और domain-modeling — आगे इस पर बात):

एक बार में एक सवाल, पहले सुझाया हुआ जवाब। यह आपके प्लान के फ़ैसलों के पेड़ पर शाखा-दर-शाखा चलता है, और हर सवाल की शुरुआत में बताता है “मैं तो यह चुनूँगा, क्योंकि…” — आपके आगे बीस सवालों की लिस्ट पटक देने के बजाय।

जो कोड से पता चल जाए, वह नहीं पूछता। जो जवाब सोर्स पर एक नज़र से मिल जाए, वह ख़ुद देख लेता है, आपको परेशान नहीं करता।

यह आपको glossary पर बाँधे रखता है। आपके प्रोजेक्ट की जड़ में पड़ी वह CONTEXT.md ही उसका पैमाना है। कोई ऐसा शब्द बोलिए जो परिभाषा से मेल न खाए, और वह तुरंत रोक देगा: “glossary कहती है ‘void’ का मतलब X है, पर आप साफ़-साफ़ Y कह रहे हैं — कौन सा?”

धुँधले शब्द धार पर लाता है। आप “account” कहिए, और वह पूछेगा: “Customer की बात कर रहे हैं या User की? ये दो अलग चीज़ें हैं।”

यह कोड से मिलान करता है। आप कहें कि फ़ीचर एक ख़ास तरीके से चलता है, तो वह कोड पढ़कर जाँचता है; मेल न खाए तो टोक देता है: “कोड पूरा ऑर्डर void करता है, पर आपने अभी कहा कुछ हिस्सा — कौन सा सही है?”

कोई शब्द तय हुआ, तो सीधे CONTEXT.md में चला जाता है। न जमा करना, न “बाद में”।

सिर्फ़ मुश्किल से पलटने वाला फ़ैसला ही एक ADR पाता है। यह ADR (architecture decision record, यानी आर्किटेक्चर फ़ैसले की लिखत) देने में कंजूस है: यह तभी एक प्रस्ताव रखता है जब तीनों बातें सही हों — पलटना मुश्किल, बिना context के उलझाने वाला, और किसी असली ट्रेड-ऑफ़ का नतीजा।

यह दरअसल domain-driven design की दो संजीदा आदतें हैं — ubiquitous language (टीम की एक ही साझा शब्दावली) और फ़ैसलों का निशान छोड़ना — एक ऐसी बातचीत में लपेटी हुई जिससे आप बच नहीं सकते।

एक बदलाव जानने लायक है: यह असल में दो skill जोड़कर बना है। Matt ने grill-with-docs को बाँटा है — grilling (वह लगातार चलने वाला इंटरव्यू) और domain-modeling (glossary + ADR का अनुशासन) — और ख़ुद grill-with-docs को एक पतला खोल बना दिया जिसका सारा मतलब एक लाइन में है: “/grilling चलाओ, /domain-modeling का इस्तेमाल करते हुए।” व्यवहार में कुछ नहीं बदला, पर अब आप दोनों आधे अलग-अलग भी चला सकते हैं: सिर्फ़ कसवाना है तो /grilling; सिर्फ़ glossary और ADR सँभालने हैं तो /domain-modeling; दोनों चाहिए — वही grill-with-docs है।

3. शुरुआत: लगाइए, फिर एक प्लान थमा दीजिए

लगाइए। यह mattpocock/skills में है — आधिकारिक एक-लाइन कमांड, प्रॉम्प्ट में grill-with-docs पर निशान:

npx skills@latest add mattpocock/skills

उसी बँटवारे की वजह से, grill-with-docs अब grilling और domain-modeling के बिना पूरा नहीं होता, इसलिए तीनों पर निशान लगाइए (या सीधे बाद वाले दो इस्तेमाल कीजिए)। repo पहले से local पर clone कर रखी है? उन फ़ोल्डरों को सीधे अपने प्रोजेक्ट के .claude/skills/ में कॉपी कर देना भी चलता है।

थमाइए। “मेरे लिए X बना दो” कहना बंद कीजिए। इसके बजाय यह कहिए:

grill-with-docs से मेरा प्लान कसो: <वह प्लान डालिए जो आपने अभी पूरी तरह सोचा नहीं है>

ध्यान दीजिए: इस पर disable-model-invocation का टैग लगा है, इसलिए यह अपने-आप सामने नहीं आता — इसे नाम लेकर बुलाना पड़ता है (या /grill-with-docs टाइप कीजिए) तभी चालू होता है। फिर तैयार रहिए: यह आपकी हाँ में हाँ नहीं मिलाएगा, यह सवाल दागना शुरू करेगा।

पहला असली नतीजा अक्सर इसका पहला सवाल ही होता है: कोई चीज़ जो आपको लगता था आपने सुलझा ली है, और एक सवाल में ही पता चलता है कि सुलझाई नहीं थी। नीचे एक रन है जो मैंने सचमुच चलाया।

4. एक असली कसाई देखिए

मैंने इसके कसने के लिए एक छोटा प्रोजेक्ट बनाया, जिसमें जानबूझकर एक जाल बिछाया था। प्रोजेक्ट में पहले से एक CONTEXT.md थी:

**Cancellation**:
शिपिंग से पहले पूरा ऑर्डर void कर दिया जाता है; stock जस का तस inventory में लौट आता है। कोई refund flow शामिल नहीं।
_Avoid_: Refund, Return

src/orders.ts का कोड भी सीधी राह चलता है: cancelOrder() सिर्फ़ पूरे ऑर्डर void करता है, सिर्फ़ शिपिंग से पहले, पैसे को कभी नहीं छूता।

फिर मैंने इसे वह प्लान थमाया (वही जो शुरू में था): “यूज़र को किसी ऑर्डर में से कुछ आइटम कैंसिल करने दो (पूरा नहीं), फिर उन आइटमों का पैसा रिफ़ंड कर दो।”

इसने कोड और glossary पढ़े, और इसकी पहली लाइन “बिलकुल” नहीं थी — यह थी:

शुरू करने से पहले, दो शब्दों के टकराव बताने ज़रूरी हैं।

आपका “कुछ आइटम कैंसिल करो और रिफ़ंड दो” दो मौजूदा परिभाषाओं से टकराता है:

CONTEXT.md में Cancellation = पूरा ऑर्डर void + कोई refund flow नहीं है। आप तो आंशिक cancellation बता रहे हैं, वह भी रिफ़ंड के साथ — दोनों टकराते हैं।

glossary की _Avoid_ लिस्ट में “Return” शब्द साफ़-साफ़ बाहर रखा गया है।

तो जो काम आप बता रहे हैं उसके लिए कोई मौजूदा शब्द नहीं है। आगे बढ़ने से पहले हमें इस नई धारणा को नाम देना होगा।

मुझे सचमुच भान नहीं था: मेरे वाक्य का “कैंसिल” और प्रोजेक्ट में पहले से तय Cancellation एक ही चीज़ नहीं थे। इसने सिर्फ़ पकड़ा ही नहीं — इसने जाकर कोड भी पढ़ा:

मौजूदा cancelOrder, src/orders.ts:3 पर, सिर्फ़ उन ऑर्डरों की इजाज़त देता है जिनका status === "PLACED" है। आपका “कुछ आइटम कैंसिल करो” — सिर्फ़ शिपिंग से पहले, या बाद में भी?

मेरा सुझाव: सिर्फ़ शिपिंग से पहले। शिपिंग के बाद की वापसी कारोबारी मायनों में एक returns flow है, परिमाण में एक दर्जा ज़्यादा पेचीदा… पहले शिपिंग-से-पहले वाली राह शिप कीजिए; सीमा वहीं सबसे साफ़ है।

मैंने जवाब दिया “ठीक है, सिर्फ़ शिपिंग से पहले।” फिर इसने एक और भी अहम काम किया — उस बेनाम धारणा को नाम दिया और सीधे glossary में लिख दिया:

Partial Cancellation: शिपिंग से पहले, किसी ऑर्डर में से कुछ (सब नहीं) line item हटा दिए जाते हैं; हटाए गए आइटमों का stock inventory में लौट आता है। कोई refund flow शामिल नहीं। _Avoid_: Partial refund, Partial return, Item cancellation

यह वाला इसने सचमुच CONTEXT.md फ़ाइल में लिखा, सिर्फ़ चैट में नहीं। रिफ़ंड वाले आधे को इसने साफ़-साफ़ अलग धकेल दिया: “वह Billing का काम है — यहाँ नहीं लिखा जाएगा।”

सीमाओं की ओर कसते हुए, यह रुककर तय करने लगा कि निशान छोड़ना है या नहीं, और फिर सचमुच एक ADR बनाया:

एक ADR docs/adr/0001-partial-cancellation-no-refund.md पर रख दिया: “Partial Cancellation रिफ़ंड चालू नहीं करता; रिफ़ंड पूरी तरह Billing context पर छोड़ा गया है। … विकल्प यह था कि रिफ़ंड Ordering के अंदर ही चालू कर दिया जाए, यानी ‘cancel + refund’ को एक atomic operation बना दिया जाए — हमने इसे ठुकराया क्योंकि इससे Ordering, Billing के अंदरूनी हिस्सों पर निर्भर हो जाता और मौजूदा context सीमा टूट जाती।”

सबसे बढ़िया हिस्सा इसका अगला सवाल है, जिसमें इसने वही ADR उद्धृत किया जो अभी-अभी ख़ुद लिखा था:

सवाल 3 / Billing को कैसे पता चलेगा कि रिफ़ंड करना है? मौजूदा cancelOrder कोई event ही नहीं भेजता (src/orders.ts:7)।

A. एक domain event भेजो; Billing subscribe करके रिफ़ंड कर देगा।

B. Ordering सीधे Billing का refund API कॉल करे।

C. कुछ मत भेजो; caller ख़ुद जोड़ ले।

मेरा सुझाव: A। विकल्प B, Ordering को सीधे Billing पर निर्भर बनाता है — बिल्कुल वही जो ADR 0001 ने ठुकराया था।

इस घेरे को ज़रा महसूस कीजिए: इसने मुझसे एक शब्द धार पर लगवाया → उसे glossary में लिखा → एक सीमा वाले फ़ैसले को ADR के रूप में दर्ज किया → फिर उसी ADR से आगे एक ऐसा विकल्प रोका जो सीमा तोड़ देता। यह उसी भाषा से, जो आपने अभी साथ मिलकर बनाई है, आगे के हर कदम की रखवाली कर रहा है। “एक इंटरव्यू जिसे आपका प्रोजेक्ट याद है” का यही मतलब है।

5. इसका मिज़ाज: कब चलाएँ, कब ज़बरदस्ती न करें

यह झकझोरता है, पर न तो हर मर्ज़ की दवा है और न हमेशा सही चुनाव:

इसके पास कसने को कुछ होना चाहिए। एक CONTEXT.md और थोड़े कोड के साथ इसके पास सामग्री होती है — आपको बाँधने और मिलान करने को। बिल्कुल ख़ाली नए repo में यह शून्य से glossary बना देगा (तब भी काम का), पर उतना धारदार कतई नहीं जितना आपकी पहले से मौजूद भाषा में छेद ढूँढना। इसलिए यह सबसे अच्छा है एक ऐसे प्रोजेक्ट में जोड़ने के लिए जो पहले से बड़ा हो चुका है।
यह स्पष्टता पर धार लगाता है, कोड पर नहीं। एक कसाई के बाद आपके हाथ में धार पर लाए हुए शब्द होते हैं, कुछ ADR, एक ऐसा प्लान जो आपने सचमुच सोच लिया है — एक ढेर implementation नहीं। कोड लिखना अगला कदम है, साफ़ हो जाने के बाद; यह उम्मीद मत रखिए कि वह आपके लिए कर देगा।
मामूली चीज़ें मत कसवाइए। एक बटन का रंग, एक बेमतलब field — इसे प्रक्रिया से गुज़ारिए तो यह आज्ञाकारी ढंग से साथ निभा देगा, पर निरा वक़्त-बर्बादी। इसकी क़ीमत वहाँ है जहाँ एक धुँधला शब्द बेइंतहा झंझट पैदा करता है: डोमेन की धारणाएँ, context की सीमाएँ, वे जगहें जहाँ कुछ विचार आपस में उलझ जाते हैं। मक्खी पर हथौड़ा: मक्खी सलामत, आप थके।
यह ADR देने में कंजूस है — यह ख़ूबी है, इस पर खीझिए मत। यह तभी एक दर्ज करता है जब तीनों बात सही हों: पलटना मुश्किल, आगे चलकर उलझाने वाला, और एक असली ट्रेड-ऑफ़। जब आप ख़ुद को यह चाहते पकड़ें कि यह और दर्ज करता तो पूछिए: आपको सचमुच निशान चाहिए, या बस “सब कुछ पूरा” वाली रस्मअदायगी? ज़्यादा ADR बेहतर नहीं; जो मायने रखते हैं उन्हें दर्ज करना बेहतर है।

एक लाइन में: किसी पके हुए प्रोजेक्ट में पेचीदा फ़ीचर जोड़ना हो, और मन में यह खटक हो कि “कुछ शब्दों के मतलब अलग-अलग लोगों के लिए अलग हैं” — तो इसे चालू कीजिए। यही इसका मैदान है।

6. झटपट कार्ड

लगाना:   npx skills@latest add mattpocock/skills   # प्रॉम्प्ट में grill-with-docs पर निशान
कसाई:    AI से कहिए "grill-with-docs से मेरा प्लान कसो: <प्लान>"

यह क्या करता है:
  एक बार में एक सवाल, पहले सुझाया हुआ जवाब
  जो कोड से पता चल जाए वहाँ पूछता नहीं
  CONTEXT.md glossary पर बाँधे रखता है; शब्द मेल न खाए तो रोक देता है
  धुँधले शब्द धार पर लाता है ("account" = Customer या User?)
  कोड से मिलान करता है; मेल न खाए तो टोकता है
  शब्द तय हुआ -> सीधे CONTEXT.md में (glossary, कोई implementation ब्यौरा नहीं)
  मुश्किल से पलटने वाला फ़ैसला -> एक ADR (docs/adr/, तभी जब तीनों कसौटी सही हों)

CONTEXT.md: सिर्फ़ glossary — हर शब्द पर एक-दो लाइन, इस्तेमाल का शब्द + _Avoid_ छोड़ने वाले शब्द
ADR की तीन कसौटी: पलटना मुश्किल + बिना context उलझाने वाला + असली ट्रेड-ऑफ़ (एक भी छूटी, मत दर्ज करो)

सबसे अच्छा कब: किसी पके प्रोजेक्ट में पेचीदा फ़ीचर जोड़ना, जहाँ "कुछ शब्दों के मतलब अलग-अलग लोगों के लिए अलग हैं"
मत करिए: ख़ाली repo / मामूली बदलाव / यह उम्मीद कि कोड वही लिख देगा

7. आगे और

सोर्स: grill-with-docs (MIT), और जिन दो में यह बँटा है, grilling और domain-modeling। glossary और ADR के फ़ॉर्मैट की गाइड अब domain-modeling में हैं: CONTEXT.md फ़ॉर्मैट, ADR फ़ॉर्मैट — दोनों पढ़ने लायक हैं।
और गहराई में जाना है? domain-driven design (DDD) में ubiquitous language और ADR (Architecture Decision Record) देखिए — grill-with-docs बस एक हल्का खोल है जो इन दोनों को सहज बना देता है।
AI के साथ “एक अलग कोण से सहयोग” वाला यह दाँव पसंद आया? पिछली बार हमने caveman खोला था (AI को बकबक बंद करवाकर सीधे मतलब पर लाना) — एक बढ़िया जोड़ी: एक उससे भराव कटवाता है, दूसरा उससे मुश्किल सवाल पुछवाता है। यह सीरीज़ Matt की repo के बाक़ी skill एक-एक करके खोलती रहेगी।

यह usesuperpowers.com का मौलिक ट्यूटोरियल है। इसमें समझाया गया grill-with-docs skill mattpocock/skills से है (source_commit: 6eeb81b), और उसके MIT लाइसेंस का पालन करता है। दिखाया गया कसाई का सत्र एक असली रन है (इधर-उधर के ब्यौरे हटा दिए गए हैं); मूल skill के नियमों का कॉपीराइट उनके लेखक का है; हमारी व्याख्या, demo और शब्द मौलिक हैं।

वर्शन के बारे में: यह लेख 6eeb81b पर आधारित है। इस वर्शन में Matt ने अकेली grill-with-docs को दो skill में बाँट दिया, grilling + domain-modeling, और grill-with-docs को दोनों जोड़ने वाला रास्ता बना दिया; जो व्यवहार यहाँ बताया गया और ऊपर का असली कसाई — दोनों पर इसका असर नहीं है, बस इस्तेमाल में “दोनों आधे अलग चलाए जा सकते हैं” वाली एक परत और जुड़ गई।