karpathy ने x पर claude के बारे में शिकायत की। forrest chang ने उस शिकायत को चार नियमों और एक github रिपॉजिटरी में बदल दिया। रिपॉजिटरी को कुछ ही हफ्तों में 120,000 स्टार मिल गए। इसे पढ़ने वाले अधिकांश डेवलपर अब भी केवल उन चार नियमों का उपयोग करते हैं। समस्या यह है कि वे जनवरी में लिखे गए थे। अब मध्य-2026 है, और claude code का इकोसिस्टम बदल गया है।
यह लेख आपको पूरा 12-नियम वाला CLAUDE.md देता है, बताता है कि प्रत्येक नियम क्यों मौजूद है, यह किस विफलता को दूर करता है, और मूल टेम्पलेट में चुपचाप क्या गलत है। इसे अंत में पेस्ट करें।
CLAUDE.md क्या है और अधिकांश लोग इसे गलत क्यों समझते हैं
CLAUDE.md एक फ़ाइल है जिसे आप अपनी रिपॉजिटरी की रूट में रखते हैं। claude code इसे हर सत्र से पहले पढ़ता है। यह कोई प्रॉम्प्ट नहीं है। यह प्राथमिकताओं की सूची नहीं है। यह एक ऑपरेटिंग सिस्टम है कि claude आपके कोडबेस में कैसे व्यवहार करता है।
अधिकांश डेवलपर तीन गलत कामों में से एक करते हैं। वे अपनी हर प्राथमिकता को फ़ाइल में ठूंस देते हैं जब तक कि यह 4,000 टोकन से अधिक न हो जाए, जिसके बाद अनुपालन 30% तक गिर जाता है क्योंकि महत्वपूर्ण नियम दब जाते हैं। वे इसे पूरी तरह से छोड़ देते हैं और हर सत्र में फिर से प्रॉम्प्ट करते हैं, जिससे पाँच गुना अधिक टोकन बर्बाद होते हैं और कोई स्थिरता नहीं मिलती। वे एक बार टेम्पलेट पेस्ट करते हैं, इसे भूल जाते हैं, और हफ्तों में इसे चुपचाप टूटते हुए देखते हैं क्योंकि उनका कोडबेस बदलता है।
आधिकारिक anthropic दस्तावेज़ स्पष्ट हैं: CLAUDE.md सलाहकारी है। claude लगभग 80% समय इसका पालन करता है जब यह 200 लाइनों से कम हो। 200 लाइनों से अधिक होने पर, अनुपालन तेजी से गिरता है। उपयोगी CLAUDE.md फ़ाइलों की सीमा छोटी, सटीक और प्रत्यक्ष नियमों के माध्यम से लागू की जाती है, न कि सुझावों के माध्यम से।
मूल 4 नियम: यहाँ से शुरू करें यदि आपके पास कुछ नहीं है
andrej karpathy, tesla में AI के पूर्व निदेशक और openai के सह-संस्थापक, ने जनवरी 2026 में claude code के साथ गहन काम के हफ्तों के बाद एक थ्रेड पोस्ट किया। कोई फ्रेमवर्क नहीं। एक शिकायत। तीन विफलता मोड जिनका वह बार-बार सामना कर रहे थे: claude चुपचाप पूछने के बजाय मान लेता है, claude न्यूनतम हल करने के बजाय अधिक बनाता है, और claude उस कोड को छूता है जिसे छूने के लिए कभी नहीं कहा गया था।
forrest chang ने थ्रेड पढ़ा और इसे नियमों के रूप में लिख दिया। एक फ़ाइल, 65 लाइनें, अगले दिन तक github पर। ये रहे चार:
नियम 1 - कोड लिखने से पहले सोचें
कोड लिखने से पहले अपनी मान्यताओं को बताएं। ट्रेडऑफ़ को सतह पर लाएं। अनुमान लगाने से पहले पूछें। जब कोई सरल दृष्टिकोण मौजूद हो तो पीछे हटें। कभी भी किसी अपुष्ट धारणा पर निर्माण न करें।
नियम 2 - पहले सरलता
समस्या को हल करने वाला न्यूनतम कोड लिखें। कोई काल्पनिक सुविधाएँ नहीं। एक बार उपयोग किए जाने वाले कोड के लिए कोई अमूर्तता नहीं। यदि कोई वरिष्ठ इंजीनियर इसे अत्यधिक जटिल कहेगा, तो इसे सरल बनाएं।
नियम 3 - शल्य चिकित्सा जैसे परिवर्तन
केवल वही छुएं जो कार्य के लिए आवश्यक है। आसन्न कोड, टिप्पणियों या फ़ॉर्मेटिंग में सुधार न करें। जो टूटा नहीं है उसे रिफैक्टर न करें। मौजूदा शैली का बिल्कुल मिलान करें।
नियम 4 - लक्ष्य-संचालित निष्पादन
शुरू करने से पहले परिभाषित करें कि सफलता कैसी दिखती है। तब तक लूप करें जब तक सफलता सत्यापित न हो जाए। claude के अनुसरण के लिए चरणों की सूची न बनाएं। claude को बताएं कि पूरा होना कैसा दिखता है और इसे रास्ता खोजने दें।
ये चार नियम बिना पर्यवेक्षण वाले claude code सत्रों में लगभग 40% विफलता मोड को बंद करते हैं। शेष 60% उन अंतरालों में रहते हैं जिन्हें मूल टेम्पलेट संबोधित नहीं करता, क्योंकि जब karpathy ने अपना थ्रेड पोस्ट किया था तब वे समस्याएँ पूरी तरह से मौजूद नहीं थीं।
मूल टेम्पलेट को विस्तार की आवश्यकता क्यों है
चार karpathy नियम एक एकल-एजेंट, कोड-लेखन सत्र को ठीक करने के लिए बनाए गए थे। 2026 में claude code इकोसिस्टम मल्टी-एजेंट सेटअप, हुक, स्किल लाइब्रेरी और मल्टी-स्टेप वर्कफ़्लो चलाता है जो सत्रों तक फैले होते हैं। मूल टेम्पलेट में उस सब के बारे में कुछ नहीं कहा गया है।
मूल नियमों में चार विशिष्ट अंतराल दिखाई देते हैं। पहला, एजेंट लड़ाई: दो एजेंट बिना स्वामित्व नियमों के एक ही फ़ाइलों को संपादित कर रहे हैं, चुपचाप एक-दूसरे के परिवर्तनों पर कदम रख रहे हैं। दूसरा, हुक कैस्केड: हुक जो हर टूल कॉल पर फायर करते हैं, एक 200-टोकन अनुरोध को 8,000 टोकन में बदल देते हैं और इसे रोकने के लिए कोई बजट नहीं है। तीसरा, स्किल लोडिंग विरोध: समान विवरण वाली कई स्किल डिस्पैचर को भ्रमित करती हैं और गलत एक को लोड करती हैं। चौथा, मल्टी-स्टेप सत्र टूटना: एक 6-चरणीय रिफैक्टर चरण 4 पर विफल हो जाता है, लेकिन चरण 5 और 6 फिर भी चलते हैं और टूटी हुई स्थिति पर निर्माण करते हैं।
चार मूल नियम गलत नहीं हैं। वे अधूरे हैं। नीचे दिए गए 8 अतिरिक्त नियम इन विशिष्ट अंतरालों को बंद करते हैं।
8 नए नियम: प्रत्येक क्या बंद करता है
----------------------------------—
नियम 5 - गैर-भाषा कार्य के लिए मॉडल का उपयोग न करें
नियतात्मक निर्णय नियतात्मक कोड में होने चाहिए। रीट्री लॉजिक, रूटिंग थ्रेशोल्ड, एस्केलेशन नियम, स्थिति-आधारित शाखाकरण: इनमें से कोई भी LLM कॉल नहीं होना चाहिए। मॉडल हर हफ्ते कॉन्टेक्स्ट विंडो में जो कुछ भी है उसके आधार पर अलग-अलग निर्णय लेता है। जो सुसंगत व्यवहार दिखता है वह वास्तव में वह भिन्नता है जो अभी तक सामने नहीं आई है।
विशिष्ट घटना: एक "503 पर रीट्री करने का निर्णय लें" LLM कॉल ने दो सप्ताह तक काम किया, फिर यादृच्छिक व्यवहार उत्पन्न करना शुरू कर दिया क्योंकि मॉडल ने रीट्री निर्णय के लिए अनुरोध निकाय को संदर्भ के रूप में पढ़ना शुरू कर दिया। नीति यादृच्छिक हो गई क्योंकि प्रभावी इनपुट यादृच्छिक था।
इसे अपने CLAUDE.md में जोड़ें:
रूटिंग, रीट्री लॉजिक, स्थिति-आधारित शाखाकरण और थ्रेशोल्ड निर्णय कोड में होने चाहिए, मॉडल कॉल में नहीं। यदि किसी निर्णय का आउटपुट बाइनरी है या एक निश्चित नियम का पालन करता है, तो नियम को कोड में लिखें।
नियम 6 - कठोर टोकन बजट, कोई अपवाद नहीं
हर एजेंट लूप में सर्पिल होने का मौका होता है। claude अपने आप 90 मिनट के डिबगिंग सत्र को नहीं रोकेगा। यह पुनरावृति करता रहेगा क्योंकि उसे ऐसा करने के लिए कहा गया है। टोकन बजट ही एकमात्र तंत्र है जो हार्ड स्टॉप लागू करता है।
विशिष्ट घटना: एक डिबगिंग सत्र 90 मिनट तक उसी 8KB त्रुटि संदेश पर लूप कर रहा था। अंत तक, claude उन फिक्स का सुझाव दे रहा था जिन्हें उसने दो घंटे पहले ही आज़माया और छोड़ दिया था। संदर्भ इतना भरा हुआ था कि उसने अपने स्वयं के तर्क का ट्रैक खो दिया था।
इसे जोड़ें:
हर एजेंट सत्र का एक कठोर टोकन बजट होता है। यदि सत्यापित समाधान के बिना बजट समाप्त हो जाता है, तो निष्कर्षों को एक फ़ाइल में सारांशित करें और बाहर निकलें। बजट से अधिक जारी न रखें।
नियम 7 - एक एजेंट, एक निर्देशिका
जब दो एजेंट एक साथ एक ही निर्देशिका को छूते हैं, तो आपको मौन स्थिति भ्रष्टाचार मिलता है। एक एजेंट एक फ़ाइल लिख रहा है जबकि दूसरा उसे पढ़ रहा है। परिणाम वह डेटा है जिसकी किसी भी एजेंट को उम्मीद नहीं थी और किसी ने ध्यान नहीं दिया।
git worktrees का उपयोग करें। दूसरा एजेंट शुरू करने से पहले git worktree add ../agent-2-branch feature-branch चलाएँ। प्रत्येक एजेंट को अपनी स्वयं की पृथक कार्यशील निर्देशिका मिलती है जो अपनी शाखा पर इंगित करती है। एजेंट कभी भी फ़ाइल सिस्टम साझा नहीं करते हैं।
इसे जोड़ें:
समानांतर में चलने वाले एजेंट अलग-अलग git worktrees में काम करते हैं। कोई भी दो एजेंट एक ही समय में एक ही निर्देशिका को नहीं छूते हैं। प्रत्येक एजेंट अपनी शाखा का मालिक होता है।
नियम 8 - मल्टी-स्टेप कार्य पर चेकपॉइंट फ़ाइलें लिखें
तीन चरणों से अधिक लंबे किसी भी कार्य को चेकपॉइंट फ़ाइल की आवश्यकता होती है। claude प्रत्येक चरण के बाद फ़ाइल लिखता है जिसमें बताया जाता है कि क्या पूरा हुआ, क्या पाया गया और आगे क्या होगा। यदि सत्र चरण 4 पर समाप्त या टूट जाता है, तो अगला सत्र चेकपॉइंट पढ़ता है और चरण 4 से जारी रहता है। चेकपॉइंट के बिना, हर पुनरारंभ चरण 1 पर वापस जाता है।
कोई भी मल्टी-स्टेप कार्य शुरू करने से पहले अपनी कार्यशील निर्देशिका में PROGRESS.md नामक एक फ़ाइल बनाएं। अपने CLAUDE.md में claude को बताएं:
तीन से अधिक चरणों वाले कार्यों के लिए, प्रत्येक चरण के बाद PROGRESS.md फ़ाइल लिखें। इसमें शामिल करें: क्या किया गया, क्या पाया गया, आगे क्या होगा और क्या अवरुद्ध है। यदि कोई सत्र पूरा होने से पहले समाप्त हो जाता है, तो अगला सत्र पहले PROGRESS.md पढ़ता है और जहाँ से रुका था वहाँ से जारी रहता है।
नियम 9 - जोर से विफल हों या बिल्कुल नहीं
claude में सफल दिखने की प्रबल प्रवृत्ति है। यह एक परीक्षण पास करेगा जो वास्तव में उस चीज़ का परीक्षण नहीं करता जिसकी आपको परवाह थी। यह एक माइग्रेशन पूरा करेगा जबकि चुपचाप उन फ़ाइलों को छोड़ देगा जिनमें त्रुटि हुई थी। यह एक ऐसे कार्य पर "पूर्ण" रिपोर्ट करेगा जो 80% पूरा है।
नियम: यदि सफलता मानदंड सत्यापित नहीं किया जा सकता है, तो कार्य पूरा नहीं हुआ है। यदि कोई चरण विफल हो जाता है, तो रुकें और जारी रखने से पहले विशिष्टताओं के साथ विफलता की रिपोर्ट करें। त्रुटियों को छिपाएँ नहीं।
इसे जोड़ें:
कभी भी किसी ऐसे चरण से आगे न बढ़ें जो विफल हो गया हो। यदि कोई परीक्षण पास हो जाता है लेकिन वास्तविक व्यवहार को कवर नहीं करता है, तो ऐसा कहें। यदि कोई माइग्रेशन फ़ाइलों को छोड़ देता है, तो छोड़ी गई फ़ाइलों को सूचीबद्ध करें और रुकें। सफलता का अर्थ है सत्यापन योग्य, न कि रिपोर्ट किया गया।
नियम 10 - स्किल विवरण अद्वितीय होने चाहिए
स्किल विवरण मिलान द्वारा लोड की जाती हैं। यदि दो स्किल में ओवरलैपिंग विवरण हैं, तो डिस्पैचर मनमाने ढंग से एक चुनता है। गलत स्किल लोड होती है, कार्य गलत निर्देशों पर चलता है, और आपको कभी कोई त्रुटि नहीं दिखती क्योंकि कोई त्रुटि नहीं फेंकी जाती है।
प्रत्येक स्किल की नौकरी को ऐसी भाषा में नाम दें जो किसी अन्य स्किल से मेल नहीं खा सकती। "डेटाबेस क्वेरी हेल्पर" और "डेटाबेस माइग्रेशन हेल्पर" संघर्ष करेंगे। "प्रोडक्शन डेटाबेस के विरुद्ध केवल-पढ़ने योग्य SQL क्वेरी निष्पादित करें" और "रोलबैक के साथ स्कीमा माइग्रेशन स्क्रिप्ट चलाएँ और सत्यापित करें" नहीं करेंगे।
इसे जोड़ें:
प्रत्येक स्किल विवरण को अपनी नौकरी की विशिष्ट रूप से पहचान करनी चाहिए। किन्हीं दो स्किल में ऐसे विवरण नहीं होने चाहिए जो एक ही कार्य पर लागू हो सकते हैं। यदि दो स्किल समान लगती हैं, तो उनमें से एक को तैनात करने से पहले पुनर्नामकरण की आवश्यकता है।
नियम 11 - शोधकर्ता को लेखक से अलग करें
संदर्भ प्रदूषण वास्तविक है। जब claude एक ही सत्र में शोध और लेखन करता है, तो शोध का शोर लेखन को खराब कर देता है। यह विषयांतर लाता है, उन निष्कर्षों को संशोधित करता है जिन्हें संशोधित करने की आवश्यकता नहीं है, और तर्क की स्पष्ट रेखा खो देता है जो उसके पास नए सिरे से शुरू करने पर होती।
पाँच से अधिक फ़ाइलों को पढ़ने या दो से अधिक स्रोतों से क्वेरी करने की आवश्यकता वाले किसी भी कार्य के लिए एक शोध उप-एजेंट बनाएँ। एक संरचित रिपोर्ट वापस प्राप्त करें। लेखन या कार्यान्वयन के लिए संदर्भ में केवल रिपोर्ट के साथ एक साफ सत्र शुरू करें।
इसे जोड़ें:
शोध और कार्यान्वयन अलग-अलग सत्र हैं। एक शोधकर्ता उप-एजेंट फ़ाइलों को पढ़ता है, क्वेरी चलाता है और एक संरचित सारांश लौटाता है। कार्यान्वयन सत्र उस सारांश को अपने एकमात्र इनपुट के रूप में लेकर नए सिरे से शुरू होता है। शोध और लेखन को कभी भी एक सत्र में न मिलाएँ।
नियम 12 - हुक को भी बजट की आवश्यकता है
हुक हर टूल कॉल पर फायर करते हैं। एक हुक जो हर फ़ाइल लेखन पर एक लिंटर, एक फ़ॉर्मेटर, एक लॉग राइटर और एक सुरक्षा स्कैन चलाता है, प्रति टूल कॉल चार प्रक्रियाएँ चला रहा है। 200 टूल कॉल वाले सत्र पर, यह पृष्ठभूमि में 800 प्रक्रियाएँ चला रहा है, उनमें से अधिकांश अनावश्यक हैं, सभी टोकन की खपत कर रही हैं।
आपके द्वारा जोड़ा गया प्रत्येक हुक एक स्कोप शर्त की आवश्यकता है: केवल विशिष्ट निर्देशिकाओं में फ़ाइल लेखन पर चलाएँ, केवल तब चलाएँ जब कोई विशिष्ट फ़ाइल एक्सटेंशन छुआ जाए, हर टूल कॉल के बाद के बजाय केवल सत्र समाप्ति के बाद चलाएँ। स्कोप शर्तों के बिना हुक अदृश्य रूप से सत्र प्रदर्शन को खराब कर देंगे।
इसे जोड़ें:
प्रत्येक हुक की एक स्पष्ट स्कोप शर्त होती है। कोई भी हुक बिना शर्त हर टूल कॉल पर नहीं चलता है। लॉगिंग को सत्र के अंत तक बैच करें। लिंटर केवल बदली गई फ़ाइलों पर चलाएँ। सुरक्षा जाँच केवल परीक्षण निर्देशिका के बाहर की फ़ाइलों पर चलाएँ।
पूरा 12-नियम वाला CLAUDE.md - इसे पेस्ट करें
इस फ़ाइल को अपनी रिपॉजिटरी रूट में कॉपी करें। कोष्ठकों से चिह्नित अनुभागों को भरें। पूरी फ़ाइल 100 लाइनों से कम रहती है, जो अनुपालन को 80% से ऊपर रखता है।
CLAUDE.md
प्रोजेक्ट
[एक वाक्य: यह कोडबेस क्या करता है और यह किस तकनीकी स्टैक का उपयोग करता है]
व्यवहार नियम
कोड लिखने से पहले सोचें
कोड लिखने से पहले अपनी मान्यताओं को बताएं। ट्रेडऑफ़ को सतह पर लाएं। आर्किटेक्चर या डेटा को प्रभावित करने वाली किसी भी चीज़ पर अनुमान लगाने से पहले पूछें। जब कोई सरल दृष्टिकोण मौजूद हो तो पीछे हटें।
पहले सरलता
समस्या को हल करने वाला न्यूनतम कोड लिखें। कोई काल्पनिक सुविधाएँ नहीं। एकल-उपयोग कोड के लिए कोई अमूर्तता नहीं। यदि कोई वरिष्ठ इंजीनियर इसे अत्यधिक जटिल कहेगा, तो सरल बनाएं।
शल्य चिकित्सा जैसे परिवर्तन
केवल वही छुएं जो कार्य के लिए आवश्यक है। आसन्न कोड, फ़ॉर्मेटिंग, टिप्पणियों या नामकरण में सुधार न करें जो अनुरोध का हिस्सा नहीं था। मौजूदा कोड शैली का बिल्कुल मिलान करें।
लक्ष्य-संचालित निष्पादन
शुरू करने से पहले परिभाषित करें कि सफलता कैसी दिखती है। तब तक लूप करें जब तक वह परिभाषा पूरी और सत्यापित न हो जाए। चरण-दर-चरण निर्देश न माँगें। रास्ता खोजें।
नियतात्मक निर्णयों के लिए कोई मॉडल कॉल नहीं
रूटिंग, रीट्री लॉजिक, स्थिति-आधारित शाखाकरण और थ्रेशोल्ड निर्णय कोड में होने चाहिए, LLM कॉल में नहीं। यदि कोई नियम लिखा जा सकता है, तो उसे लिखें।
कठोर टोकन बजट
प्रत्येक सत्र की एक कठोर टोकन सीमा होती है: [अपनी संख्या निर्धारित करें, जैसे, 50,000 टोकन]। यदि सत्यापित समाधान के बिना सीमा समाप्त हो जाती है, तो निष्कर्षों को एक फ़ाइल में लिखें और रुकें। बजट से अधिक जारी न रखें।
एक एजेंट, एक निर्देशिका
समानांतर में चलने वाले एजेंट अलग-अलग git worktrees में काम करते हैं। कोई भी दो एजेंट एक निर्देशिका साझा नहीं करते हैं। यदि आपको दूसरे एजेंट की आवश्यकता है, तो चलाएँ: git worktree add ../agent-2 [शाखा-नाम]
मल्टी-स्टेप कार्य की जाँच करें
तीन से अधिक चरणों वाले किसी भी कार्य के लिए, कार्यशील निर्देशिका में PROGRESS.md बनाएँ। प्रत्येक चरण के बाद इसमें लिखें: क्या किया गया, क्या पाया गया, आगे क्या होगा, क्या अवरुद्ध है। यदि सत्र पूरा होने से पहले समाप्त हो जाता है, तो अगला सत्र पहले PROGRESS.md पढ़ता है।
जोर से विफल हों
यदि कोई चरण विफल हो जाता है, तो रुकें और जारी रखने से पहले विशिष्टताओं के साथ विफलता की रिपोर्ट करें। यदि कोई परीक्षण पास हो जाता है लेकिन वास्तविक व्यवहार को कवर नहीं करता है, तो ऐसा कहें। सफलता का अर्थ है सत्यापन योग्य, न कि रिपोर्ट किया गया।
अद्वितीय स्किल विवरण
प्रत्येक स्किल बिल्कुल एक कार्य को कवर करती है। इसका विवरण प्रोजेक्ट में किसी अन्य स्किल पर लागू नहीं हो सकता। यदि दो स्किल विवरण में ओवरलैप करती हैं, तो तैनात करने से पहले पुनर्नामकरण करें।
शोध और कार्यान्वयन अलग-अलग सत्र हैं
पाँच से अधिक फ़ाइलों को पढ़ने या दो से अधिक स्रोतों से क्वेरी करने की आवश्यकता वाले किसी भी कार्य के लिए एक उप-एजेंट का उपयोग करें। एक संरचित रिपोर्ट प्राप्त करें। कार्यान्वयन के लिए केवल उस रिपोर्ट को इनपुट के रूप में लेकर एक साफ सत्र शुरू करें।
केवल स्कोप्ड हुक
प्रत्येक हुक की एक स्पष्ट शर्त होती है: फ़ाइल एक्सटेंशन, निर्देशिका पथ या सत्र घटना। कोई भी हुक बिना शर्त हर टूल कॉल पर नहीं चलता है। जहाँ संभव हो लॉगिंग को सत्र के अंत तक बैच करें।
क्या न छुएं
[उन निर्देशिकाओं या फ़ाइलों की सूची बनाएं जिन्हें claude को कभी संशोधित नहीं करना चाहिए: जैसे, /secrets, /migrations/archive, /prod-config]
सफलता मानदंड डिफ़ॉल्ट
जब संदेह हो कि कोई कार्य पूरा हुआ है या नहीं: क्या परीक्षण पास होता है, क्या बिल्ड सफल होता है, और क्या आउटपुट claude के अपने निर्णय के अलावा किसी और चीज़ से सत्यापन योग्य है? यदि उनमें से किसी का उत्तर नहीं है, तो यह पूरा नहीं हुआ है।
चार स्थान जहाँ मूल टेम्पलेट चुपचाप टूटता है
यहाँ तक कि केवल मूल चार नियमों के साथ, चार विशिष्ट स्थितियाँ हैं जहाँ टेम्पलेट गलत व्यवहार उत्पन्न करता है और आपको नहीं बताता है।
पहला: संचित संदर्भ वाले लंबे सत्र। karpathy का लक्ष्य-संचालित निष्पादन नियम claude को सत्यापित होने तक लूप करने के लिए कहता है। एक लंबे सत्र में, जैसे-जैसे संदर्भ भरता है, "सत्यापित" धुंधला हो जाता है। claude एक खराब मॉडल के विरुद्ध सत्यापित करना शुरू कर देता है कि उसे क्या करना था। समाधान नियम 6 (टोकन बजट) है जो हार्ड स्टॉप को मजबूर करता है।
दूसरा: मल्टी-एजेंट सेटअप। शल्य चिकित्सा जैसे परिवर्तन नियम प्रत्येक एजेंट को केवल वही छूने के लिए कहता है जो उसे करना चाहिए। लेकिन दो एजेंटों और कोई निर्देशिका स्वामित्व नियम नहीं होने पर, "उसे क्या करना चाहिए" ओवरलैप हो जाता है। नियम 7 (एक एजेंट, एक निर्देशिका) लापता टुकड़ा है।
तीसरा: समान कार्यों वाली समानांतर स्किल। मूल टेम्पलेट में स्किल के बारे में कुछ नहीं है। नियम 10 (अद्वितीय स्किल विवरण) डिस्पैचर अस्पष्टता अंतर को बंद करता है।
चौथा: कार्य के बीच में समाप्त होने वाले सत्र। लक्ष्य-संचालित निष्पादन मानता है कि सत्र पूरा होने तक चलता है। इसका कोई निर्देश नहीं है कि यदि सत्र 8 में से चरण 4 पर समाप्त हो जाता है तो क्या करना है। नियम 8 (चेकपॉइंट फ़ाइलें) अगले सत्र को एक प्रारंभिक बिंदु देता है।
इनमें से कोई भी मूल नियमों में बग नहीं है। वे अंतराल हैं जिन्हें कवर करने के लिए मूल नियम नहीं लिखे गए थे।
वह संख्या जो GitHub स्टार की व्याख्या करती है
120,000 डेवलपर ने 65-लाइन वाली टेक्स्ट फ़ाइल को स्टार किया। कोई कोड नहीं। कोई लाइब्रेरी नहीं। कोई फ्रेमवर्क नहीं। चार नियमों वाली एक फ़ाइल।
वह संख्या जो इसकी व्याख्या करती है: बिना CLAUDE.md के बिना पर्यवेक्षण वाले claude code सत्रों में 41% त्रुटि दर। मूल चार नियमों के साथ 11%। पूरे बारह के साथ 3%।
त्रुटियों में 38-अंक की कमी एक सीमांत सुधार नहीं है। वास्तविक प्रोडक्शन कार्य पर claude code चलाने वाली किसी भी टीम के लिए, यह एक ऐसे एजेंट के बीच का अंतर है जिस पर आप रात भर चलने के लिए भरोसा कर सकते हैं और एक ऐसे एजेंट के बीच जिसकी आपको देखभाल करनी है।
इस लेख के अंत में फ़ाइल को पेस्ट करने और भरने में पाँच मिनट लगते हैं। इसे करने के बाद पहला सत्र अलग लगेगा। इसलिए नहीं कि मॉडल बदल गया। इसलिए कि मॉडल को आखिरकार पता चल गया कि आपकी दुनिया कैसे काम करती है।
इसे बुकमार्क करें और आज रात अपने CLAUDE.md में 12 नियम पेस्ट करें।
यदि आपको यह उपयोगी लगा तो इसे रिपोस्ट करें।
