coding agents तुमच्या सूचना का पाळत नाहीत?

तुमच्या सूचनांकडे coding agents दुर्लक्ष का करतात

coding agents तुमच्या सूचनांकडे चार कारणांमुळे दुर्लक्ष करतात. तुम्ही खूप नम्र होता, हे त्यापैकी एकही कारण नाही. तो नियम context window मध्ये कधीच आला नव्हता. एखाद्या कृतीशी तुलना करता येईल इतका तो नियम अस्पष्ट होता. Context मधील दुसरी गोष्ट त्याच्याशी विरोधात होती; बहुतेकदा agent ने नुकताच वाचलेला code. किंवा नियम अजूनही loaded आहे, पण सध्याच्या turn पासून खूप मागे आहे आणि agent जवळच्या मजकुरावरून काम करत आहे.

प्रत्येक कारणासाठी स्वतंत्र उपाय आहे. त्यामुळे पहिली पायरी म्हणजे ही कारणे वेगळी ओळखणे. Capital letters आणि IMPORTANT हा शब्द वापरणे निदान नाही. खालील कार्यपद्धतीत Claude Code चे उदाहरण घेतले आहे, कारण August 2026 पर्यंत त्याचे loading आणि compaction behaviour सविस्तर documented आहे. इतर tools मधील तपशील वेगळे असू शकतात, पण एकूण वर्तन समान असते.

प्रथम दोन संज्ञा. context window म्हणजे एखाद्या turn मध्ये model ला दिसणारा मजकुराचा संपूर्ण भाग: system prompt, तुमच्या instruction files, conversation आणि agent ने वाचलेली प्रत्येक file. harness म्हणजे model भोवतालचा program; तो disk वरील files वाचतो आणि तो संपूर्ण मजकूर तयार करतो. या post मधील जवळजवळ प्रत्येक तक्रार प्रत्यक्षात model बद्दल नसून harness बद्दल असते.

तुमची instruction file ही message आहे, setting नाही

Instruction file ही configuration नसते. Runtime मधील कोणताही घटक CLAUDE.md वाचून त्याची अंमलबजावणी करत नाही. Harness ही file disk वरून वाचतो आणि तिचा मजकूर conversation मध्ये paste करतो. Claude Code मध्ये हा मजकूर system prompt नंतर ठेवलेल्या user message म्हणून दिला जातो. त्यामुळे model तुमचे नियम तुम्ही टाइप केलेल्या इतर कोणत्याही मजकुराप्रमाणेच पाहतो.

याचा एक अस्वस्थ करणारा परिणाम होतो. Window मधील इतर प्रत्येक मजकुराशी तुमचे नियम समान पातळीवर स्पर्धा करतात. एखादा नियम हा एक दावा असतो. Agent ने नुकतीच उघडलेली file हा पुरावा असतो. दोन्हीमध्ये विसंगती असल्यास पुरावा अनेकदा प्रभावी ठरतो. कोणताही error निर्माण होत नाही, कारण model च्या दृष्टीने काहीही चुकीचे घडलेले नसते.

अधिकृत documentation हे स्पष्टपणे सांगते: instruction files ना enforced configuration म्हणून नव्हे, तर context म्हणून हाताळले जाते. Model ने काहीही ठरवले तरी एखादी action रोखायची असल्यास sentence नव्हे, तर hook आवश्यक असतो. ही ओळ लक्षात ठेवा. या post च्या शेवटी दिलेल्या बहुतेक उपायांमध्ये हीच ओळ विशिष्ट परिस्थितीला लागू केली आहे.

कोणत्या instruction files लोड होतात आणि कधी

Claude Code तुम्ही ज्या directory मधून ते सुरू केले त्या directory पासून directory tree मध्ये वरच्या दिशेने जाते. Filesystem root पासून तुमच्या working directory पर्यंत असलेली प्रत्येक CLAUDE.md आणि CLAUDE.local.md launch वेळी पूर्णपणे लोड होते. ती files त्या क्रमाने एकत्र जोडली जातात. त्यामुळे तुम्ही Claude Code सुरू केलेल्या directoryच्या सर्वात जवळची file शेवटी वाचली जाते. तसेच, एका directoryमध्ये .local file मुख्य file नंतर जोडली जाते.

तुमच्या working directoryच्या खालील subdirectoriesमधील files वेगळ्या पद्धतीने हाताळल्या जातात. त्या launch वेळी लोड होत नाहीत. Agent त्या directoryमधील एखादी file वाचतो तेव्हा त्या लोड होतात. .claude/rules/ मधील paths: frontmatter field असलेल्या path scoped rules बाबतही हेच लागू होते. Matching file वाचली जाते तेव्हा त्या contextमध्ये येतात; प्रत्येक turn वेळी नाही.

नोंदवलेल्या failuresपैकी मोठ्या प्रमाणाचे कारण हा एकच फरक आहे. तुम्ही packages/api/CLAUDE.md मध्ये rule ठेवता, API विषयी प्रश्न विचारता आणि agent packages/api/ अंतर्गत कोणतीही file न उघडता उत्तर देतो. Rule दुर्लक्षित केलेला नव्हता. तो contextमध्ये कधीच आला नव्हता. तुमचे repository monorepoमधील प्रत्येक packageसाठी स्वतंत्र instruction files अशा प्रकारे guidance विभागत असेल, तर प्रत्येक वेळी सर्वप्रथम हे तपासा.

आणखी एक loading trap आहे. "agent ने माझ्या instructionsकडे दुर्लक्ष केले" असे वाटण्याचे हे सर्वात सामान्य कारण आहे: Claude Code AGENTS.md नव्हे, तर CLAUDE.md वाचते. AGENTS.md ला standard मानणाऱ्या repositoryमध्ये CLAUDE.md नसल्यास Claude Code कडे लोड करण्यासाठी काहीही उपलब्ध नसते. यासाठी समर्थित bridge म्हणजे CLAUDE.md. त्याची पहिली ओळ @AGENTS.md असते. ही ओळ launch वेळी संबंधित file import करते; त्याखाली Claude specific notes ठेवता येतात. अतिरिक्त मजकूर जोडायचा नसेल, तर symlink देखील चालते. सुरुवातीपासून त्या fileमध्ये काय ठेवायचे हे वेगळे ठरवावे लागते. याचे वर्णन agent instructions आणि human documentation वेगळे करण्याबाबत केले आहे.

फाइल पुन्हा लिहिण्यापूर्वी ती लोड झाली आहे याची खात्री करा

एजंटला फाइल दिसत असल्याचा पुरावा मिळेपर्यंत मजकुरात बदल करू नका. यासाठी दोन तपासण्या आहेत. त्यापैकी जलद तपासणी आधी करा.

सत्रामध्ये /context चालवा. हे सध्याची विंडो श्रेणीनुसार दाखवते आणि प्रत्यक्षात लोड झालेल्या प्रत्येक सूचना फाइलचे नाव Memory files यादीत देते. एखादी फाइल त्या यादीत नसेल, तर ती संभाषणाचा भाग नाही. त्यामुळे तिच्यामध्ये लिहिलेल्या कोणत्याही मजकुराचा परिणाम होणार नाही. /memory फाइलची स्थाने दाखवते आणि त्या संपादनासाठी उघडते. अद्याप अस्तित्वात नसलेल्या फाइल्सचाही यात समावेश होतो.

अधिक सखोल पडताळणीसाठी लोड होण्याच्या नोंदी ठेवा. प्रत्येक वेळी एखादी CLAUDE.md किंवा rules file context मध्ये येते, तेव्हा InstructionsLoaded hook event सुरू होते. त्याचा matcher लोड का झाले ते दाखवतो: 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"
          }
        ]
      }
    ]
  }
}

या hook ला त्याचा payload standard input वर JSON स्वरूपात मिळतो. त्यामुळे cat संपूर्ण record जोडते. काम करताना tail -f /tmp/instructions-loaded.log वापरून त्याचे निरीक्षण करा. या event चा exit status दुर्लक्षित केला जातो. त्यामुळे हा hook फक्त निरीक्षण करू शकतो; तो प्रक्रिया थांबवू शकत नाही. ज्या सत्रात nested file लोड होणे अपेक्षित होते, त्या सत्रातील log मध्ये ती कधीही दिसली नाही, तर मजकूर पुन्हा लिहिणे थांबवा. समस्या file placement मध्ये आहे.

दीर्घ सत्राचा तुमच्या नियमांवर होणारा परिणाम

येथे दोन स्वतंत्र परिणाम लागू होतात आणि त्यांच्यासाठी वेगवेगळे उपाय आवश्यक आहेत.

अंतर. turn 1 मध्ये सांगितलेला नियम turn 90 पर्यंत window मध्ये असतो. मात्र तो आता अधिक अलीकडील आणि तुम्ही सध्या करत असलेल्या कामाशी अधिक संबंधित असलेल्या 90 turns मधील मजकुराशी स्पर्धा करतो. हे तुम्ही configuration द्वारे दूर करू शकत नाही; मात्र त्याचे मोजमाप करू शकता. तेच काम नव्या session मध्ये चालवा. तेथे नियम लागू होत असेल आणि दीर्घ session मध्ये पुढे जाऊन लागू होत नसेल, तर कारण अंतर आहे.

Compaction. window भरल्यावर harness आतापर्यंतच्या संभाषणाचा सारांश तयार करते आणि त्या सारांशापासून पुढे सुरू ठेवते. सारांशकाराला महत्त्वाचे वाटलेलेच टिकते. ते तुम्हाला महत्त्वाचे वाटणाऱ्या गोष्टींसारखेच असेल असे नाही. Claude Code प्रत्येक mechanism नुसार परिणाम स्पष्ट करते आणि त्यांतील फरक मोठे आहेत. Project root CLAUDE.md आणि unscoped rules compaction नंतर disk वरून पुन्हा inject केले जातात. Auto memory disk वरून पुन्हा inject केली जाते. paths: frontmatter असलेले rules जुळणारी file पुन्हा read होईपर्यंत गमावले जातात. Subdirectories मधील nested CLAUDE.md files त्या subdirectory मधील एखादी file पुन्हा read होईपर्यंत गमावल्या जातात.

तुमच्या instructions ची त्या तक्त्यानुसार क्रमवारी लावा; त्यातून fragility चा क्रम स्पष्ट होतो. तुम्ही फक्त chat मध्ये टाइप केलेला rule हा session मधील सर्वांत नाजूक घटक आहे. सारांशात तो राहिला तरच तो टिकतो. packages/api/CLAUDE.md मधील rule त्यानंतर येतो, कारण तो एकदा load होतो, सारांशात गमावला जाऊ शकतो आणि त्या directory मध्ये पुढच्या read वेळीच परत येतो. Project root file मधील rule सर्वांत टिकाऊ असतो, कारण तो प्रत्येक वेळी disk वरून पुन्हा read केला जातो.

म्हणून एखादा instruction संपूर्ण session मध्ये लागू राहणे आवश्यक असल्यास, तो paths: frontmatter नसलेल्या project root file मध्ये असावा. इतर सर्व बाबतीत तुम्ही जाणीवपूर्वक tradeoff ठरवावा. Context window मध्ये काय टिकून राहते याचे व्यवस्थापन या विषयात /compact साठी focus argument आणि असंबंधित tasks मधील /clear यांवर भर दिला आहे. या दोन्ही गोष्टींमुळे सारांशकाराला तुमचे rules काय होते हे ठरवण्याची वारंवारता बदलते.

सभोवतालचा कोड नियमावर मात का करतो

ही अशी चूक आहे जिचे वर्णन लोक सर्वाधिक करतात, पण निदान सर्वात कमी वेळा करतात. तुमच्या फाइलमध्ये database access repository layer मधून होतो असे नमूद आहे. Agent असा handler लिहितो जो ORM (object relational mapper) ला थेट call करतो. Style च्या कारणास्तव तुमच्याकडे दुर्लक्ष झालेले नसते. उपलब्ध पुराव्याने तुमच्या नियमाला मागे टाकलेले असते.

नियम एखादे प्राधान्य सांगतो. कोड त्याचे एक उदाहरण दाखवतो. Agent ज्या module मध्ये बदल करणार आहे त्यातील तीन फाइल्स उघडतो आणि तिन्ही फाइल्स ORM ला थेट call करत असतील, तर context मध्ये एका बाजूला एक abstract वाक्य आणि दुसऱ्या बाजूला अलीकडची, task शी जुळणारी तीन ठोस उदाहरणे असतात. स्थानिक pattern ची नक्कल करणे हे सहसा योग्य behaviour असते. येथे ते चुकीचे ठरते, कारण context ला माहीत नसलेली एक गोष्ट तुम्हाला माहीत असते: त्या फाइल्स legacy आहेत.

म्हणून ती माहिती नियमात लिहा. स्वतःच्या counter-evidence चा उल्लेख करणारे नियम वास्तविक repository मध्ये टिकतात. केवळ preference सांगणारे नियम टिकत नाहीत.

नवीन database access app/repositories/ मधून करा. app/legacy/ अंतर्गत असलेल्या फाइल्स अजूनही ORM ला थेट call करतात. तो जुना code आहे; तो pattern नाही. त्याची नक्कल करू नका.

हे काम दुसरे वाक्य करते. Agent ला ते code सापडण्यापूर्वीच, त्याला काय सापडणार आहे आणि ते कसे समजून घ्यायचे हे ते सांगते. तुमच्या repository मध्ये स्पष्टपणे विरोधाभास दाखवणाऱ्या कोणत्याही नियमासाठी हीच दुरुस्ती लागू होते: तुमच्या history मध्ये न पाळली जाणारी commit style, तुमच्या suite पैकी निम्म्याने दुर्लक्षित केलेली test layout किंवा केवळ नवीन code मध्ये लागू असलेली import convention. जिथे code आणि फाइलमध्ये विसंगती असेल, तिथे ती विसंगती फाइलमध्ये स्पष्टपणे नमूद करा.

अस्पष्ट नियम तपासता येत नाही, त्यामुळे त्याचे पालनही करता येत नाही

"स्वच्छ कोड लिहा." "अनावश्यकपणे गुंतागुंतीची रचना करू नका." "ते सोपे ठेवा." "Migrations करताना काळजी घ्या." यांपैकी कोणताही नियम एखाद्या विशिष्ट कृतीच्या आधारे agent किंवा तुम्ही तपासू शकत नाही. Agent ला स्वतःच्या output विरुद्ध तपासता न येणारा नियम दिल्यास तो अंदाज लावतो आणि तुम्ही त्या अंदाजाचे मूल्यमापन ठोस निकषांऐवजी जाणिवेवर करता.

तुमच्या file मधील प्रत्येक ओळीला हा test लागू करा. नियम मोडल्यावर non-zero exit होईल अशी shell command लिहा. ती command लिहिता येत नसेल, तर तो नियम checkable नाही. या जोड्यांची तुलना करा:

• Checkable नाही: "Functions लहान ठेवा." Checkable: "60 lines पेक्षा मोठ्या function च्या वर ती इतकी मोठी का आहे हे स्पष्ट करणारी comment आवश्यक आहे."
• Checkable नाही: "तुमचे बदल test करा." Checkable: "Task पूर्ण झाल्याचे सांगण्यापूर्वी npm test चालवा आणि failure count द्या."
• Checkable नाही: "Files व्यवस्थित ठेवा." Checkable: "HTTP handlers src/api/handlers/ मध्येच असतात. त्या directory मध्ये इतर काहीही ठेवू नका."
• Checkable नाही: "Code योग्य प्रकारे format करा." Checkable: ".ts files मध्ये 2 space indentation वापरा."

"अनावश्यकपणे गुंतागुंतीची रचना करू नका" हा नियम लोक सर्वप्रथम सोडून देतात, कारण त्याची दुरुस्ती लहान वाक्य नसते, तर मोठे वाक्य असते: प्रत्यक्षात काम करणारा सर्वात लहान बदल म्हणजे काय, हे स्पष्टपणे लिहिल्यास agent स्वतःच्या diff विरुद्ध तपासता येतील असे निकष मिळतात.

Size ची समस्या वेगळ्या रूपात दिसते. Claude Code च्या guidance मध्ये प्रत्येक instruction file 200 lines पेक्षा कमी ठेवण्याचे लक्ष्य दिले आहे आणि मोठ्या files मुळे adherence कमी होते, हे स्पष्टपणे नमूद केले आहे. 700 lines ची file अधिक ठोस instruction नसते. ती एकमेकांशी विरोध करण्याची अधिक शक्यता असलेल्या 700 claims ची file असते. तसेच प्रत्येक turn मध्ये ती तुमच्या window वर मोजली जाते आणि हे तुमच्या token usage मध्ये थेट दिसते. प्रत्येक rule reader सहज scan करू शकेल अशा heading खाली ठेवून file ची रचना करणे agent कृती करू शकेल अशी instruction file लिहिणे यात समाविष्ट आहे. याहून चांगले म्हणजे वर्णन करणारे, instruction न देणारे भाग काढून टाका: handlers आणि models कुठे आहेत याचा directory tour हा agent repository च्या parsed map मधून गरजेनुसार पाहू शकतो. त्यामुळे तो प्रत्येक turn मध्ये ही माहिती window मध्ये ठेवण्याची गरज राहत नाही.

दहा मिनिटांत समस्येचे निदान कसे करावे

खालील कमांड या क्रमाने चालवा. शेवटच्या टप्प्यावर थेट जाण्यामुळे मोठी नियमांची फाइल तयार होते, पण समस्या तरीही सुटत नाही.

1. ते लोड झाले आहे का ते तपासा. /context चालवा आणि Memory files यादी वाचा. फाइल तेथे नसेल, तर तिचे स्थान दुरुस्त करा आणि थांबा. या यादीतील इतर कोणतीही पायरी अद्याप लागू होत नाही.
2. नवीन session मध्ये पुन्हा समस्या निर्माण करून पाहा. नवीन session सुरू करा आणि नियम लागू व्हायला हवा असे सर्वात लहान task द्या. दीर्घ session मध्ये नियम लागू होत असेल, पण येथे अपयशी ठरत असेल, तर संदर्भापासूनचे अंतर किंवा compaction कारणीभूत असू शकते. येथेही अपयश आल्यास समस्या स्वतः नियमात आहे.
3. स्पर्धक सूचना काढून टाका. विद्यमान code आधीच त्या नियमाचे पालन करत असलेल्या directory मध्ये तोच बदल करण्यास सांगा. नियमाचे पालन पुन्हा सुरू झाल्यास, आजूबाजूचा code तुमच्या वाक्यापेक्षा अधिक प्रभावी ठरला होता.
4. विरोधाभास शोधा. एकाच वर्तनासाठी दोन files मध्ये वेगवेगळ्या सूचना असणे ही नोंदवलेली failure condition आहे: model यांपैकी एक सूचना मनमानीपणे निवडू शकते आणि तसे केल्याचे तुम्हाला सांगणार नाही.
5. नियम तपासता येण्यासारखा करा आणि पुन्हा चाचणी घ्या. ठोस path आणि condition वापरून नियम पुन्हा लिहा. नियमाचे पालन मोठ्या प्रमाणात वाढल्यास, कारण मांडणीमध्ये होते.

Step 4 साठी एकच command आवश्यक आहे. तुम्ही संपादित करत असलेल्या file पुरते मर्यादित न राहता, विषयासाठी प्रत्येक instruction source मध्ये शोधा:

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

वेगवेगळ्या गोष्टी सांगणाऱ्या दोन files मध्ये hit आढळणे हीच तुमची bug आहे. त्यांपैकी एक delete करा. अधिक कडक शब्द वापरून त्यांना क्रम देण्याचा प्रयत्न करू नका, कारण त्यासाठी कोणतेही ranking engine उपलब्ध नाही.

उपाय, परिणामकारकतेच्या क्रमाने

खालील प्रत्येक पायरी तिच्या वरील पायरीपेक्षा अधिक परिणामकारक आहे आणि ती मांडण्यासाठी अधिक खर्च येतो. एखादा नियम पुन्हा स्पष्टपणे लिहिणे स्वस्त असेल, तर वरच्या पायरीपासून सुरुवात करा. एखादा नियम इतका महत्त्वाचा असेल की अधूनमधून होणाऱ्या चुकाही स्वीकारता येणार नाहीत, तेव्हा पुढच्या पायरीवर जा.

1. नियम ठोस करा. एखादा path, command किंवा condition स्पष्टपणे नमूद करा. आधी दाखवल्याप्रमाणे, repository मध्ये agent ला सापडणारे विरोधी पुरावेही द्या. यासाठी कोणताही अतिरिक्त खर्च येत नाही आणि आश्चर्यकारक प्रमाणातील प्रकरणे यामुळे सुटतात.
2. नियम ज्या गोष्टीवर लागू होतो तिच्या अधिक जवळ तो ठेवा. Nested CLAUDE.md, .claude/rules/ मधील path-scoped rule किंवा file च्या सुरुवातीला असलेली comment वापरा. त्यामुळे rule ज्या code वर लागू होतो त्याच read मध्ये तो उपलब्ध होतो. यातील तडजोड स्वीकारा: अशा प्रकारे load केलेली कोणतीही माहिती पुढील compaction वेळी context मधून काढली जाते आणि पुढील matching read वेळी परत येते.
3. Enforcement hook मध्ये हलवा. Prose विनंती करते. Hook निर्णय घेतो. Hooks निश्चित lifecycle events वेळी code म्हणून चालतात आणि model कोणता निष्कर्ष काढतो याची पर्वा न करता लागू होतात.
4. नियम deterministic tool कडे द्या आणि prose काढून टाका. Formatting, import order, line length, banned imports आणि commit message ची रचना यांसाठी ruff format, prettier --write, eslint किंवा pre-commit hook वापरा. Formatter प्रत्येक वेळी योग्य निकाल देतो आणि त्यासाठी शून्य tokens लागतात. Sentence बहुतेक वेळा योग्य असते, पण प्रत्येक turn वेळी 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 नाकारला जाईल आणि कारण म्हणून तुमचा message परत येईल. PreToolUse वरील exit status 2 tool call चालण्यापूर्वीच तो थांबवतो आणि तुमचा stderr text blocking message म्हणून model कडे पाठवतो. ${CLAUDE_PROJECT_DIR} project root कडे resolve होतो, त्यामुळे agent कोणत्या directory मध्ये असेल याची पर्वा न करता hook कार्य करतो. Agent ला या नियमाशी सहमत असण्याची, तो नियम लक्षात ठेवण्याची किंवा तो अजून context मध्ये असण्याची गरज नाही. Edit होत नाही.

कोणतेही logic नसलेल्या सरळ prohibition साठी, settings मधील permissions.deny हेच काम करते आणि maintain करण्यासाठी script ची गरज राहत नाही. तुमची परवानगी न मागता काय चालवायचे हे permission modes ठरवतात. एखादी instruction user message ऐवजी system prompt स्तरावरच असणे खरोखर आवश्यक असल्यास, --append-system-prompt ती तेथे ठेवतो. मात्र तो प्रत्येक invocation वेळी pass करावा लागतो, त्यामुळे interactive work पेक्षा scripts साठी तो अधिक योग्य आहे.

तुम्ही सूचनांनी काय दूर करू शकत नाही

यातील कोणता भाग तुमच्या नियंत्रणात आहे, हे स्पष्ट ठेवा. Placement, phrasing, files मधील conflicts आणि file size या लेखकाच्या समस्या आहेत आणि त्यांच्यासाठी लेखकानेच सुधारणा कराव्या लागतात. उरलेला भाग model behaviour आहे. अधिक चांगली wording केल्याने तो दूर होणार नाही.

Agreement म्हणजे compliance नाही. Agent एखादा rule मान्य करेल, तो तुम्हाला योग्य रीतीने पुन्हा सांगेल आणि दोन tool calls नंतर तो मोडेल. त्या acknowledgement साठी कोणताही प्रयत्न लागत नाही आणि त्यावरून पुढील वर्तनाचा अंदाज येत नाही. त्याला सुधारणा समजू नका आणि test म्हणूनही मोजू नका.

काही सवयी टिकून राहतात. Comments जोडणे, defensive error handling जोडणे, शेवटी summary लिहिणे आणि obvious next command चालवणे यांसारख्या सवयी rule ने प्रतिबंधित केल्यानंतरही परत दिसतात. त्यांचे प्रमाण शून्य होत नाही; ते कमी होते. स्वतःचा rate मोजण्यासाठी तेच task fresh sessions मध्ये दहा वेळा चालवा आणि violations मोजा. जिथे ही संख्या शून्य असणे आवश्यक आहे, तिथे तो rule prompt मधून काढावा लागतो. कामाचा काही भाग अजून बाकी असताना job finished म्हणणे हीदेखील याच प्रकारची सवय आहे. तिच्यासाठी verbal सुधारणा पुरेशी नाही. रचना बदलावी लागते: unlazy skill त्या sentence ऐवजी Depth Tree वापरते आणि agent ने done म्हणण्यापूर्वी clear करावयाच्या gate files वापरते.

तुमचे स्वतःचे session उदाहरण बनते. Agent ने turn 12 वर rule मोडला आणि तुम्ही ते तसेच जाऊ दिले, तर तो violation context मध्ये demonstration म्हणून राहतो आणि rule पेक्षा तो अधिक अलीकडचा असतो. Violation दिसताच तो दुरुस्त करा. दुरुस्ती न केलेला violation session च्या उर्वरित भागाला तोच नमुना शिकवतो.

Instruction file ही security boundary नाही. ती behaviour ला दिशा देते; enforcement करत नाही. ज्या गोष्टी चुकल्यास मोठे नुकसान होऊ शकते, जसे credentials किंवा destructive commands, त्या permissions किंवा hook मध्ये हाताळल्या पाहिजेत. Keeping secrets out of reach of an agent हाच principle data वर लागू करते: agent ला file वाचू नको असे सांगू नका; ती file वाचता येणार नाही अशी व्यवस्था करा.

थोडक्यात: file load झाल्याचा पुरावा द्या, rule तपासता येईल असा करा, तो ज्या गोष्टीवर लागू होतो तिच्या जवळ ठेवा आणि miss rate अजूनही महत्त्वाचा असेल, तर तो prose मधून काढा. Agent ज्याकडे दुर्लक्ष करू शकत नाही, असा rule agent कडून कधी मागितलाच गेला नव्हता.

FAQ

Claude Code माझी CLAUDE.md का दुर्लक्षित करतो?

ती दुर्लक्षित झाली असे गृहीत धरण्यापूर्वी ती लोड झाली आहे का ते तपासा. /context चालवा आणि Memory files सूची पहा; ज्या फाइलचे नाव तेथे नाही, ती conversation मध्ये समाविष्ट नाही. Instruction files या system prompt नंतर user message म्हणून दिल्या जातात आणि enforced configuration ऐवजी context म्हणून हाताळल्या जातात. त्यामुळे त्यांचे काटेकोर पालन होईल याची हमी नसते. प्रत्यक्षातील बहुतेक प्रकरणे चारपैकी एक असतात: फाइल अशा subdirectory मध्ये असते जिथून agent ने कधीही वाचलेले नसते, दोन फाइल्समध्ये मतभेद असतात आणि model त्यांपैकी एक अनियोजितपणे निवडतो, नियम इतका अस्पष्ट असतो की एखाद्या कृतीशी त्याची पडताळणी करता येत नाही, किंवा आसपासचा code त्या नियमाच्या विरुद्ध उदाहरण दाखवतो.

session सुरू असताना instruction file संपादित केल्याने काही बदल होतो का?

conversation मध्ये आधीच समाविष्ट असलेल्या प्रतिकृतीवर नाही. तुमच्या working directory वरील फाइल्स launch वेळी पूर्णपणे लोड होतात. त्यामुळे model कडे असलेला मजकूर launch वेळेचा असतो. केलेला बदल लागू करण्यासाठी नवीन session सुरू करा किंवा agent ला त्याच्या नेहमीच्या file tools वापरून फाइल वाचण्यास सांगा. त्यामुळे सध्याची आवृत्ती fresh message म्हणून conversation मध्ये येते. compaction नंतर project root file disk वरून पुन्हा वाचली जाते. त्यामुळे त्या वेळी नवीन आवृत्तीही येते.

root CLAUDE.md आणि nested फाइलमध्ये मतभेद असल्यास कोणती फाइल लागू होते?

विश्वसनीयपणे कोणतीही नाही. सापडलेल्या फाइल्स एकमेकींवर override करण्याऐवजी context मध्ये concatenate केल्या जातात. त्यांचा क्रम filesystem root पासून working directory पर्यंत असतो. त्यामुळे सर्वात जवळची फाइल फक्त शेवटी वाचली जाते. विरोधाभास सोडवणारे precedence engine नाही. Claude Code च्या documentation नुसार contradictory rules अनियोजितपणे सोडवले जाऊ शकतात. Nested फाइल्समध्ये त्या कोणत्या path ला लागू आहेत हे स्पष्ट करून अतिरिक्त नियम लिहा. एखाद्या नियमाला इतरांपेक्षा वरचढ करण्याचा प्रयत्न करण्याऐवजी विरोधाभास काढून टाका.

माझ्या instructions /compact नंतर टिकतात का?

त्या कशा लोड झाल्या यावर ते अवलंबून असते. Project root CLAUDE.md, unscoped rules आणि auto memory compaction नंतर disk वरून पुन्हा inject केले जातात. paths: frontmatter असलेले rules आणि subdirectories मधील nested CLAUDE.md files matching file पुन्हा वाचली जाईपर्यंत हरवतात. तुम्ही chat मध्ये फक्त टाइप केलेली कोणतीही गोष्ट summariser ने ठेवली असेल तरच टिकते. एखादा नियम संपूर्ण session मध्ये लागू राहणे आवश्यक असल्यास, तो project root file मध्ये paths: frontmatter शिवाय ठेवा.

एखादा नियम prose ऐवजी hook कधी बनवावा?

पडताळणी deterministic असेल आणि ती न झाल्याची किंमत लहान script लिहिण्याच्या किंमतीपेक्षा जास्त असेल तेव्हा. File path restrictions, commit करण्यापूर्वी आवश्यक commands आणि forbidden tool calls या सर्वांसाठी hook योग्य आहे. PreToolUse hook status 2 ने exit झाल्यास tool call थेट block होतो आणि stderr मधील मजकूर कारण म्हणून model कडे परत पाठवला जातो. त्यामुळे तो नियम context मध्ये अजूनही आहे की नाही यावर अवलंबून राहत नाही. Formatter किंवा linter ठरवू शकणारी कोणतीही गोष्ट त्या tool कडे सोपवा आणि instruction file मधून पूर्णपणे काढून टाका.