कोडिंग एजेंट्स निर्देशों की अनदेखी क्यों करते हैं?

कोडिंग एजेंट्स आपके निर्देशों की अनदेखी क्यों करते हैं

कोडिंग एजेंट्स आपके निर्देशों की अनदेखी चार कारणों से करते हैं, और इनमें से कोई भी कारण यह नहीं है कि आप बहुत विनम्र थे। नियम कभी भी context window में था ही नहीं। नियम इतना अस्पष्ट था कि किसी क्रिया की उसके विरुद्ध जाँच नहीं की जा सकी। context में किसी अन्य चीज़ ने इसका खंडन किया, आमतौर पर वह कोड जिसे एजेंट ने अभी-अभी पढ़ा था। या फिर नियम अभी भी लोड है लेकिन वर्तमान टर्न से बहुत पीछे है, और एजेंट उस जानकारी पर काम कर रहा है जो उसके करीब है।

प्रत्येक कारण का अपना समाधान है, इसलिए पहला काम उनमें अंतर करना है। बड़े अक्षर और IMPORTANT शब्द कोई निदान नहीं हैं। नीचे दी गई कार्यप्रणाली में Claude Code का उदाहरण के रूप में उपयोग किया गया है, क्योंकि अगस्त 2026 तक इसके लोडिंग और कॉम्पैक्शन व्यवहार का विस्तार से दस्तावेजीकरण किया गया है। अन्य टूल्स विवरण में भिन्न हो सकते हैं लेकिन रूपरेखा में समान व्यवहार करते हैं।

सबसे पहले दो शब्द। context window टेक्स्ट का वह ब्लॉक है जिसे मॉडल एक निश्चित टर्न पर देखता है: system prompt, आपकी instruction files, बातचीत, और एजेंट द्वारा पढ़ी गई प्रत्येक फाइल। harness मॉडल के चारों ओर का प्रोग्राम है, वह चीज़ जो डिस्क से फाइलें पढ़ती है और उस ब्लॉक को इकट्ठा करती है। इस पोस्ट में लगभग हर शिकायत वास्तव में मॉडल के बारे में नहीं, बल्कि harness के बारे में है।

आपका instruction file एक संदेश है, न कि कोई सेटिंग

एक instruction file कॉन्फ़िगरेशन नहीं होती है। रनटाइम में कोई भी चीज़ CLAUDE.md को नहीं पढ़ती और न ही उसे लागू करती है। हार्नेस डिस्क से फ़ाइल को पढ़ता है और टेक्स्ट को बातचीत में पेस्ट कर देता है। Claude Code में वह सामग्री एक यूजर मैसेज के रूप में डिलीवर की जाती है जिसे सिस्टम प्रॉम्प्ट के बाद रखा जाता है, जिसका अर्थ है कि मॉडल आपके नियमों को उसी तरह देखता है जैसे वह आपके द्वारा टाइप की गई किसी भी अन्य चीज़ को देखता है।

इसका एक असहज परिणाम यह होता है कि आपके नियम विंडो में मौजूद हर दूसरे टेक्स्ट के साथ समान स्तर पर प्रतिस्पर्धा करते हैं। एक नियम केवल एक दावा है। जिस फ़ाइल को एजेंट ने अभी खोला है, वह साक्ष्य (evidence) है। जब दोनों में असहमति होती है, तो अक्सर साक्ष्य जीत जाता है, और कोई त्रुटि (error) नहीं आती है, क्योंकि मॉडल के दृष्टिकोण से कुछ भी गलत नहीं हुआ है।

आधिकारिक दस्तावेज़ इसे स्पष्ट रूप से कहते हैं: instruction files को संदर्भ (context) माना जाता है, न कि लागू किया गया कॉन्फ़िगरेशन। मॉडल के निर्णय की परवाह किए बिना किसी कार्रवाई को रोकने के लिए, आपको एक हुक की आवश्यकता है, न कि एक वाक्य की। उस पंक्ति को ध्यान में रखें। इस पोस्ट के अंत में दिए गए अधिकांश समाधान किसी विशिष्ट मामले पर लागू की गई वही पंक्ति हैं।

कौन सी instruction files लोड होती हैं, और कब

Claude Code उस directory से ऊपर की ओर directory tree में जाता है जहाँ से आपने इसे शुरू किया था। filesystem root से आपकी working directory तक की हर CLAUDE.md और CLAUDE.local.md लॉन्च के समय पूरी तरह लोड हो जाती है। वे इसी क्रम में concatenate की जाती हैं, इसलिए जहाँ से आपने लॉन्च किया है उसके सबसे करीब वाली फाइल सबसे अंत में पढ़ी जाती है, और एक ही directory के भीतर .local फाइल को मुख्य फाइल के बाद जोड़ा जाता है।

आपकी working directory के नीचे वाली subdirectories में मौजूद फाइलें अलग तरह से व्यवहार करती हैं। वे लॉन्च के समय लोड नहीं होतीं। वे तब लोड होती हैं जब agent उस directory में किसी फाइल को पढ़ता है। .claude/rules/ में path scoped rules के साथ भी ऐसा ही है जिनमें paths: frontmatter field होता है: वे हर turn पर नहीं, बल्कि तब context में आते हैं जब कोई matching फाइल पढ़ी जाती है।

यह एक अंतर रिपोर्ट की गई अधिकांश विफलताओं का कारण बताता है। आप packages/api/CLAUDE.md में एक rule डालते हैं, आप API के बारे में कोई सवाल पूछते हैं, और agent packages/api/ के तहत कोई फाइल खोले बिना ही जवाब दे देता है। rule को ignore नहीं किया गया था। वह कभी मौजूद ही नहीं था। यदि आपकी repository monorepo में प्रति पैकेज instruction files के माध्यम से मार्गदर्शन को विभाजित करती है, तो हर बार सबसे पहले यही जाँचें।

लोडिंग का एक और जाल, और यह "agent ने मेरे निर्देशों को ignore किया" का सबसे सामान्य संस्करण है: Claude Code CLAUDE.md पढ़ता है, AGENTS.md नहीं। एक repository जो AGENTS.md पर मानकीकृत है और जिसमें कोई CLAUDE.md नहीं है, वह Claude Code को लोड करने के लिए कुछ भी नहीं देती है। समर्थित bridge एक CLAUDE.md है जिसकी पहली पंक्ति @AGENTS.md है, जो लॉन्च के समय फाइल को import करती है, और उसके नीचे Claude से संबंधित कोई भी notes होते हैं। जब आपके पास जोड़ने के लिए कुछ अतिरिक्त न हो तो एक symlink भी काम करता है। उस फाइल में क्या होना चाहिए, यह तय करना एक अलग प्रश्न है, जिसे human documentation से agent निर्देशों को अलग करना में कवर किया गया है।

Rewrite करने से पहले पुष्टि करें कि फ़ाइल लोड हो गई है

जब तक आपके पास यह प्रमाण न हो कि एजेंट फ़ाइल को देख सकता है, तब तक शब्दों में कोई बदलाव न करें। इसके लिए दो जाँचें हैं, और पहली जाँच सरल है।

सेशन के भीतर /context चलाएँ। यह वर्तमान विंडो को श्रेणियों के अनुसार विभाजित करके प्रिंट करता है, और Memory files सूची में उन सभी निर्देश फ़ाइलों के नाम होते हैं जो वास्तव में लोड हुई हैं। यदि कोई फ़ाइल उस सूची में नहीं है, तो वह बातचीत का हिस्सा नहीं है, इसलिए उसके भीतर आप जो कुछ भी लिखेंगे उसका कोई महत्व नहीं होगा। /memory फ़ाइल के स्थानों को सूचीबद्ध करता है और उन्हें संपादन के लिए खोलता है, जिनमें वे फ़ाइलें भी शामिल हैं जो अभी तक मौजूद नहीं हैं।

अधिक सटीक उत्तर के लिए, लोड को लॉग करें। InstructionsLoaded हुक इवेंट हर बार तब ट्रिगर होता है जब कोई CLAUDE.md या नियम फ़ाइल कॉन्टेक्स्ट में प्रवेश करती है, और इसका मैचर आपको बताता है कि लोड क्यों हुआ: session_start, nested_traversal, path_glob_match, include, या compact। इसे .claude/settings.json में रखें:

{
  "hooks": {
    "InstructionsLoaded": [
      {
        "matcher": "nested_traversal",
        "hooks": [
          {
            "type": "command",
            "command": "cat >> /tmp/instructions-loaded.log"
          }
        ]
      }
    ]
  }
}

हुक अपने पेलोड को standard input पर JSON के रूप में प्राप्त करता है, इसलिए cat पूरे रिकॉर्ड को append करता है। काम करते समय इसे tail -f /tmp/instructions-loaded.log के साथ मॉनिटर करें। इस इवेंट के exit status को अनदेखा कर दिया जाता है, इसलिए हुक केवल देख सकता है, कभी ब्लॉक नहीं कर सकता। यदि आपका नेस्टेड फ़ाइल उस सत्र के दौरान लॉग में कभी दिखाई नहीं देता है जहाँ आपने इसकी अपेक्षा की थी, तो rewording बंद कर दें। समस्या फ़ाइल के स्थान (placement) में है।

लंबे सेशन का आपके रूल्स पर क्या प्रभाव पड़ता है

यहाँ दो अलग-अलग प्रभाव लागू होते हैं, और उनके लिए अलग-अलग प्रतिक्रियाओं की आवश्यकता होती है।

दूरी (Distance)। टर्न 1 पर दिया गया कोई रूल टर्न 90 पर भी विंडो में रहता है, लेकिन अब यह 90 टर्न के उस टेक्स्ट के साथ प्रतिस्पर्धा करता है जो अधिक हालिया है और आपके वर्तमान कार्य के लिए अधिक विशिष्ट है। आप इसे कॉन्फ़िगरेशन के माध्यम से ठीक नहीं कर सकते, लेकिन आप इसे माप सकते हैं। एक नए सेशन में वही कार्य चलाएँ। यदि रूल वहाँ काम करता है और लंबे सेशन में गहराई पर जाकर विफल हो जाता है, तो इसका कारण दूरी है।

कॉम्पैक्शन (Compaction)। जब विंडो भर जाती है, तो हार्नेस अब तक की बातचीत का सारांश (summarise) तैयार करता है और उस सारांश से आगे बढ़ता है। जो बचता है वह वही है जिसे समराइज़र ने महत्वपूर्ण माना है, जो कि आपके द्वारा महत्वपूर्ण माने गए तथ्यों से अलग हो सकता है। Claude Code प्रत्येक मैकेनिज्म के अनुसार परिणाम को डॉक्यूमेंट करता है, और इनमें काफी अंतर होता है। प्रोजेक्ट रूट CLAUDE.md और अनस्कोप किए गए रूल्स को कॉम्पैक्शन के बाद डिस्क से फिर से इंजेक्ट किया जाता है। ऑटो मेमोरी को डिस्क से फिर से इंजेक्ट किया जाता है। paths: फ्रंटमैटर वाले रूल्स तब तक खो जाते हैं जब तक कि कोई संबंधित फाइल दोबारा न पढ़ी जाए। सब-डायरेक्टरी में मौजूद नेस्टेड CLAUDE.md फाइलें तब तक खो जाती हैं जब तक कि उस सब-डायरेक्टरी की कोई फाइल दोबारा न पढ़ी जाए।

अपने निर्देशों को उस टेबल के अनुसार रैंक करें और आपको उनकी नाजुकता (fragility) का क्रम पता चल जाएगा। जो रूल आपने केवल चैट में टाइप किया है, वह सेशन में सबसे नाजुक चीज है: यह केवल तभी बना रहता है यदि सारांश ने इसे गलती से रख लिया हो। packages/api/CLAUDE.md में मौजूद रूल इसके बाद आता है, क्योंकि इसे एक बार लोड किया गया, सारांश में हटा दिया गया, और यह केवल उस डायरेक्टरी में अगली बार पढ़ने पर ही वापस आता है। प्रोजेक्ट रूट फाइल में मौजूद रूल सबसे अधिक टिकाऊ होता है, क्योंकि इसे हर बार डिस्क से दोबारा पढ़ा जाता है।

इसलिए, यदि किसी निर्देश को पूरे सेशन के दौरान लागू रहना है, तो उसे बिना किसी paths: फ्रंटमैटर के प्रोजेक्ट रूट फाइल में होना चाहिए। बाकी सब कुछ एक ट्रेड-ऑफ है जिसे आपको सोच-समझकर करना चाहिए। कॉन्टेक्स्ट विंडो में क्या बना रहता है, इसे मैनेज करना /compact को फोकस आर्ग्युमेंट के साथ और /clear को असंबंधित कार्यों के बीच कवर करता है, ये दोनों ही इस बात को बदलते हैं कि समराइज़र को आपके रूल्स के बारे में निर्णय लेने का मौका कितनी बार मिलता है।

कोड का मौजूदा नियम से बेहतर होना

यह वह विफलता है जिसका वर्णन लोग सबसे अधिक करते हैं और निदान सबसे कम। आपकी फाइल कहती है कि डेटाबेस एक्सेस repository लेयर के माध्यम से होता है। एजेंट एक ऐसा हैंडलर लिखता है जो सीधे ORM (object relational mapper) को कॉल करता है। आपकी बात को स्टाइल के आधार पर नजरअंदाज नहीं किया गया था। साक्ष्यों ने आपके तर्क को पीछे छोड़ दिया।

एक नियम केवल प्राथमिकता बताता है। कोड एक प्राथमिकता को प्रदर्शित करता है। जब एजेंट उस मॉड्यूल में तीन फाइलें खोलता है जिसे वह एडिट करने वाला है और तीनों सीधे ORM को कॉल करती हैं, तो संदर्भ में एक तरफ एक अमूर्त वाक्य होता है और दूसरी तरफ तीन ठोस, हालिया और कार्य के अनुरूप उदाहरण होते हैं। स्थानीय पैटर्न की नकल करना आमतौर पर सही व्यवहार है। यह यहाँ केवल इसलिए गलत है क्योंकि आप कुछ ऐसा जानते हैं जो संदर्भ नहीं जानता: वे फाइलें legacy हैं।

इसलिए इसे नियम में लिखें। जो नियम अपने स्वयं के विपरीत साक्ष्यों का उल्लेख करते हैं, वे वास्तविक रिपॉजिटरी के साथ तालमेल बिठा पाते हैं। जो नियम केवल एक कोरी प्राथमिकता बताते हैं, वे ऐसा नहीं कर पाते।

नया डेटाबेस एक्सेस app/repositories/ के माध्यम से होना चाहिए। app/legacy/ के अंतर्गत आने वाली फाइलें अभी भी सीधे ORM को कॉल करती हैं। वह पुराना कोड है, पैटर्न नहीं। उसकी नकल न करें।

दूसरा वाक्य मुख्य काम करता है। यह एजेंट को बताता है कि वह क्या खोजने वाला है और उसे कैसे पढ़ना है, इससे पहले कि वह उसे खोजे। यही सुधार किसी भी ऐसे नियम पर लागू होता है जिसका आपका रिपॉजिटरी स्पष्ट रूप से खंडन करता है: एक कमिट स्टाइल जिसका आपका इतिहास पालन नहीं करता, एक टेस्ट लेआउट जिसे आपकी आधी सूट अनदेखा करती है, या एक इम्पोर्ट कन्वेंशन जो केवल नए कोड में लागू होता है। जहाँ भी कोड फाइल के साथ असहमत हो, उस असहमति का नाम फाइल में ही लिखें।

अस्पष्ट नियमों की जाँच नहीं की जा सकती, इसलिए उनका पालन नहीं किया जा सकता

"साफ कोड लिखें।" "ओवर-इंजीनियरिंग न करें।" "इसे सरल रखें।" "माइग्रेशन के समय सावधान रहें।" इनमें से किसी भी नियम को किसी विशिष्ट क्रिया के विरुद्ध टेस्ट नहीं किया जा सकता, न तो एजेंट द्वारा और न ही आपके द्वारा। जिस एजेंट को ऐसा नियम दिया जाता है जिसकी वह अपने आउटपुट के विरुद्ध जाँच नहीं कर सकता, वह केवल अनुमान लगा रहा होता है, और आप उस अनुमान को अपनी भावना के आधार पर परख रहे होते हैं।

यहाँ वह टेस्ट है जिसे आपको अपनी फाइल की हर लाइन पर लागू करना चाहिए। वह शेल कमांड लिखें जो नियम टूटने पर non-zero exit कोड दे। यदि आप वह कमांड नहीं लिख सकते, तो नियम की जाँच संभव नहीं है। इन जोड़ों की तुलना करें:

• जाँच योग्य नहीं: "फंक्शन्स को छोटा रखें।" जाँच योग्य: "60 लाइनों से बड़े फंक्शन के ऊपर एक कमेंट होना चाहिए जिसमें कारण बताया गया हो।"
• जाँच योग्य नहीं: "अपने बदलावों को टेस्ट करें।" जाँच योग्य: "npm test चलाएं और किसी कार्य को पूरा बताने से पहले फेलियर काउंट पेस्ट करें।"
• जाँच योग्य नहीं: "फाइलों को व्यवस्थित रखें।" जाँच योग्य: "HTTP हैंडलर्स src/api/handlers/ में रहते हैं। उस डायरेक्टरी में और कुछ नहीं जाना चाहिए।"
• जाँच योग्य नहीं: "कोड को सही ढंग से फॉर्मेट करें।" जाँच योग्य: ".ts फाइलों में 2 स्पेस इंडेंटेशन का उपयोग करें।"

"ओवर-इंजीनियरिंग न करें" वह नियम है जिसे लोग सबसे पहले छोड़ देते हैं, क्योंकि इसका समाधान छोटा वाक्य नहीं बल्कि एक लंबा वाक्य है: सबसे छोटे काम करने वाले बदलाव का अर्थ स्पष्ट करना एजेंट को ऐसे मानदंड देता है जिसके विरुद्ध वह अपने diff की जाँच कर सकता है।

आकार भी वही समस्या है, बस उसका रूप अलग है। Claude Code का मार्गदर्शन प्रति इंस्ट्रक्शन फाइल 200 लाइनों से कम रखने का सुझाव देता है और सीधे तौर पर कहता है कि लंबी फाइलें अनुपालन (adherence) को कम करती हैं। 700 लाइनों की फाइल कोई अधिक ठोस निर्देश नहीं है। यह 700 लाइनों के दावे हैं जिनमें एक-दूसरे का खंडन करने की संभावना अधिक है, और यह हर टर्न पर आपकी विंडो के विरुद्ध चार्ज होता है, जो सीधे आपके टोकन उपयोग में दिखाई देता है। फाइल को इस तरह व्यवस्थित करना कि प्रत्येक नियम एक हेडिंग के नीचे हो जिसे पाठक स्कैन कर सके, ऐसी इंस्ट्रक्शन फाइल लिखना जिस पर एजेंट कार्य कर सके में कवर किया गया है।

इसे दस मिनट में डायग्नोस कैसे करें

इन्हें क्रम में चलाएं। अंतिम चरण पर सीधे जाने से ही लोग ऐसे नियमों की लंबी सूची बना लेते हैं जो काम नहीं करते।

1. पुष्टि करें कि यह लोड हो गया है। /context चलाएं और Memory फाइलों की सूची पढ़ें। यदि फाइल वहां नहीं है, तो लोकेशन ठीक करें और रुक जाएं। इस सूची की कोई अन्य बात अभी लागू नहीं होती।
2. एक नए सेशन में इसे दोहराएं। एक नया सेशन शुरू करें और वह सबसे छोटा कार्य दें जो नियम को ट्रिगर करना चाहिए। यदि यहां काम कर रहा है लेकिन लंबे सेशन में विफल हो रहा है, तो इसका मतलब है कि समस्या दूरी या कॉम्पैक्शन (compaction) की है। यदि यहां भी विफल हो रहा है, तो इसका मतलब है कि समस्या स्वयं नियम में है।
3. प्रतिस्पर्धा हटाएं। उसी बदलाव के लिए ऐसी डायरेक्टरी में कहें जिसका मौजूदा कोड पहले से ही नियम का पालन करता है। यदि अनुपालन (compliance) वापस आ जाता है, तो आसपास का कोड आपके निर्देश को ओवरराइड कर रहा था।
4. संघर्ष (conflict) खोजें। एक ही व्यवहार के लिए दो फाइलें अलग-अलग निर्देश दे रही हों तो यह एक ज्ञात विफलता है: मॉडल मनमाने ढंग से किसी एक को चुन सकता है, और वह आपको बताएगा भी नहीं।
5. इसे जांचने योग्य बनाएं और पुनः परीक्षण करें। नियम को एक ठोस पाथ और शर्त के साथ फिर से लिखें। अनुपालन में बड़ी वृद्धि का मतलब है कि समस्या शब्दों के चयन में थी।

चरण 4 केवल एक कमांड है। केवल उस फाइल के लिए नहीं जिसे आप एडिट कर रहे थे, बल्कि विषय के लिए हर निर्देश स्रोत को grep करें:

grep -rni "migration" --include="CLAUDE.md" --include="CLAUDE.local.md" .
grep -rni "migration" .claude/rules/ ~/.claude/CLAUDE.md ~/.claude/rules/ 2>/dev/null

दो फाइलों में एक ही विषय पर अलग-अलग निर्देश मिलना ही आपका बग है। एक को हटा दें। उन्हें अधिक मजबूत शब्दों के साथ रैंक करने का प्रयास न करें, क्योंकि अपील करने के लिए कोई रैंकिंग इंजन नहीं है।

प्रभाव के आधार पर सुधार के उपाय

नीचे दिए गए प्रत्येक चरण का प्रभाव अपने ऊपर वाले चरण से अधिक है, और इसे सेटअप करने में अधिक लागत आती है। जब किसी नियम को फिर से लिखना सस्ता हो, तो ऊपर से शुरुआत करें। जैसे ही कोई नियम इतना महत्वपूर्ण हो जाए कि उसमें कभी-कभार होने वाली चूक भी स्वीकार्य न हो, तो नीचे की ओर बढ़ें।

1. नियम को ठोस बनाएँ। किसी path, command या condition का नाम लें। जैसा कि पहले दिखाया गया है, repository में एजेंट को मिलने वाले counter-evidence को जोड़ें। यह मुफ्त है और आश्चर्यजनक रूप से कई मामलों को ठीक कर देता है।
2. इसे उस चीज़ के करीब ले जाएँ जिसे यह नियंत्रित करता है। एक nested CLAUDE.md, .claude/rules/ में path-scoped नियम, या स्वयं file के शीर्ष पर एक टिप्पणी। नियम तब उसी समय पढ़ा जाता है जब वह कोड पढ़ा जाता है जिस पर यह लागू होता है। इस समझौते को स्वीकार करें: इस तरह लोड की गई कोई भी चीज़ अगले compaction पर हट जाती है और अगली बार matching read होने पर वापस आ जाती है।
3. प्रवर्तन (enforcement) को एक hook में ले जाएँ। गद्य (prose) केवल अनुरोध करता है। एक hook निर्णय लेता है। Hooks निश्चित lifecycle events पर कोड के रूप में चलते हैं और मॉडल के निष्कर्ष की परवाह किए बिना लागू होते हैं।
4. नियम को एक deterministic tool को सौंपें और गद्य को हटा दें। Formatting, import order, line length, banned imports, commit message का आकार। ruff format, prettier --write, eslint, एक pre-commit hook। Formatter हर बार सही होता है और इसमें शून्य tokens का खर्च आता है। वाक्य अधिकतर समय सही होता है और हर बार tokens खर्च करता है।

चरण 3 का पूर्ण विवरण। मान लीजिए कि migration files को एजेंट द्वारा कभी भी संपादित नहीं किया जाना चाहिए। इसे .claude/settings.json में रखें:

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

और इसे .claude/hooks/guard-migrations.sh में रखें:

#!/usr/bin/env bash
set -euo pipefail

path=$(jq -r '.tool_input.file_path // empty')

case "$path" in
  */migrations/*)
    echo "Files under migrations/ are written by hand. Stop and ask first." >&2
    exit 2
    ;;
esac

exit 0

chmod +x .claude/hooks/guard-migrations.sh चलाएँ, फिर एक नया session शुरू करें और एजेंट को migrations/ के अंतर्गत किसी file को संपादित करने के लिए कहें। संपादन को अस्वीकार कर दिया जाएगा और आपका संदेश कारण के रूप में वापस आएगा। PreToolUse पर exit status 2 टूल कॉल को चलने से पहले ही रोक देता है, और आपका stderr text मॉडल को blocking message के रूप में दिया जाता है। ${CLAUDE_PROJECT_DIR} project root पर resolve होता है, इसलिए यह hook तब भी काम करता है जब एजेंट किसी भी directory में हो। एजेंट को नियम से सहमत होने, नियम को याद रखने, या संदर्भ में नियम को बनाए रखने की आवश्यकता नहीं है। संपादन नहीं होता है।

बिना किसी तर्क वाली सीधी मनाही के लिए, आपकी settings में permissions.deny वही काम करता है, जिसमें बनाए रखने के लिए कोई script नहीं होती, और permission modes यह तय करते हैं कि आपसे पूछे बिना क्या चलना है। यदि किसी निर्देश को वास्तव में user message के बजाय system prompt स्तर पर होना चाहिए, तो --append-system-prompt उसे वहाँ रखता है, हालाँकि इसे हर invocation पर पास किया जाना चाहिए, जो interactive काम की तुलना में scripts के लिए अधिक उपयुक्त है।

जिन निर्देशों को आप हटा नहीं सकते

यह स्पष्ट रखें कि इसमें से कौन सा हिस्सा आपका है। प्लेसमेंट, वाक्यांश, फाइलों के बीच टकराव और फाइल का आकार लेखक की समस्याएं हैं जिन्हें लेखक ही ठीक कर सकता है। बाकी सब मॉडल का व्यवहार है, और बेहतर शब्दों के प्रयोग से यह नहीं बदलेगा।

सहमति का अर्थ अनुपालन नहीं है। एक एजेंट किसी नियम को स्वीकार करेगा, उसे आपको सही ढंग से दोहराएगा, और दो टूल कॉल के बाद उसे तोड़ देगा। स्वीकृति की कोई कीमत नहीं होती और यह कुछ भी सुनिश्चित नहीं करती। इसे सुधार न मानें और न ही इसे किसी परीक्षण के रूप में गिनें।

कुछ आदतें स्थायी होती हैं। टिप्पणियाँ जोड़ना, रक्षात्मक त्रुटि प्रबंधन (defensive error handling) जोड़ना, समापन सारांश लिखना, अगला स्पष्ट कमांड चलाना। ये सब उन नियमों के बावजूद वापस आ जाते हैं जो इन्हें मना करते हैं, हालांकि इनकी दर शून्य के बजाय कम हो जाती है। आप अपनी दर को माप सकते हैं: एक ही कार्य को दस बार नए सत्रों में चलाएं और उल्लंघनों की गिनती करें। जहां उस संख्या का शून्य होना आवश्यक है, वहां नियम को प्रॉम्प्ट से हटा देना चाहिए।

आपका अपना सत्र एक उदाहरण बन जाता है। यदि एजेंट ने टर्न 12 पर नियम तोड़ा और आपने उसे जाने दिया, तो वह उल्लंघन अब संदर्भ (context) में एक प्रदर्शन के रूप में बैठ जाता है, और यह नियम की तुलना में बहुत अधिक हालिया है। उल्लंघन को देखते ही उसे सुधारें। एक बिना सुधारा गया उल्लंघन बाकी सत्र को गलत सीख देता है।

एक निर्देश फाइल सुरक्षा सीमा नहीं है। यह व्यवहार को आकार देती है, उसे लागू नहीं करती। कोई भी ऐसी चीज जहां चूक महंगी हो, जैसे क्रेडेंशियल्स या विनाशकारी कमांड, उसे अनुमतियों (permissions) या हुक में रखा जाना चाहिए। एजेंट की पहुंच से सीक्रेट्स को दूर रखना डेटा पर भी यही सिद्धांत लागू करता है: एजेंट से किसी फाइल को न पढ़ने के लिए न कहें, बल्कि ऐसी व्यवस्था करें कि फाइल पढ़ने योग्य ही न हो।

संक्षिप्त संस्करण। यह साबित करें कि फाइल लोड हो गई है, नियम को जांचने योग्य बनाएं, उसे उस चीज के बगल में ले जाएं जिसे वह नियंत्रित करता है, और जब चूक की दर अभी भी मायने रखती हो, तो उसे गद्य (prose) से बाहर निकाल दें। जिस नियम को एजेंट अनदेखा नहीं कर सकता, वह ऐसा नियम है जिसे कभी एजेंट से पूछा ही नहीं गया था।

FAQ

Claude Code मेरी CLAUDE.md को अनदेखा क्यों करता है?

यह मान लेने से पहले कि इसे अनदेखा किया गया है, जाँचें कि क्या यह लोड हुआ है। /context चलाएँ और Memory files सूची देखें; जो फ़ाइल वहाँ नहीं है, वह बातचीत (conversation) का हिस्सा नहीं है। निर्देश फ़ाइलें सिस्टम प्रॉम्प्ट के बाद एक उपयोगकर्ता संदेश के रूप में भेजी जाती हैं और इन्हें लागू कॉन्फ़िगरेशन के बजाय संदर्भ (context) के रूप में माना जाता है, इसलिए अनुपालन की कोई सख्त गारंटी नहीं है। अधिकांश वास्तविक मामले इन चार कारणों में से एक होते हैं: फ़ाइल किसी ऐसी सबडायरेक्टरी में है जिसे एजेंट ने कभी नहीं पढ़ा, दो फ़ाइलें आपस में विरोधाभासी हैं और मॉडल ने मनमाने ढंग से एक को चुन लिया, नियम इतना अस्पष्ट है कि किसी क्रिया की जाँच नहीं की जा सकती, या आसपास का कोड नियम के विपरीत व्यवहार प्रदर्शित करता है।

क्या सत्र के बीच में निर्देश फ़ाइल को संपादित करने से कुछ बदलता है?

बातचीत में पहले से मौजूद कॉपी के लिए नहीं। आपकी वर्किंग डायरेक्टरी के ऊपर की फ़ाइलें लॉन्च के समय पूरी तरह लोड हो जाती हैं, इसलिए मॉडल के पास मौजूद टेक्स्ट लॉन्च के समय वाला ही रहता है। संपादन को लागू करने के लिए, एक नया सत्र शुरू करें, या एजेंट को उसके सामान्य फ़ाइल टूल के साथ फ़ाइल पढ़ने के लिए कहें, जो वर्तमान संस्करण को एक नए संदेश के रूप में बातचीत में डाल देता है। कॉम्पैक्शन (compaction) के बाद प्रोजेक्ट रूट फ़ाइल को डिस्क से फिर से पढ़ा जाता है, इसलिए उस समय नया संस्करण भी आ जाता है।

जब रूट CLAUDE.md और नेस्टेड CLAUDE.md में असहमति हो तो कौन सी फ़ाइल प्रभावी होती है?

कोई भी नहीं, निश्चित रूप से। खोजी गई फ़ाइलों को एक-दूसरे के ऊपर ओवरराइड करने के बजाय संदर्भ में जोड़ा (concatenate) जाता है, जो फ़ाइल सिस्टम रूट से आपकी वर्किंग डायरेक्टरी तक क्रमबद्ध होती हैं, इसलिए सबसे करीबी फ़ाइल को अंत में पढ़ा जाता है। विरोधाभासों को हल करने के लिए कोई प्राथमिकता इंजन नहीं है, और Claude Code का दस्तावेज़ीकरण बताता है कि विरोधाभासी नियमों को मनमाने ढंग से हल किया जा सकता है। नेस्टेड फ़ाइलों को ऐसे अतिरिक्त निर्देशों के रूप में लिखें जो उस पथ का नाम बताते हैं जिसे वे नियंत्रित करती हैं, और किसी नियम को प्राथमिकता देने की कोशिश करने के बजाय विरोधाभासी नियम को हटा दें।

क्या मेरे निर्देश /compact के बाद भी बने रहते हैं?

यह इस पर निर्भर करता है कि वे कैसे लोड हुए थे। प्रोजेक्ट रूट CLAUDE.md, अनस्कोप किए गए नियम और ऑटो मेमोरी को कॉम्पैक्शन के बाद डिस्क से फिर से इंजेक्ट किया जाता है। paths: फ्रंटमैटर वाले नियम और सबडायरेक्टरी में मौजूद CLAUDE.md फ़ाइलें तब तक खो जाती हैं जब तक कि कोई मिलान वाली फ़ाइल फिर से न पढ़ी जाए। आपने जो कुछ भी केवल चैट में टाइप किया है, वह तभी बना रहता है यदि समराइज़र (summariser) ने उसे सुरक्षित रखा हो। यदि कोई नियम पूरे सत्र में बना रहना चाहिए, तो उसे बिना किसी paths: फ्रंटमैटर के प्रोजेक्ट रूट फ़ाइल में रखें।

किसी नियम को गद्य (prose) के बजाय हुक (hook) कब बनाना चाहिए?

जब जाँच नियतात्मक (deterministic) हो और चूकने की लागत एक छोटा स्क्रिप्ट लिखने की लागत से अधिक हो। फ़ाइल पथ प्रतिबंध, कमिट से पहले आवश्यक कमांड, और निषिद्ध टूल कॉल सभी इसके अंतर्गत आते हैं। एक PreToolUse हुक जो स्टेटस 2 के साथ बाहर निकलता है, वह टूल कॉल को पूरी तरह से ब्लॉक कर देता है और आपके stderr टेक्स्ट को कारण के रूप में मॉडल को वापस भेज देता है, इसलिए यह बना रहता है चाहे नियम संदर्भ में कहीं भी हो या न हो। जो कुछ भी एक फॉर्मेटर या लिंटर तय कर सकता है, उसे उस टूल द्वारा नियंत्रित किया जाना चाहिए और निर्देश फ़ाइल से पूरी तरह हटा दिया जाना चाहिए।