MISTAKES.md और Claude Code: बार-बार होने वाली गलती को नियम में कैसे बदलें

Claude Code के लिए MISTAKES.md कैसे रखें: विफलताएँ दर्ज करें, secrets अलग रखें, दोहराव की सीमा तय करें और गलतियों को प्रोजेक्ट नियमों व परीक्षणों में बदलें।

जटिल प्रोजेक्ट में Claude Code के साथ काम करते समय एजेंट को अनिवार्य रूप से वातावरण की ऐसी सीमाएँ मिलती हैं जो तुरंत दिखाई नहीं देतीं: पुराने types, छिपी dependencies, या bundler का विशेष व्यवहार। हर बार बातचीत में वही गलती फिर से ठीक करने पर context और समय खर्च होता है। दूसरी ओर, पूरे session के कई पन्नों वाले logs एजेंट को देने या “model memory” पर भरोसा करने से शोर बढ़ता है और फोकस घटता है।

व्यावहारिक उपाय repository के root में एक संक्षिप्त MISTAKES.md रखना है। इसमें केवल दोहराई जा सकने वाली विफलताएँ, सत्यापित कारण और रोकथाम के नियम दर्ज होते हैं; बाद में इन्हें project tests और configuration में बदला जाता है।


1. MISTAKES.md और session log में अंतर

गलतियों के journal को terminal dump न समझें:

मापदंडSession log (Transcript)MISTAKES.md journal
आकारसंवाद और intermediate commands की हजारों linesहर incident के लिए 5–10 lines
उद्देश्यकिसी एक run का auditविफलताओं को दोबारा होने से रोकने के लिए precedent base
Secrets का संग्रहtokens हो सकते हैं; सफाई जरूरी हैसख्त निषेध: keys और tokens शामिल नहीं होते
जीवनकालअस्थायी artifactautomation आने तक documentation का स्थायी भाग

MISTAKES.md को छोटा रखना चाहिए ताकि एजेंट session की शुरुआत में उसे पढ़ सके और context window पर अनावश्यक भार न पड़े।


2. गलती की entry की संरचना

हर entry में चार अनिवार्य fields हों:

  1. घटना (Incident): वास्तव में क्या टूटा और किन परिस्थितियों में (error code, command)।
  2. प्रभाव (Impact): उसका परिणाम क्या हुआ (build रुकना, migration खराब होना)।
  3. मूल कारण (Root Cause): समस्या का पुष्ट तकनीकी स्रोत। यदि कारण अभी सिद्ध नहीं है, तो उसे स्पष्ट रूप से [Hypothesis] लिखें।
  4. रोकथाम (Prevention): recurrence रोकने वाली ठोस कार्रवाई।

Entry का उदाहरण

ERR-014: PostgreSQL Migration Failed on DROP COLUMN without CASCADE

  • Incident: Claude Code executed ALTER TABLE orders DROP COLUMN customer_ref; in migration 0042.
  • Impact: Staging deployment failed due to dependent view v_active_orders.
  • Root Cause: Views referencing base tables require explicit cascade recreation or prior view updates.
  • Prevention: All DDL column removal migrations must check dependent views via pg_depend before execution.
> [!IMPORTANT] > **Secrets को अलग रखें**: `MISTAKES.md` में असली connection strings, private keys, tokens या `.env` के fragments कभी न रखें। Claude Code के लिए अपना API Key local environment में configure करें; वह repository में नहीं जाना चाहिए। Claude Code को custom API provider से जोड़ने के लिए अपना Key उपयोग करें और BetterToken की वर्तमान Claude Code guide देखें: [https://docs.bettertoken.ai/ai-tools/claude-code](https://docs.bettertoken.ai/ai-tools/claude-code)। ---

3. Entry को rule या test में बदलने की कसौटी

हर एकबार की typo स्थायी rule की पात्र नहीं होती। Entry को निम्न योजना के अनुसार automated guardrail में बदलें:

graph TD A[Incident occurred] --> B{Error repeated more than once?} B -- No --> C[Keep a MISTAKES.md entry for observation] B -- Yes --> D{Can it be covered by a test or linter?} D -- Yes --> E[Add a unit test / ESLint rule / pre-commit hook] D -- No --> F[Add a strict rule to CLAUDE.md / AGENTS.md] E --> G[Remove or archive the MISTAKES.md entry] F --> G

No

Yes

Yes

No

Incident occurred

Error repeated more than once?

Keep a MISTAKES.md entry for observation

Can it be covered by a test or linter?

Add a unit test / ESLint rule / pre-commit hook

Add a strict rule to CLAUDE.md / AGENTS.md

Remove or archive the MISTAKES.md entry

  1. पहला मामला: MISTAKES.md में छोटी entry जोड़ें।
  2. दूसरा मामला (recurrence): यदि गलती को deterministically पकड़ा जा सकता है, तो linter rule या automated test लिखें। यह text instructions से अधिक भरोसेमंद है।
  3. जब mechanical control संभव न हो: CLAUDE.md में स्पष्ट negative rule लिखें, जैसे: “CI में --runInBand के बिना jest कभी न चलाएँ।”
  4. Archive करना: test या hook लागू होते ही active MISTAKES.md से entry हटाएँ या archive करें, ताकि file अनावश्यक रूप से न बढ़े।

4. अगली task पर सत्यापन

यह सुनिश्चित करने के लिए कि नया guardrail काम करता है:

  1. Claude Code की एक नई, साफ session शुरू करें।
  2. एजेंट को वैसी ही task दें जो पहले दर्ज गलती को trigger करती थी।
  3. जाँचें कि एजेंट instructions को पढ़ता है और prohibition का पालन करता है या नहीं।
  4. यदि एजेंट फिर से rule तोड़ता है, तो CLAUDE.md की भाषा को सख्त करें या check को अनिवार्य pre-commit hook में बदलें।

यह feedback loop अनियमित development failures को project के engineering standards के विश्वसनीय ढाँचे में बदल देता है।

भुगतान और balance top-up

API के लिए balance top-up और भुगतान BetterToken के account dashboard में किए जाते हैं। उपलब्ध विकल्पों और current rates को देखने के लिए pricing page देखें; बदलती कीमत या payment-method availability को documentation में स्थिर तथ्य की तरह न लिखें।

लागत का उदाहरण और rates कैसे जाँचें

किसी request की लागत का हिसाब लगाने के लिए input tokens, output tokens और, जहाँ लागू हो, cached-token usage को अलग रखें; उस समय की लागू दरें BetterToken pricing page से जाँचें। उदाहरण को अनुमान के रूप में रखें और उसे किसी model की वर्तमान rate का दावा न बनाएं।

अपना LLM वर्कफ़्लो बेहतर बनाना चाहते हैं?

एक API से मॉडल जोड़ें, कुंजियाँ प्रबंधित करें और AI खर्च नियंत्रित करें।