कमांड बनीं Claude Code आदतें: hook, /goal, reviewer और checklist फ़ाइलें

TL;DR और निष्कर्ष

CLAUDE.md में लिखा नियम एक सलाह है जिसे Claude तौलता है। जिस नियम को आप कमांड बना देते हैं, वह Claude के पढ़ने या न पढ़ने से फ़र्क़ के बिना चलता है। हमने अपनी मशीन पर एक invoicing API (Node 20, TypeScript, vitest) लिया, Claude Code 2.1.294 के साथ, और पाँच आदतों को पाँच कमांड की तरह चलाया।

• पूरा होना: /goal के साथ जवाब में पूरा vitest आउटपुट छपा, "Tests 44 passed (44)", और goal 1 turn के बाद achieved चिह्नित हुआ। इसके बिना Claude ने सिर्फ़ "pnpm test passes (37/37)" कहा और आउटपुट एक tool call में मुड़ा रहा।
• जो नियम टिकना चाहिए: एक PreToolUse hook ने सुरक्षित migrations फ़ाइल पर 2 edits block किए, और Claude ने बाकी edit किया।
• एक काम, एक context: /clear ने बातचीत को 26.4k tokens से 130 tokens पर पहुँचा दिया।
• जो इस्तेमाल करें वही लोड करें: /skill-doctor को 52 skills मिलीं जो लोड थीं पर कभी चलाई नहीं गईं (13 + 14 + 25)।
• ताज़ा review: एक read-only reviewer को वही tie-order bug मिला जो author session को मिला था, साथ में एक गायब test, और उसने साफ़ typecheck का दावा किया जो वह चला ही नहीं सकता था।

निष्कर्ष: पहले hook सेट कीजिए, उस नियम पर जो आपके repo में पहले ही टूट चुका है। /clear और /skill-doctor कुछ खर्च नहीं करते। /goal को लंबे runs के लिए रखिए और reviewer को merge के लिए। पैक में फ़ाइलें मिलती हैं।

स्रोतों के साथ सार

CLAUDE.md की एक लाइन लागू नहीं की जाती। Anthropic की best practices कहती हैं कि Always typecheck before you finish जैसी लाइन ज़्यादातर बार काम करती है, हर बार नहीं s1। Memory docs हर CLAUDE.md के लिए 200 लाइन से कम का लक्ष्य जोड़ते हैं, क्योंकि लंबी फ़ाइलें ज़्यादा context खाती हैं और पालन घटाती हैं s6। हमारी bench फ़ाइल में चार नियम थे, जिनमें से एक कैपिटल में: "NEVER edit src/store/migrations.ts"।

/goal वही परखता है जो स्क्रीन पर है। Evaluator कमांड नहीं चलाता और फ़ाइलें नहीं पढ़ता, इसलिए शर्त ऐसी होनी चाहिए जिसे Claude का अपना आउटपुट दिखा सके s2। इसीलिए हमारी शर्त माँगती है कि पूरा test आउटपुट बातचीत में छपे। लगभग 600 PRs वाली एक टीम की field report में पाया गया कि उसका सबसे बुरा bug tsc, lint और agent के अपने tests से निकल गया था s8। जो done-check कभी पूरा नहीं हो सकता, वह block cap तक loop करता रहता है s9।

Exit 2 वाला hook call को block करता है। Hooks guide में exit 2 का मतलब है action को block करना s3। हमारे run में, CLAUDE.md से नियम हटाने पर Claude दो बार migrations फ़ाइल की ओर गया और दोनों edits हमारे संदेश के साथ block होकर लौटे। कैपिटल वाली लाइन होने पर Claude ने खुद मना कर दिया, और बाद के 2 runs में उसने पहले hook script पढ़ी और फ़ाइल को आज़माया ही नहीं। Hacker News का एक thread सबसे तीखी आलोचना करता है: block निश्चित है, उसके बाद मॉडल क्या करेगा वह नहीं s10।

/clear मुफ़्त है, और सही चीज़ खाली करता है। Best practices कहती हैं कि असंबंधित कामों के बीच /clear की कोई कीमत नहीं s1। हमारे feature के बाद /context ने 1m में से 57.5k tokens दिखाए, Messages 26.4k पर। /clear के बाद 31.1k दिखा, Messages 130 tokens पर। Instructions, tools और skills बने रहे।

/skill-doctor बताता है कि आप क्या कभी इस्तेमाल नहीं करते। यह listing की उन skills को चिह्नित करता है जो कभी चलाई नहीं गईं और बताता है कि उन्हें कहाँ बंद करना है s7। हमारी मशीन पर उसने 13 skills बताईं जो लोड थीं पर कभी चलाई नहीं गईं, 14 claude.ai से synced, और 25 plugin skills: कुल 52, साथ में 4 plugins जो हाल में इस्तेमाल नहीं हुए। Listing की जगह कम है: एक write-up में मिला कि एक description में 267 अतिरिक्त characters ने 7 दूसरी skills को सिर्फ़ नाम बना दिया s12। फ़ायदा शोर घटने का है, आधा context खाली होने का नहीं।

ताज़ा reviewer इसलिए मदद करता है कि उसने आपका तर्क नहीं देखा। Best practices सीधे यही कहती हैं, और जोड़ती हैं कि वही काम subagent को देने से जवाब बेहतर नहीं होता s1। हर subagent एक ताज़ा, अलग context window के साथ शुरू होता है s5। इसकी कीमत है: एक user ने हर subagent को शुरू में लगभग 51k tokens का नापा s14, इसलिए इसे हर feature पर एक बार बुलाइए। हमारा reviewer background में 28 s चला।

Code

• goal-conditions.md

# /goal conditions

The /goal judge reads only the conversation. It does not run commands or read files, so write the condition as something Claude's own output can demonstrate. Name one end state and the proof you want printed on screen.

## 1. The one we used (overdue invoices endpoint)

```
/goal GET /invoices/overdue returns the overdue invoices with page and pageSize query params, new tests cover it, and the full pnpm test output showing every test passing is printed in this conversation
```

Result on our run: the reply printed the full vitest output, then the goal was marked achieved.

## 2. Template: a bug fix

```
/goal <the failing behaviour> no longer happens, a new test reproduces it and passes, and the full <your test command> output showing every test passing is printed in this conversation
```

## 3. Template: a refactor

```
/goal <the old name or pattern> no longer appears in the code, the output of <your search command> showing no matches is printed in this conversation, and the full <your test command> output showing every test passing is printed too
```

## Rules for all three

- One end state, not a list of wishes.
- The proof is output Claude prints (test results, a search result), never "it works".
- Do not write a condition Claude cannot meet; an unsatisfiable goal loops.
- Check it with `/goal` alone; remove it with `/goal clear`.

goal-conditions.md on GitHub

protect-migrations.sh

#!/bin/sh
# Block edits to the append-only migrations file
path=$(jq -r '.tool_input.file_path // empty')
case "$path" in
  *src/store/migrations.ts)
    echo "migrations.ts is append-only: add a new migration file instead" >&2
    exit 2 ;;
esac
exit 0

protect-migrations.sh on GitHub

settings.json

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Edit|Write",
        "hooks": [ { "type": "command", "command": ".claude/hooks/protect-migrations.sh" } ] }
    ]
  }
}

settings.json on GitHub

reviewer.md

---
name: reviewer
description: Read-only code reviewer. Use it to review the current git diff before a merge, against the conventions in README.md.
tools: Read, Grep, Glob, Bash(git diff:*), Bash(git status:*)
---

You review a diff you did not write. You never edit files.

1. Run `git diff` and read every changed file in full.
2. Read README.md and check the diff against each of its conventions.
3. Look for bugs: wrong edge cases, missing validation, untested branches, behaviour that breaks existing routes.

Report each finding with the file, the line, what is wrong and why it matters. Say plainly when you find nothing real. No style nits.

reviewer.md on GitHub

checklist.md

# Clear and skill-doctor checklist

After every finished task
1. Run `/context` and read what the session carries.
2. Run `/clear` before the next unrelated task.
3. Run `/context` again; the conversation should be near empty while instructions, tools and skills stay.
4. In the middle of a task, do not clear: use `/compact` with a focus instead.

Once a month
1. Run `/skill-doctor` (needs a recent Claude Code release).
2. Skills loaded but never invoked: turn them off in `/skills` (space bar cycles).
3. Skills synced from claude.ai: switch them off on the web side, deleting them locally brings them back.
4. Plugin skills: disable the plugin in the Installed tab.
5. Keep what you use rarely but still need.

checklist.md on GitHub

सोमवार को यह कीजिए

• अपनी CLAUDE.md खोलिए और हर वह लाइन चिह्नित कीजिए जो हर बार टिकनी चाहिए, ज़्यादातर बार नहीं।
• protect-migrations.sh और settings.json को .claude/ में कॉपी कीजिए, path को अपनी सुरक्षित फ़ाइल की ओर कीजिए, फिर Claude से उसे edit करने को कहिए और block देखिए।
• अपने अगले feature से पहले /goal टाइप कीजिए, ऐसी शर्त के साथ जो पूरा test आउटपुट छापने को कहे।
• वह काम पूरा होने पर /context चलाइए, फिर /clear, फिर दोबारा /context।
• /skill-doctor चलाइए और जो कभी नहीं चलाया उसे बंद कीजिए। Synced skills के लिए यह web वाली तरफ़ कीजिए।
• reviewer.md को .claude/agents/ में कॉपी कीजिए और अपने अगले merge से पहले diff की review माँगिए।
• Review के बाद typecheck खुद चलाइए। हमारे reviewer ने एक का दावा किया जो वह चला नहीं सकता था।

और आगे

हमने इन्हें छोड़ दिया।

• Prompt audit। /doctor prompt-audit और "ज़ोरदार नियम, लंबी फ़ाइल" वाली दलील। Version की न्यूनतम सीमा के लिए commands reference देखिए s4।
• ऐसी skills जो कभी trigger नहीं होतीं। यह descriptions की बात है, इस बात की नहीं कि क्या लोड होता है। शुरुआत primeline के write-up से कीजिए s12।
• MCP की छँटाई। एक लेख ने 12 MCP servers नापे: tool search के साथ 5.8k tokens और उसके बिना 63k, इसलिए यह पहले जितना मायने नहीं रखता s13।
• बड़ी CLAUDE.md फ़ाइलें। एक पोस्ट ने नौ फ़ाइलों में 455,530 characters को घटाकर 88,584 किया, और बताया कि @path imports तुरंत लोड होते हैं जबकि सादे links ज़रूरत पर s11।
• /batch। बड़े refactors के लिए commands reference 5 से 30 इकाइयाँ गिनाता है, हर एक का एक worktree s4। हमने इसे नहीं चलाया।
• हाथ से /compact की सीमाएँ। हमें किसी तय प्रतिशत का कोई स्रोत नहीं मिला, इसलिए हम कोई नहीं देते।

FAQ

क्या /goal मेरे खुद tests चलाने की जगह ले लेता है? नहीं। Judge सिर्फ़ बातचीत पढ़ता है। वह जाँचता है कि आउटपुट दिखाया गया, यह नहीं कि वह सच है।

क्या hook Claude को edit आज़माने से रोकता है? नहीं। Claude के आज़माते ही वह edit को रोकता है। हमारे run में बिना CLAUDE.md नियम के Claude दो बार फ़ाइल की ओर गया, और दोनों edits block हुए।

Hook होने पर क्या मुझे CLAUDE.md के नियम हटा देने चाहिए? नहीं। कैपिटल वाली लाइन होने पर Claude ने खुद edit से मना कर दिया, जिससे एक block हुई call बच गई। इसे उस चीज़ के लिए रखिए जो Claude आपके कोड से नहीं निकाल सकता।

हर edit पर reviewer क्यों नहीं बुलाएँ? हर subagent अपने पूरे context के साथ शुरू होता है, इसलिए इसमें असली tokens लगते हैं। इसे हर feature पर एक बार, merge से पहले इस्तेमाल कीजिए।

क्या /skill-doctor मेरे version पर चलेगा? यह एक feature flag और commands reference में बताई गई हाल की release के पीछे है s4। 2.1.294 पर यह हमारी मशीन पर चला, पर अगर आपके यहाँ न चले तो पहले Claude Code अपडेट कीजिए।