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 न समझें:
MISTAKES.md को छोटा रखना चाहिए ताकि एजेंट session की शुरुआत में उसे पढ़ सके और context window पर अनावश्यक भार न पड़े।
2. गलती की entry की संरचना
हर entry में चार अनिवार्य fields हों:
- घटना (Incident): वास्तव में क्या टूटा और किन परिस्थितियों में (error code, command)।
- प्रभाव (Impact): उसका परिणाम क्या हुआ (build रुकना, migration खराब होना)।
- मूल कारण (Root Cause): समस्या का पुष्ट तकनीकी स्रोत। यदि कारण अभी सिद्ध नहीं है, तो उसे स्पष्ट रूप से
[Hypothesis]लिखें। - रोकथाम (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_dependbefore execution.
3. Entry को rule या test में बदलने की कसौटी
हर एकबार की typo स्थायी rule की पात्र नहीं होती। Entry को निम्न योजना के अनुसार automated guardrail में बदलें:
- पहला मामला:
MISTAKES.mdमें छोटी entry जोड़ें। - दूसरा मामला (recurrence): यदि गलती को deterministically पकड़ा जा सकता है, तो linter rule या automated test लिखें। यह text instructions से अधिक भरोसेमंद है।
- जब mechanical control संभव न हो:
CLAUDE.mdमें स्पष्ट negative rule लिखें, जैसे: “CI में--runInBandके बिना jest कभी न चलाएँ।” - Archive करना: test या hook लागू होते ही active
MISTAKES.mdसे entry हटाएँ या archive करें, ताकि file अनावश्यक रूप से न बढ़े।
4. अगली task पर सत्यापन
यह सुनिश्चित करने के लिए कि नया guardrail काम करता है:
- Claude Code की एक नई, साफ session शुरू करें।
- एजेंट को वैसी ही task दें जो पहले दर्ज गलती को trigger करती थी।
- जाँचें कि एजेंट instructions को पढ़ता है और prohibition का पालन करता है या नहीं।
- यदि एजेंट फिर से 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 का दावा न बनाएं।