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

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

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

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

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

Instruction file एक संदेश है, न कि सेटिंग

Instruction file configuration नहीं होती है। Runtime में कोई भी चीज़ CLAUDE.md को नहीं पढ़ती है और न ही उसे लागू करती है। Harness डिस्क से फाइल को पढ़ता है और टेक्स्ट को conversation में पेस्ट कर देता है। Claude Code में वह सामग्री एक user message के रूप में डिलीवर की जाती है, जिसे system prompt के बाद रखा जाता है। इसका मतलब है कि model आपके नियमों को उसी तरह देखता है जैसे आपके द्वारा टाइप की गई किसी भी अन्य चीज़ को।

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

आधिकारिक documentation इसे स्पष्ट रूप से कहता है: instruction files को context माना जाता है, न कि लागू की गई configuration। model के निर्णय की परवाह किए बिना किसी action को रोकने के लिए, आपको एक hook की आवश्यकता है, न कि एक वाक्य की। इस बात को ध्यान में रखें। इस पोस्ट के अंत में दिए गए अधिकांश समाधान किसी विशिष्ट मामले पर लागू की गई यही पंक्ति हैं।

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

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

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

यह एक अंतर रिपोर्ट की गई अधिकांश विफलताओं का कारण है। आप 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 है, जो launch के समय फाइल को import करती है, और उसके नीचे Claude से संबंधित कोई भी notes हो सकते हैं। जब आपके पास जोड़ने के लिए कुछ अतिरिक्त न हो तो symlink भी काम करता है। उस फाइल में क्या होना चाहिए, यह तय करना एक अलग प्रश्न है, जिसे human documentation से agent instructions को अलग करना में कवर किया गया है।

फाइल को दोबारा लिखने से पहले उसके लोड होने की पुष्टि करें

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

सेशन के भीतर /context चलाएँ। यह वर्तमान विंडो को श्रेणियों के अनुसार विभाजित करके प्रिंट करता है, और Memory files सूची में उन सभी instruction फाइलों के नाम होते हैं जो वास्तव में लोड हुई हैं। जो फाइल उस सूची में नहीं है, वह बातचीत का हिस्सा नहीं है, इसलिए उसके भीतर आप जो कुछ भी लिखेंगे उसका कोई महत्व नहीं होगा। /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 अनदेखा कर दिया जाता है, इसलिए हुक केवल निरीक्षण कर सकता है, कभी भी ब्लॉक नहीं कर सकता। यदि आपकी नेस्टेड फाइल उस सेशन के दौरान लॉग में कभी दिखाई नहीं देती जहाँ आपने इसकी अपेक्षा की थी, तो दोबारा लिखना बंद कर दें। समस्या फाइल के स्थान (placement) में है।

लंबे सेशन का आपके नियमों पर प्रभाव

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

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

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

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

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

क्यों आसपास का कोड नियम से बेहतर काम करता है

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

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

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

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

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

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

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

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

• जाँचने योग्य नहीं: "फंक्शन्स को छोटा रखें।" जाँचने योग्य: "60 लाइनों से अधिक लंबे फंक्शन के ऊपर एक टिप्पणी होनी चाहिए जिसमें कारण बताया गया हो।"
• जाँचने योग्य नहीं: "अपने बदलावों का परीक्षण करें।" जाँचने योग्य: "npm test चलाएं और कार्य पूरा करने से पहले विफलता की संख्या (failure count) पेस्ट करें।"
• जाँचने योग्य नहीं: "फाइलों को व्यवस्थित रखें।" जाँचने योग्य: "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 का नाम लें। जैसा कि पहले दिखाया गया है, वह counter-evidence जोड़ें जो agent को repository में मिलेगा। यह मुफ्त है और आश्चर्यजनक रूप से कई मामलों को हल कर देता है।
2. इसे उस चीज़ के करीब ले जाएँ जिसे यह नियंत्रित करता है। एक nested CLAUDE.md, .claude/rules/ में path scoped नियम, या स्वयं file के शीर्ष पर एक टिप्पणी। नियम तब उसी समय पढ़ा जाता है जब वह code पढ़ा जाता है जिस पर यह लागू होता है। इस tradeoff को स्वीकार करें: इस तरह load की गई कोई भी चीज़ अगले compaction पर हट जाती है और अगली matching read पर वापस आ जाती है।
3. प्रवर्तन (enforcement) को एक hook में ले जाएँ। गद्य (prose) केवल अनुरोध करता है, जबकि एक hook निर्णय लेता है। Hooks निश्चित lifecycle events पर code के रूप में चलते हैं और model के निष्कर्ष की परवाह किए बिना लागू होते हैं।
4. नियम को एक deterministic tool को सौंपें और गद्य को हटा दें। Formatting, import order, line length, banned imports, commit message का स्वरूप। ruff format, prettier --write, eslint, एक pre-commit hook। Formatter हर बार सही होता है और इसमें zero tokens का खर्च आता है। वाक्य अधिकतर समय सही होता है और हर बार tokens खर्च करता है।

चरण 3 का पूर्ण विवरण। मान लीजिए कि migration files को agent द्वारा कभी भी edit नहीं किया जाना चाहिए। इसे .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 शुरू करें और agent से migrations/ के अंतर्गत किसी file को edit करने के लिए कहें। edit करने से मना कर दिया जाएगा और आपका संदेश कारण के रूप में वापस आएगा। PreToolUse पर exit status 2 tool call को चलने से पहले ही रोक देता है, और आपका stderr text model को blocking message के रूप में दिया जाता है। ${CLAUDE_PROJECT_DIR} project root पर resolve होता है, इसलिए यह hook तब भी काम करता है जब agent किसी भी directory में हो। agent को नियम से सहमत होने, नियम को याद रखने, या नियम को context में रखने की आवश्यकता नहीं है। edit नहीं होता है।

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

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

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

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

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

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

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

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

FAQ

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

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

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

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

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

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

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

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

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

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