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

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

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

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

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

तुमची instruction file ही संदेश आहे, setting नाही

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

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

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

कोणत्या instruction files लोड होतात आणि केव्हा

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

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

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

Loading मधील आणखी एक अडचण आहे. "Agent ने माझ्या instructions कडे दुर्लक्ष केले" असे दिसण्याचे हे सर्वात सामान्य कारण आहे. Claude Code AGENTS.md नव्हे, तर CLAUDE.md वाचतो. AGENTS.md वर standardise केलेल्या आणि CLAUDE.md नसलेल्या repository मधून Claude Code ला लोड करण्यासाठी काहीही मिळत नाही. यासाठी समर्थित bridge म्हणजे CLAUDE.md. त्याची पहिली ओळ @AGENTS.md असते. ही ओळ launch वेळी त्या फाइलचा मजकूर import करते. त्याखाली Claude-specific notes ठेवता येतात. अतिरिक्त मजकूर जोडायचा नसल्यास symlink देखील चालतो. त्या फाइलमध्ये नेमके काय असावे हे ठरवणे हा स्वतंत्र प्रश्न आहे. त्याचे स्पष्टीकरण agent instructions आणि human documentation वेगळी करण्याबाबत दिले आहे.

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

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

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

अधिक ठोस खात्री हवी असल्यास, loads चे log नोंदवा. प्रत्येक वेळी एखादी CLAUDE.md किंवा rules file context मध्ये दाखल झाल्यावर InstructionsLoaded hook event सुरू होते. त्याचा matcher load का झाला हे सांगतो: 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 फक्त निरीक्षण करू शकतो; तो प्रक्रिया थांबवू शकत नाही. ज्या session मध्ये nested file लोड होणे अपेक्षित होते, त्या session च्या log मध्ये ती फाइल दिसत नसेल, तर rewording थांबवा. समस्या file placement मध्ये आहे.

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

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

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

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

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

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

आसपासचा code rule पेक्षा अधिक प्रभावी का ठरतो

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

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

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

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

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

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

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

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

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

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

Size ची समस्याही वेगळ्या रूपात तीच आहे. Claude Code च्या मार्गदर्शनानुसार प्रत्येक instruction file 200 lines पेक्षा कमी असावी आणि अधिक लांब files मुळे adherence कमी होते. 700 lines ची file अधिक ठोस instruction नसते. ती एकमेकांशी विरोध करण्याची अधिक शक्यता असलेल्या 700 दाव्यांची file असते. शिवाय प्रत्येक turn मध्ये ती तुमच्या window विरुद्ध मोजली जाते, त्यामुळे तिचा परिणाम तुमच्या token usage मध्ये थेट दिसतो. प्रत्येक नियम reader ला सहज scan करता येईल अशा heading खाली ठेवून file ची रचना करणे agent कृती करू शकेल अशी instruction file लिहिणे यामध्ये समाविष्ट आहे.

दहा मिनिटांत समस्या कशी शोधावी

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

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

Step 4 साठी एक command पुरेसा आहे. तुम्ही ज्या फाइलमध्ये बदल करत होतात तिथेच नव्हे, तर या विषयाशी संबंधित प्रत्येक 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

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

अंमलबजावणीच्या प्रभावानुसार उपाय

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

1. नियम ठोस करा. एखादा path, command किंवा condition स्पष्टपणे नमूद करा. आधी दाखवल्याप्रमाणे, agent ला repository मध्ये सापडणारे विरुद्ध पुरावेही जोडा. यासाठी कोणताही अतिरिक्त खर्च नाही आणि यामुळे आश्चर्यकारकरीत्या अनेक प्रकरणे सुटतात.
2. नियम ज्या गोष्टीवर लागू होतो तिच्या अधिक जवळ तो ठेवा. Nested CLAUDE.md, .claude/rules/ मधील path-scoped rule किंवा स्वतः file च्या सुरुवातीला असलेली comment वापरा. त्यामुळे नियम आणि तो लागू होणारा code एकाच read मध्ये उपलब्ध होतात. याचा tradeoff स्वीकारा: अशा प्रकारे load केलेली कोणतीही माहिती पुढील compaction वेळी context मधून बाहेर पडते आणि पुढील matching read वेळी परत येते.
3. अंमलबजावणी hook मध्ये हलवा. Prose फक्त विनंती करते. Hook निर्णय घेतो. Hooks निश्चित lifecycle events वेळी code म्हणून चालतात आणि model चा निष्कर्ष काहीही असला तरी लागू होतात.
4. नियम deterministic tool कडे द्या आणि prose काढून टाका. Formatting, import order, line length, बंदी असलेले imports आणि commit message ची रचना यांसाठी ruff format, prettier --write, eslint किंवा pre-commit hook वापरा. Formatter प्रत्येक वेळी योग्य परिणाम देतो आणि त्यासाठी एकही token लागत नाही. 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 कामापेक्षा scripts साठी तो अधिक योग्य आहे.

काय सूचना देऊन टाळता येत नाही

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

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

काही सवयी टिकून राहतात. Comments जोडणे, defensive error handling जोडणे, शेवटी summary लिहिणे आणि लगेच पुढचा स्पष्ट command चालवणे. त्यांना मनाई करणारा नियम असला तरी या सवयी पूर्णपणे नाहीशा होत नाहीत; त्यांचा दर फक्त कमी होतो. तुम्ही स्वतःचा दर मोजू शकता: fresh sessions मध्ये तीच task दहा वेळा चालवा आणि violations मोजा. जिथे हा आकडा zero असणे आवश्यक आहे, तिथे तो नियम prompt मधून काढावा लागतो.

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

Instruction file ही security boundary नाही. ती वर्तनावर परिणाम करते, पण ते enforce करत नाही. चूक झाल्यास मोठा परिणाम होणाऱ्या गोष्टी, जसे credentials किंवा destructive commands, permissions किंवा hook मध्ये ठेवाव्यात. agent पासून secrets दूर ठेवणे हेच तत्त्व data साठी लागू करते: agent ला एखादी file वाचू नको असे सांगू नका; ती file वाचता येणार नाही अशी व्यवस्था करा.

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

FAQ

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

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

सत्राच्या मध्यात instruction file संपादित केल्यास काही बदल होतो का?

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

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

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

माझ्या सूचना /compact नंतरही टिकतात का?

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

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

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