Claude Code को पहला task सौंपने के लिए ऐसा brief लिखें

“इस repository का README वगैरह ज़रा ठीक-ठाक कर दो।”

Install करने के तीस मिनट बाद, मैंने Claude Code को सबसे पहला यही काम दिया था। जवाब में जो diff आया, उसमें सिर्फ README नहीं, package.json के script names तक बदल चुके थे। चलता तो है, मगर जो असल में ठीक करना था उससे अलग तीन files बदल गई थीं। “ये publish करने लायक है भी या नहीं?”—मैं screen के सामने ठहर गया।

जो Claude Code इतना समझदार माना जाता है, वह बिना कहे जगहों को क्यों छू बैठता है? यह क्षमता की कमी नहीं है। बात बस इतनी है कि मैंने एक शब्द में भी नहीं बताया था कि “कहाँ तक करना है”। जैसे किसी नए कर्मचारी से कहकर निकल जाएँ “दुकान ज़रा सँभाल लेना”, और लौटकर देखें कि उसने पूरी shelf ही दोबारा सजा डाली।

यह लेख उसी “कहाँ तक” को एक कागज़ पर लिखने के बारे में है। मैं इसे brief (पहले task का brief) कहता हूँ।

मुख्य बातें

• पहले request में हादसा इसलिए होता है क्योंकि मकसद, छूने की हद, proof और rollback तय किए बिना “ठीक-ठाक कर दो” कह दिया जाता है।
• Brief में 9 आइटम लिखें: मकसद / पाठक की हालत / पढ़ने की इजाज़त / edit की इजाज़त / run की इजाज़त / मत छूना / proof / rollback / अगला कदम।
• Claude Code को सौंपें सिर्फ “पढ़ना, तय files सुधारना, verification command चलाना” तक। Delete, production में लागू करना, और पैसे खर्च करने वाला फैसला इंसान करे।
• Copy-paste लायक brief template और brief की कमी अपने-आप पकड़ने वाली JavaScript दोनों यहाँ दे रहा हूँ।
• सबसे तेज़ सफलता का अनुभव है—“गड़बड़ होने पर भी git से वापस लौटाया जा सके” ऐसा एक छोटा task चुनना।

पहले ही task में हादसा क्यों होता है

Claude Code डालते ही ज़्यादातर लोग “चौड़ा request” देते हैं। “repository व्यवस्थित कर दो”, “README ठीक कर दो”। मन समझ में आता है—जानना तो चाहते हैं कि यह कर क्या सकता है।

मगर चौड़ा request देते ही पहले दस मिनट exploration में निकल जाते हैं। Claude Code इधर-उधर की files पढ़ता है, जो जगह जुड़ी लगती है उसे अपनी मर्ज़ी से सुधारता है, और आख़िर में “शायद चलता है” जैसी धुँधली report देकर रुक जाता है। आपको पूरा diff दोबारा पढ़ना पड़ता है, और अंत में लगता है “इससे तो खुद कर लेता तो जल्दी होता।”

वजह model की समझदारी नहीं है। वजह यह है कि आपने मकसद और सीमा दी ही नहीं। इंसानी नया कर्मचारी भी पहले दिन “जो मन हो करो” सुनकर या तो हाथ रोक लेगा या बेकाबू हो जाएगा। सीमा पहले तय कर देने भर से यह हादसा लगभग खत्म हो जाता है।

जिन्हें बुनियादी operations को लेकर ही झिझक है, वे पहले Claude Code की शुरुआत कैसे करें एक बार देख लें, फिर लौटें—तब यह brief वाली बात आसानी से बैठ जाएगी।

Brief में लिखने के 9 आइटम

मैं हर बार एक कागज़ पर यही 9 आइटम लिखता हूँ। मुश्किल शब्दों की ज़रूरत नहीं। हर लाइन में एक-एक जवाब भर देना है, बस।

आइटम	क्या लिखें	बुरा उदाहरण → अच्छा उदाहरण
मकसद	खत्म होने पर क्या हालत हो तो सफलता	”README ठीक करो” → “README के steps को package.json से मिलाओ”
पाठक की हालत	किसके लिए काम है	(खाली) → “beginner, एक बार पक्की सफलता चाहिए”
पढ़ने की इजाज़त	जिन files को देखने दें	(सब) → “सिर्फ README.md और package.json”
edit की इजाज़त	जिन्हें बदलने दें	(सब) → “सिर्फ README.md”
run की इजाज़त	जो command चलाने दें	(कुछ भी) → “सिर्फ npm run build”
मत छूना	जिसे हरगिज़ न बदलने दें	(तय नहीं) → “package-lock, deploy settings, pricing”
proof	सफलता का सबूत क्या होगा	”चल जाए तो ठीक” → “build pass हो / diff सिर्फ README का हो”
rollback	fail होने पर वापस कैसे लौटाएँ	(कुछ नहीं) → “README को git से वापस लाओ”
अगला कदम	पाठक का अगला एक कदम	(तीन गिनाना) → “पहले सिर्फ मुफ्त शुरुआती सामग्री”

असली पकड़ “मत छूना”, “proof” और “rollback” में है। जिस पल आप ये तीन लिख देते हैं, request एक “विनती” से बदलकर “सुरक्षित रूप से सौंपा जा सकने वाला काम” बन जाता है।

Copy-paste लायक brief template

यह सीधे इस्तेमाल लायक खाका है। code block इसलिए है ताकि Claude Code में बिल्कुल वैसे ही paste करके दिया जा सके। अपनी repository का नाम और जो जगह सुधारनी है, वहाँ बदल लें।

# पहले task का brief

मकसद: README के setup steps को package.json की सामग्री से मिलाना।
पाठक की हालत: beginner. एक बार पक्की सफलता चाहिए।
पढ़ने की इजाज़त:
- README.md
- package.json
edit की इजाज़त:
- सिर्फ README.md
run की इजाज़त:
- npm run build
मत छूना:
- package-lock.json
- deploy settings (environment variables, publish settings)
- pricing या signup links
proof:
- npm run build pass हो
- git diff में सिर्फ README.md का बदलाव हो
rollback:
- proof fail हो तो README.md को git से वापस लाओ
अगला कदम:
- पहले सिर्फ मुफ्त शुरुआती सामग्री की जानकारी दो

असली उदाहरण में कहें तो—अगर सिर्फ README के steps को package.json से मिलाना है, तो पढ़ना है README और package.json, edit सिर्फ README, सबूत है npm run build। इतने बारीक scope पर, fail होने पर भी git checkout -- README.md एक झटके में वापस लौटा देता है। पहली बार इतना ही संकरा रखें—बल्कि जितना संकरा, उतना ही आप खुद तय कर पाएँगे कि सफल हुआ या नहीं।

Claude Code को क्या सौंपें, और इंसान क्या तय करे

Brief लिखते वक्त मैं दिमाग में यह लकीर खींचता हूँ। सीमा धुँधली हो तो Claude Code “मदद के इरादे” से लकीर पार कर जाता है।

Claude Code को सौंपना ठीक	इंसान तय करे (automate न करें)
तय files पढ़ना	किन files को छूने देना है, यह फैसला
सिर्फ तय files सुधारना	files को delete करना
npm run build जैसी verification command चलाना	production में लागू करना / deploy
diff का सारांश लौटाना	पैसे खर्च करने वाला operation
fail की वजह बताना	git push --force जैसे न लौटने वाले operation

बायाँ हिस्सा सौंप दें। दाएँ हिस्से को शुरू में पूरा “चलाने से पहले इंसान से पुष्टि” पर रखें। जो operation सुरक्षित साबित हो जाए, बस उसे बाद में थोड़ा-थोड़ा automatic की तरफ खिसकाएँ। यह क्रम भर निभाने से, रात को दिल दहलने की नौबत बहुत कम आती है।

Request देते वक्त मैं एक लाइन जोड़ देता हूँ।

इस brief के scope में ही, एक छोटा task चलाएँ।
जो scope के बाहर लगे, उसे चलाएँ नहीं—सिर्फ सुझाव दें।

सबसे पहले ये पाँच लौटाएँ:
1. जो files अब पढ़ेंगे
2. जो files अब edit करेंगे
3. काम से पहले और बाद चलाने वाली verification command
4. बदलाव के diff का सारांश
5. fail होने पर rollback कैसे करेंगे

खास बात है “implement से पहले plan और proof लौटाओ” कहना। लौटा हुआ plan अगर brief के scope से बाहर निकल रहा हो, तो उसी जगह रोका जा सकता है। हाथ चलने से पहले रोक लें, तो बाद की सफाई की ज़रूरत ही नहीं पड़ती।

Brief की कमी अपने-आप पकड़ने वाला code

Brief लिख तो दिया, फिर भी कोई आइटम छूट जाना आम बात है। मैं आइटम मौजूद हैं या नहीं, यह मशीन से जँचवाता हूँ। यह copy-paste पर चलने वाली JavaScript है। Node.js में node check-brief.mjs की तरह चला सकते हैं।

// brief में सब ज़रूरी आइटम मौजूद हैं या नहीं, मशीनी जाँच
const requiredFields = [
  "मकसद",
  "पढ़ने की इजाज़त",
  "edit की इजाज़त",
  "run की इजाज़त",
  "मत छूना",
  "proof",
  "rollback",
  "अगला कदम",
];

export function validateFirstTaskBrief(markdown) {
  // जो आइटम मौजूद नहीं हैं, उन्हें छाँटो
  const missing = requiredFields.filter((field) => !markdown.includes(field));

  // verification command (यहाँ npm run build) तक लिखी है या नहीं, यह भी देखो
  const hasProofCommand = markdown.includes("npm run build");

  return {
    ok: missing.length === 0,
    missing,
    readyForClaudeCode: missing.length === 0 && hasProofCommand,
  };
}

// काम जाँचने का उदाहरण
const sample = `
मकसद: README को package.json से मिलाओ
पढ़ने की इजाज़त: README.md
edit की इजाज़त: README.md
run की इजाज़त: npm run build
मत छूना: package-lock.json
proof: npm run build pass हो
rollback: git से README.md वापस लाओ
अगला कदम: मुफ्त शुरुआती सामग्री
`;

const result = validateFirstTaskBrief(sample);
console.log(result);
// → { ok: true, missing: [], readyForClaudeCode: true }

इस जाँच से गुज़ारकर brief देने की आदत डाल लें, तो “मत छूना” और “rollback” का छूट जाना खत्म हो जाता है। सिर्फ इंसानी आँख पर भरोसा करें, तो व्यस्त दिन कहीं न कहीं ज़रूर कुछ छूटेगा। जो मशीन से पता चल सकता है, उसे मशीन पर छोड़ देना आसान है।

ऐसे मौकों पर काम आता है (तीन)

1. README या manual की सुधार “documentation update कर दो” कहें तो scope अनंत है। “सिर्फ README के setup chapter को package.json के script names से मिलाओ” कहकर संकरा करें, तो diff एक file में सिमट जाता है और npm run build से जाँचा जा सकता है। पहले task के लिए यह सबसे उपयुक्त है।

2. Pull request की पहली review “इस PR को देखो” नहीं, बल्कि “बदली files में से सिर्फ src/ वाली पढ़ो, और जहाँ test fail हो सकता है वहाँ इशारा करो। code मत सुधारो, सिर्फ इशारा करो।” पढ़ना सौंप दें, सुधारने का फैसला इंसान के पास रखें। इससे “अपनी मर्ज़ी से सुधारकर नया bug पैदा कर देने” वाला हादसा रुक जाता है।

3. CTA (पाठक के अगले कदम की राह) बदलना लोकप्रिय लेख के नीचे का एक button भर बदलने में भी, “related component ढूँढकर सुधारो” बहुत चौड़ा है। पहले brief में तय करें—“जो file छूनी है”, “जो public URL जाँचनी है”, “जो link बदलनी है”। काम के बाद की जाँच “लगता तो ठीक है” से बदलकर “इस सबूत पर तो publish कर सकते हैं” बन जाती है।

मेरी की हुई तीन गलतियाँ

ईमानदारी से लिखता हूँ। Brief इस्तेमाल शुरू करने से पहले, मैं यही गलतियाँ बार-बार दोहराता था।

पहली—“मत छूना” न लिखना। बस README सुधरवाना था, और Claude Code ने मदद के इरादे से package.json तक सँवार दिया, जिससे build रुक गया। मत छूना: package-lock.json, deploy settings की तीन लाइनें भर जोड़ीं, और यह दोबारा कभी नहीं हुआ।

दूसरी—proof को “चल जाए तो ठीक” में निपटाना। “चलना” किसे कहें, यह तय न होने से हर बार diff आँखों से पूरा पढ़ना पड़ता था। proof: npm run build pass हो / diff सिर्फ README का हो जैसी ठोस command बनाई, तो जाँच 10 सेकंड में खत्म होने लगी।

तीसरी—अगला कदम तीन गिनाना। लेख के अंत में सामग्री, course, consultation—सब चिपका दिए, तो पाठक की प्रतिक्रिया धुँधली हो गई। पाठक की हालत के मुताबिक एक पर सिमट जाएँ, तो आख़िर वही एक ठीक से click होता है। क्या लिखना है, यह CLAUDE.md लिखने का तरीका में project नियम के तौर पर रख दें, तो हर बार डगमगाहट नहीं होती।

अक्सर पूछे जाने वाले सवाल

Q. हर बार ये पूरे 9 आइटम लिखना झंझट नहीं? सिर्फ पहली कुछ बार। एक template बनाकर first-task-brief.md के तौर पर रख दें, तो अगली बार से बस 3–4 लाइनें बदलनी होती हैं। लिखने में जितना समय लगता है, उससे कहीं ज़्यादा बेकाबू diff दोबारा पढ़ने में लगता है।

Q. आसान काम में भी brief चाहिए? “एक file की spelling सुधारना” जैसे स्तर पर ज़बानी request काफी है। Brief तब काम आता है जब काम कई files छू सकता हो, या production-पैसे-delete पास से गुज़रते हों। दुविधा हो तो लिख लें—इसमें नुकसान नहीं।

Q. क्या English key names (Goal, May edit वगैरह) में लिखूँ? Team में logs को साथ रखकर तुलना करनी हो तो English keys एक जैसे रहकर सुविधाजनक हैं, मगर अकेले इस्तेमाल हो तो Hindi काफी है। Claude Code दोनों समझता है। अहम भाषा नहीं, आइटम का न छूटना है।

Q. जो programming नहीं करते, वे भी इस्तेमाल कर सकते हैं? हाँ। लेख लिखने या सामग्री व्यवस्थित करने में भी “पढ़ने की इजाज़त / edit की इजाज़त / मत छूना” वाली सोच एक ही है। non-engineer के लिए शुरुआत जो engineer नहीं हैं उनके लिए Claude Code में समेटी है।

Q. Claude Code brief को नज़रअंदाज़ कर scope के बाहर छू दे तो? पहले “शुरू में plan और proof लौटाओ” कहकर, हाथ चलने से पहले रोकना बुनियादी तरीका है। फिर भी पार करे, तो ज़्यादा संभावना है कि brief का “मत छूना” ठोस नहीं है। folder name और file name तक साफ लिख दें, तो असर होता है।

असल में आज़माकर क्या निकला

इस brief को README को package.json से मिलाने वाले छोटे काम में आज़माना सबसे साफ रहा। edit की इजाज़त: सिर्फ README.md पहले लिख देने से, Claude Code का package-lock या config files की तरफ हाथ बढ़ाना execute से पहले plan वाले चरण पर ही रुक गया। diff दोबारा पढ़ने की मेहनत वहीं की वहीं खत्म हो गई—यही सबसे बड़ी बात रही।

proof में npm run build और git diff—ये दो डालना भी काम आया। काम के बाद का फैसला “माहौल से ठीक लगता है” से बदलकर “build हरा, diff सिर्फ README, इसलिए publish कर सकते हैं” वाली दो-टूक बात बन गया। उलटे जिस बार अगला कदम खाली छोड़ा, उस बार खुद ही “अब आगे किसकी जानकारी देनी थी” में अटक गया और लेख के अंत की राह धुँधली पड़ गई।

आख़िर समझ यह आई कि Claude Code को बड़ी आज़ादी देना ही कीमती नहीं है। पहले एक task को छोटा काटकर, सफलता-असफलता-अगला कदम अपनी आँख से दिखने वाली हालत में रखना—यही सबसे तेज़ है। एक कागज़ पर सीमा लिखने की झंझट, बेकाबू diff बाद में दोबारा पढ़ने की झंझट के सामने न के बराबर थी।

बाहरी ढाँचे को और कसना हो, तो Anthropic के Claude Code आधिकारिक documentation में permission settings का बर्ताव देख लें—तब brief और settings के बँटवारे का रोल साफ हो जाता है। कंपनी के काम में Claude Code उतारकर operation नियमों समेत व्यवस्थित करना हो, तो training / consultation में आपके असली काम के मुताबिक brief का format बनाने से ही साथ में शुरुआत की जा सकती है।