मैंने हर Claude Code आदत को एक कमांड बना दिया

Claude Code की आदतों की हर लिस्ट बताती है कि क्या करना है। यह लेख हर आदत को एक ऐसे कमांड में बदलता है जिसे Claude Code खुद चलाता है, इसलिए आदत तब भी टिकी रहती है जब मॉडल उसे पढ़े या न पढ़े। हमने पाँचों को एक असली repo पर चलाया: ledgerly, Node 20 और TypeScript में बना एक छोटा invoicing API, Claude Code 2.1.294 के साथ।

वजह Anthropic की अपनी best practices में है: आपकी CLAUDE.md में "finish करने से पहले हमेशा typecheck चलाओ" जैसी लाइन "ज़्यादातर बार काम करती है, हर बार नहीं"। नीचे के पाँच कमांड ये हैं: /goal, एक PreToolUse hook, /context के साथ /clear, /skill-doctor, और एक read-only reviewer subagent।

CLAUDE.md वह instructions फ़ाइल है जिसे Claude हर session की शुरुआत में पढ़ता है, यानी नए टीममेट के लिए लिखी गई readme: कमांड, conventions और नियम। ज़्यादातर आदतें यहीं पहुँचती हैं, और सबसे ज़रूरी वाली अक्सर कैपिटल में होती हैं, जैसे "NEVER edit src/store/migrations.ts"।

Anthropic के memory docs साफ़ बताते हैं कि यह फ़ाइल क्या है: Claude इसे context की तरह पढ़ता है, लागू की गई configuration की तरह नहीं। हर लाइन एक सलाह है जिसे वह सामने के काम के साथ तौलता है। फ़र्क़ वही है जो wiki पेज पर रखी code review checklist और आपकी CI pipeline के किसी check में होता है: पहली तब काम करती है जब कोई उसे पढ़े, दूसरा हर हाल में चलता है।

करने की बात: अपनी CLAUDE.md खोलिए और हर वह लाइन चिह्नित कीजिए जो हर बार टिकनी चाहिए। बाकी को वहीं रहने दीजिए, क्योंकि जो बात Claude आपके कोड से नहीं निकाल सकता उसके लिए यह फ़ाइल अब भी सही जगह है, और docs प्रति फ़ाइल 200 लाइन से कम का लक्ष्य देते हैं।

Claude तब रुकता है जब काम पूरा दिखता है। अगर कोई उसे नहीं बताता कि काम सच में पूरा हुआ या नहीं, तो Anthropic की best practices के मुताबिक आप ही test suite बन जाते हैं।

/goal एक बार में finish line तय कर देता है। हर turn के बाद एक छोटा, तेज़ मॉडल बातचीत पढ़ता है और लौटाता है: met, not yet met या impossible। वह कमांड नहीं चला सकता और फ़ाइलें नहीं पढ़ सकता, इसलिए शर्त ऐसी लिखिए जिसे Claude का अपना आउटपुट दिखा सके, जैसे पूरा test आउटपुट।

ledgerly पर चलाया	हमने क्या देखा
सादा session, वही feature request	Tests एक collapsed tool call के अंदर चले; जवाब में लिखा था "pnpm test passes (37/37)"
/goal और शर्त "full pnpm test output printed" के साथ	जवाब में पूरा run छपा, "Tests 44 passed (44)", फिर "Goal achieved (45s · 1 turn · 5.1k tokens)"

उसकी स्थिति देखने के लिए अकेला /goal टाइप कीजिए और हटाने के लिए /goal clear। एक लाइन के fix के लिए इसकी ज़रूरत नहीं; docs कहते हैं कि यह लंबे runs में सबसे ज़्यादा काम आता है, जहाँ Claude कभी-कभी कुछ चीज़ें खुली छोड़कर turn खत्म कर देता है।

कैपिटल में लिखा नियम ज़्यादातर बार माना जाता है, और यही असली समस्या है। Hook एक छोटी script है जिसे Claude Code तय क्षण पर खुद चलाता है; PreToolUse hook हर tool call से पहले चलता है। हमारा hook फ़ाइल का path पढ़ता है और जब वह src/store/migrations.ts हो, तो "migrations.ts is append-only: add a new migration file instead" छापकर exit code 2 के साथ निकल जाता है। Hooks guide के अनुसार exit code 2 call को block करता है और संदेश Claude तक लौटा देता है, और permission prompts बंद होने पर भी यह block टिकता है।

हमारे runs में: CLAUDE.md में नियम होने पर Claude ने खुद edit से मना कर दिया। नियम हटाने पर Claude दो बार migrations फ़ाइल की ओर गया और hook ने दोनों edits block कर दिए; Claude ने बाकी edit किया और बताया "A project hook blocked both of my edits to that file." बाद के दो runs में उसने पहले hook script पढ़ी और उस फ़ाइल को छुआ तक नहीं।

Hook सिर्फ़ वही block करता है जिसे वह match कर सके, जैसे कोई path या कमांड। "साफ़ कोड लिखो" जैसे विवेक वाले नियम CLAUDE.md में ही रहते हैं, और match को संकरा रखने से hook आपके अपने काम को नहीं रोकता।

Context वह सब है जो मॉडल हर turn पर देखता है: आपके instructions, पढ़ी गई फ़ाइलें और पूरी बातचीत। /context इसे एक grid की तरह दिखाता है; /clear बातचीत खाली कर देता है, जबकि फ़ाइलें और settings बनी रहती हैं।

ledgerly पर /context	कुल	Messages
पूरा हुए काम के बाद	1m में से 57.5k tokens	26.4k tokens
/clear के बाद	1m में से 31.1k tokens	130 tokens

Docs कहते हैं: असंबंधित कामों के बीच /clear की कोई कीमत नहीं, और दो बार सुधार विफल होने के बाद आप clear करके बेहतर prompt लिखते हैं। काम के बीच में इसकी जगह फ़ोकस के साथ /compact इस्तेमाल कीजिए।

Skill एक पैक किया हुआ instruction है जिसे Claude तब लोड करता है जब कोई काम उससे मेल खाए। पूरी skill तभी लोड होती है जब वह चले, लेकिन उसकी एक लाइन की listing हर turn prompt में रहती है, और listing का बजट context window का लगभग 1% है, इसलिए सबसे कम इस्तेमाल होने वाली skills के descriptions सबसे पहले हटते हैं।

/skill-doctor हर skill को उसके context cost और आपके इस्तेमाल की गिनती के साथ दिखाता है। हमारी मशीन पर उसने यह बताया:

प्रकार	लोड हैं पर कभी चलाई नहीं गईं
Personal skills	13
claude.ai से sync हुईं	14
Plugin skills	25

उसने 4 ऐसे plugins भी गिनाए जो हाल में इस्तेमाल नहीं हुए। किसी skill को /skills में बंद कीजिए; synced skills हटाने पर वापस आ जाती हैं, इसलिए उन्हें claude.ai पर बंद कीजिए; plugin skills plugin manager से बंद होती हैं। एक listing लाइन छोटी होती है, इसलिए इससे शोर कम होता है, आपका आधा context खाली नहीं होता।

Subagent एक दूसरा Claude session है जो एक ही काम के लिए शुरू होता है, अपने खाली context के साथ, और बदले में सारांश लौटाता है। Anthropic के docs सीधे कहते हैं: वही काम subagent को देने से जवाब बेहतर नहीं होता, लेकिन ताज़ा reviewer मदद करता है क्योंकि उसने आपका तर्क नहीं देखा।

हमारा reviewer .claude/agents/reviewer.md में रहता है और उसके tools read-only हैं: Read, Grep, Glob, Bash(git diff:*) और Bash(git status:*)। overdue-invoices वाले diff पर author session की अपनी review को एक असली bug मिला: एक ही due date वाले invoices id के हिसाब से text की तरह sort हो रहे थे। Reviewer को वही bug और गायब test 28 सेकंड में मिल गए, फिर उसने README का हर convention एक-एक करके जाँचा। उसने यह भी दावा किया कि type check साफ़ है, जो उसके tools चला ही नहीं सकते थे, और मुख्य session ने इसे अपुष्ट चिह्नित किया। इसे हर feature पर एक बार, merge से पहले बुलाइए।

Hook से शुरू कीजिए, उस नियम पर जो आपके repo में एक से ज़्यादा बार टूट चुका है। /clear और /skill-doctor कुछ खर्च नहीं करते। /goal को लंबे runs के लिए रखिए और reviewer को merge के लिए। याद रखने वाला नियम: अगर कोई आदत हर बार टिकनी चाहिए, तो उसे ऐसा कुछ बनाइए जिसे Claude Code चलाए, ऐसा नहीं जिसे Claude पढ़े।