Coding agents మీ సూచనలను ఎందుకు పట్టించుకోవు?

మీ coding agents మీ సూచనలను ఎందుకు పట్టించుకోవు

Coding agents మీ సూచనలను పట్టించుకోకపోవడానికి నాలుగు కారణాలు ఉన్నాయి. వాటిలో మీరు మర్యాదగా వ్యవహరించారనేది ఏదీ కాదు. ఆ నియమం context window లోకి ఎప్పుడూ రాలేదు. లేదా ఆ నియమం చాలా అస్పష్టంగా ఉండటంతో, దాని ఆధారంగా ఒక చర్యను తనిఖీ చేయలేకపోయారు. లేదా context లోని మరేదైనా విషయం దానికి విరుద్ధంగా ఉంది; సాధారణంగా agent అప్పుడే చదివిన code కారణంగా ఇది జరుగుతుంది. లేదా ఆ నియమం ఇంకా load అయి ఉంది, కానీ ప్రస్తుత turn కు చాలా దూరంగా ఉండటంతో agent సమీపంలోని విషయాల ఆధారంగా పనిచేస్తోంది.

ప్రతి కారణానికి ప్రత్యేక పరిష్కారం ఉంటుంది. అందువల్ల మొదటి పని ఈ కారణాలను వేరు చేయడం. పెద్ద అక్షరాలు లేదా IMPORTANT అనే పదం ఉపయోగించడం ద్వారా కారణం నిర్ధారించబడదు. క్రింద వివరించే విధానం Claude Code ను ఉదాహరణగా ఉపయోగిస్తుంది. ఎందుకంటే August 2026 నాటికి దాని loading మరియు compaction ప్రవర్తనపై విస్తృత documentation అందుబాటులో ఉంది. ఇతర tools లో వివరాలు మారవచ్చు, కానీ ప్రధానంగా అవి ఇదే విధంగా పనిచేస్తాయి.

ముందుగా రెండు పదాలు. context window అంటే ఒక నిర్దిష్ట turn లో model చూసే text block. ఇందులో system prompt, మీ instruction files, conversation మరియు agent చదివిన ప్రతి file ఉంటాయి. harness అంటే model చుట్టూ పనిచేసే program. Disk నుంచి files చదివి ఆ text block ను సమీకరించేది ఇదే. ఈ post లోని దాదాపు ప్రతి ఫిర్యాదు వాస్తవానికి model గురించి కాదు, harness గురించి ఉంటుంది.

మీ instruction file ఒక message, setting కాదు

Instruction file configuration కాదు. Runtime లో ఏదీ CLAUDE.md ను చదివి అమలు చేయదు. Harness disk నుంచి ఆ file ను చదివి, దాని text ను conversation లో paste చేస్తుంది. Claude Code లో ఆ content system prompt తర్వాత ఉంచిన user message గా పంపబడుతుంది. అందువల్ల model మీరు టైప్ చేసిన ఇతర విషయాలను చూసినట్టే మీ rules ను కూడా చూస్తుంది.

దీనికి ఒక అసౌకర్యకరమైన పరిణామం ఉంది. Window లోని ప్రతి ఇతర text తో మీ rules సమాన స్థాయిలో పోటీ పడతాయి. Rule అనేది ఒక claim. Agent ఇప్పుడే తెరిచిన file evidence. ఈ రెండింటి మధ్య విభేదం వచ్చినప్పుడు evidence తరచుగా గెలుస్తుంది. Model దృష్టిలో ఏ తప్పూ జరగలేదు కాబట్టి ఎటువంటి error కూడా కనిపించదు.

Official documentation దీన్ని స్పష్టంగా చెబుతుంది: instruction files ను enforced configuration గా కాకుండా context గా పరిగణిస్తారు. Model ఏ నిర్ణయం తీసుకున్నా ఒక action ను నిరోధించాలంటే sentence కాదు, hook అవసరం. ఆ పంక్తిని గుర్తుంచుకోండి. ఈ post చివరలో ఉన్న చాలా fixes, నిర్దిష్ట సందర్భానికి వర్తింపజేసిన అదే పంక్తి.

ఏ instruction files లోడ్ అవుతాయి, ఎప్పుడు

Claude Code మీరు ప్రారంభించిన directory నుంచి directory tree లో పైకి వెళ్తుంది. Filesystem root నుంచి మీ working directory వరకు ఉన్న ప్రతి CLAUDE.md మరియు CLAUDE.local.md launch సమయంలో పూర్తిగా లోడ్ అవుతుంది. అవి అదే క్రమంలో కలపబడతాయి. అందువల్ల మీరు Claude Code ను ప్రారంభించిన స్థానానికి దగ్గరగా ఉన్న 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 సమయంలో కాదు.

Reported failures లో పెద్ద భాగాన్ని ఈ ఒక్క తేడా వివరిస్తుంది. మీరు packages/api/CLAUDE.md లో ఒక rule ఉంచి, API గురించి ప్రశ్న అడుగుతారు. Agent packages/api/ కింద ఉన్న file ను తెరవకుండానే సమాధానం ఇస్తుంది. ఆ rule విస్మరించబడలేదు. అది ఎప్పుడూ context లోకి రాలేదు. మీ repository monorepo లో ప్రతి package కోసం instruction files గా guidance ను విభజిస్తే, ప్రతిసారీ ముందుగా ఇదే తనిఖీ చేయాలి.

ఇంకొక loading సమస్య ఉంది. “agent నా instructions ను విస్మరించింది” అనే పరిస్థితిలో ఇది అత్యంత సాధారణ కారణం. Claude Code AGENTS.md ను కాదు, CLAUDE.md ను చదువుతుంది. AGENTS.md ను ప్రామాణీకరించిన repository లో CLAUDE.md లేకపోతే, Claude Code లోడ్ చేయడానికి ఏమీ ఉండదు. దీనికి మద్దతు ఉన్న bridge ఒక CLAUDE.md. దాని మొదటి line @AGENTS.md అయి ఉండాలి. ఇది launch సమయంలో ఆ file ను import చేస్తుంది. దాని కింద Claude కు సంబంధించిన అదనపు notes ఉంచవచ్చు. అదనంగా ఏమీ జతచేయాల్సిన అవసరం లేకపోతే symlink కూడా పనిచేస్తుంది. ఆ file లో మొదటగా ఏ సమాచారం ఉండాలో నిర్ణయించడం వేరే ప్రశ్న. దీనిని agent instructions ను human documentation నుంచి వేరు చేయడం విభాగంలో చర్చించాం.

మీరు దాన్ని తిరిగి రాయడానికి ముందు ఫైల్ లోడ్ అయిందని నిర్ధారించండి

Agent ఆ ఫైల్‌ను చూడగలదని నిర్ధారించే ఆధారం లభించే వరకు వాక్యాలను మార్చవద్దు. దీనిని తనిఖీ చేయడానికి రెండు మార్గాలు ఉన్నాయి. ముందుగా సులభమైనదాన్ని అమలు చేయండి.

సెషన్‌లో /context ను అమలు చేయండి. ఇది ప్రస్తుత window ను category ఆధారంగా విభజించి చూపిస్తుంది. వాస్తవంగా లోడ్ అయిన ప్రతి instruction file పేరును Memory files జాబితా చూపిస్తుంది. ఆ జాబితాలో లేని ఫైల్ conversation లో లేదు. అందువల్ల దానిలో మీరు రాసినది ఏదీ ప్రభావం చూపదు. /memory ఫైల్ స్థానాలను జాబితా చేసి, అవి ఇంకా లేకపోయినా, వాటిని editing కోసం తెరుస్తుంది.

మరింత ఖచ్చితమైన నిర్ధారణ కోసం loads ను log చేయండి. ప్రతి CLAUDE.md లేదా rules file context లోకి వచ్చినప్పుడు InstructionsLoaded hook event అమలవుతుంది. Load ఎందుకు జరిగిందో దాని 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 తో దాన్ని monitor చేయండి. ఈ event యొక్క exit status విస్మరించబడుతుంది. కాబట్టి hook కేవలం గమనించగలదు, అడ్డుకోలదు. Nested file కనిపించాలి అని మీరు భావించిన సెషన్‌లో అది ఆ log లో ఎప్పుడూ కనిపించకపోతే, వాక్యాలను తిరిగి రాయడం ఆపండి. సమస్య file placement లో ఉంది.

దీర్ఘ session మీ నియమాలను ఎలా ప్రభావితం చేస్తుంది

ఇక్కడ రెండు వేర్వేరు ప్రభావాలు ఉంటాయి. వాటికి వేర్వేరు పరిష్కారాలు అవసరం.

దూరం. turn 1లో పేర్కొన్న నియమం turn 90లో కూడా windowలో ఉంటుంది. అయితే అప్పటికి అది ఇటీవలి కాలానికి చెందిన, మీరు ప్రస్తుతం చేస్తున్న పనికి మరింత నిర్దిష్టమైన 90 turns పాఠ్యంతో పోటీ పడుతుంది. దీన్ని configuration ద్వారా తొలగించలేరు. కానీ దీన్ని కొలవచ్చు. అదే taskను కొత్త sessionలో అమలు చేయండి. అక్కడ నియమం పనిచేసి, దీర్ఘ sessionలో లోతుగా వెళ్లిన తర్వాత విఫలమైతే, కారణం దూరమే.

Compaction. window నిండినప్పుడు harness ఇప్పటివరకు ఉన్న conversationను సంక్షిప్తంగా సమీక్షించి, ఆ summary నుంచి కొనసాగుతుంది. ఏది నిలిచి ఉంటుందో summariser ముఖ్యమని భావించినదానిపై ఆధారపడి ఉంటుంది. మీరు ముఖ్యమని భావించేదానితో అది తప్పనిసరిగా సమానం కాదు. Claude Code ప్రతి mechanism కోసం ఫలితాన్ని documentationలో వివరిస్తుంది. వాటి మధ్య తేడాలు గణనీయంగా ఉంటాయి. Project root CLAUDE.md మరియు unscoped rules compaction తర్వాత disk నుంచి మళ్లీ inject అవుతాయి. Auto memory disk నుంచి మళ్లీ inject అవుతుంది. paths: frontmatter కలిగిన rules మళ్లీ matching file చదివే వరకు పోతాయి. Subdirectoriesలోని nested CLAUDE.md files ఆ subdirectoryలోని fileను మళ్లీ చదివే వరకు పోతాయి.

ఆ పట్టిక ఆధారంగా మీ instructionsకు క్రమం కేటాయిస్తే, వాటి fragility క్రమం స్పష్టమవుతుంది. Chatలో మాత్రమే మీరు టైప్ చేసిన rule sessionలో అత్యంత fragile అంశం. Summary దాన్ని ఉంచితేనే అది కొనసాగుతుంది. packages/api/CLAUDE.md లోని rule తరువాతి స్థాయిలో ఉంటుంది. అది ఒకసారి load అయి, summaryలో తొలగిపోయి, ఆ directoryలో తదుపరి read జరిగినప్పుడు మాత్రమే తిరిగి వస్తుంది. Project root fileలోని rule అత్యంత durableగా ఉంటుంది, ఎందుకంటే అది ప్రతి సారి disk నుంచి మళ్లీ చదవబడుతుంది.

కాబట్టి ఒక instruction మొత్తం sessionలో అమలులో ఉండాలి అనుకుంటే, అది paths: frontmatter లేకుండా project root fileలో ఉండాలి. మిగిలిన ప్రతి ఎంపికను ఉద్దేశపూర్వకంగా చేసిన tradeoffగా పరిగణించాలి. context windowలో ఏది నిలిచి ఉండాలో నిర్వహించడంలో /compact కోసం focus argument, అలాగే సంబంధం లేని tasks మధ్య /clear గురించి వివరణ ఉంది. ఇవి రెండూ summariser మీ rules ఏమిటో నిర్ణయించే అవకాశాన్ని ఎంత తరచుగా పొందుతుందో మార్చుతాయి.

పరిసర కోడ్ నియమాన్ని మించేది ఎందుకు

ఇది చాలామంది తరచుగా వివరించే, కానీ చాలా అరుదుగా సరిగ్గా నిర్ధారించే వైఫల్యం. మీ ఫైల్ ప్రకారం database access repository layer ద్వారా జరగాలి. కానీ agent ORM (object relational mapper) ను నేరుగా పిలిచే handler ను రాస్తుంది. ఇది style కారణంగా మీ సూచనను విస్మరించడం కాదు. ఆధారాల పరంగా మీ సూచనకు మద్దతు లేకపోవడం వల్ల agent వేరే నిర్ణయం తీసుకుంది.

ఒక rule ఒక ప్రాధాన్యతను వివరిస్తుంది. కోడ్ ఒక అమలైన ఉదాహరణను చూపిస్తుంది. Agent మార్చబోయే module లోని మూడు ఫైళ్లను తెరిచినప్పుడు, ఆ మూడింటిలోనూ ORM ను నేరుగా పిలుస్తూ ఉంటే, context లో ఒక వైపు ఒక abstract వాక్యం, మరో వైపు మూడు concrete, ఇటీవలి, ప్రస్తుత task కు సరిపోయే ఉదాహరణలు ఉంటాయి. స్థానిక pattern ను అనుసరించడం సాధారణంగా సరైన ప్రవర్తనే. అయితే ఇక్కడ అది తప్పు, ఎందుకంటే context కు తెలియని విషయం మీకు తెలుసు: ఆ ఫైళ్లు legacy code.

కాబట్టి ఆ విషయాన్ని rule లోనే రాయండి. తమకు విరుద్ధంగా కనిపించే ఆధారాలను స్వయంగా పేర్కొనే rules నిజమైన repository లోనూ సమర్థంగా పనిచేస్తాయి. కేవలం ఒక preference ను పేర్కొనే rules అలా పనిచేయవు.

New database access goes through app/repositories/. Files under app/legacy/ still call the ORM directly. That is old code, not the pattern. Do not copy it.

రెండవ వాక్యమే ప్రధాన పని చేస్తుంది. Agent ఆ కోడ్‌ను చూసే ముందే, తాను ఏమి చూడబోతోందో మరియు దాన్ని ఎలా అర్థం చేసుకోవాలో ఆ వాక్యం చెబుతుంది. Repository స్పష్టంగా విరుద్ధంగా చూపించే ఏ rule కైనా ఇదే సవరణ వర్తిస్తుంది: మీ history అనుసరించని commit style, మీ test suite లో సగం పాటించని test layout, కొత్త code లో మాత్రమే కనిపించే import convention. Code మరియు file ఒకదానితో ఒకటి విభేదించే ప్రతి చోట, ఆ విభేదాన్ని file లోనే పేర్కొనండి.

అస్పష్టమైన నియమాన్ని తనిఖీ చేయలేము. కాబట్టి దాన్ని అనుసరించలేము

"శుభ్రమైన కోడ్ రాయండి." "అవసరానికి మించి రూపకల్పన చేయవద్దు." "సరళంగా ఉంచండి." "Migrations విషయంలో జాగ్రత్తగా ఉండండి." వీటిలో ఏదీ agent లేదా మీరు ఒక నిర్దిష్ట చర్యతో పోల్చి పరీక్షించలేరు. తన స్వంత output తో పోల్చి తనిఖీ చేయలేని నియమాన్ని agent కు ఇస్తే, అది కేవలం ఊహిస్తుంది. మీరు కూడా ఆ ఊహను స్పష్టమైన ప్రమాణం లేకుండా అంచనా వేస్తారు.

మీ ఫైల్‌లోని ప్రతి పంక్తికి ఈ పరీక్షను వర్తింపజేయండి. ఆ నియమం ఉల్లంఘించినప్పుడు non-zero తో ముగిసే shell command ను రాయండి. ఆ command ను రాయలేకపోతే, ఆ నియమాన్ని తనిఖీ చేయలేరు. ఈ జంటలను పోల్చండి:

• తనిఖీ చేయలేనిది: "Functions ను చిన్నగా ఉంచండి." తనిఖీ చేయగలిగేది: "60 lines కంటే ఎక్కువ ఉన్న function పైన, అది ఎందుకు అవసరమో వివరించే comment ఉండాలి."
• తనిఖీ చేయలేనిది: "మీ మార్పులను test చేయండి." తనిఖీ చేయగలిగేది: "npm test ను run చేసి, task పూర్తయిందని చెప్పే ముందు failure count ను paste చేయండి."
• తనిఖీ చేయలేనిది: "Files ను క్రమబద్ధంగా ఉంచండి." తనిఖీ చేయగలిగేది: "HTTP handlers src/api/handlers/ లో ఉండాలి. ఆ directory లోకి మరేదీ వెళ్లకూడదు."
• తనిఖీ చేయలేనిది: "Code ను సరిగ్గా format చేయండి." తనిఖీ చేయగలిగేది: ".ts files లో 2 space indentation ఉపయోగించండి."

"అవసరానికి మించి రూపకల్పన చేయవద్దు" అనే నియమాన్ని ప్రజలు మొదట వదిలేస్తారు. కారణం, దాని పరిష్కారం చిన్న వాక్యం కాదు; పొడవైన వాక్యం. పనిచేసే అతి చిన్న మార్పు అంటే నిజంగా ఏమిటో స్పష్టంగా రాయడం ద్వారా agent తన diff ను పోల్చుకోగల ప్రమాణాలను పొందుతుంది.

వేరే రూపంలో కనిపించే ఇదే సమస్య size విషయంలోనూ ఉంటుంది. Claude Code మార్గదర్శకాలు ప్రతి instruction file ను 200 lines కంటే తక్కువగా ఉంచాలని సూచిస్తాయి. పొడవైన files లో నియమాలను అనుసరించే స్థాయి తగ్గుతుందని అవి నేరుగా చెబుతాయి. 700 line file మరింత బలమైన instruction కాదు. అది పరస్పరం విరుద్ధంగా ఉండే అవకాశాలు ఎక్కువగా ఉన్న 700 claims. ప్రతి 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 లో విఫలమైతే సమస్య context దూరం లేదా compaction కు సంబంధించినది. ఇక్కడ కూడా విఫలమైతే సమస్య నియమంలోనే ఉంది.
3. పోటీ సూచనలను తొలగించండి. ఇప్పటికే ఉన్న code ఆ నియమాన్ని అనుసరిస్తున్న directory లో అదే మార్పును అడగండి. అప్పుడు compliance తిరిగి వస్తే, చుట్టూ ఉన్న code మీ వాక్యాన్ని మించిన ప్రభావాన్ని చూపుతోంది.
4. విరుద్ధత కోసం శోధించండి. ఒకే ప్రవర్తనకు రెండు files భిన్నమైన సూచనలు ఇస్తే, అది documentation లో పేర్కొన్న failure. Model ఏదో ఒకదాన్ని యాదృచ్ఛికంగా ఎంచుకోవచ్చు. అలా ఎంచుకున్నట్లు అది మీకు చెప్పదు.
5. దాన్ని తనిఖీ చేయగలిగేలా చేసి మళ్లీ పరీక్షించండి. ఖచ్చితమైన path మరియు condition తో నియమాన్ని తిరిగి రాయండి. Compliance గణనీయంగా పెరిగితే, కారణం phrasing లోనే ఉంది.

Step 4 ఒక command తో పూర్తవుతుంది. మీరు సవరించిన file మాత్రమే కాకుండా, topic కు సంబంధించిన ప్రతి instruction source ను grep చేయండి:

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

రెండు files లో భిన్నమైన సూచనలు కనిపిస్తే, అదే మీ bug. ఒకదాన్ని తొలగించండి. బలమైన wording తో వాటికి ప్రాధాన్యత క్రమాన్ని నిర్ణయించడానికి ప్రయత్నించవద్దు. ఎందుకంటే ఆశ్రయించడానికి ranking engine ఏదీ లేదు.

అమలు ప్రభావం ఆధారంగా పరిష్కారాల క్రమం

కింద ఉన్న ప్రతి దశకు, దాని పైన ఉన్న దశకంటే ఎక్కువ అమలు ప్రభావం ఉంటుంది. అయితే దాన్ని ఏర్పాటు చేయడానికి ఎక్కువ ఖర్చవుతుంది. ఒక నియమాన్ని సులభంగా తిరిగి రాయగలిగితే పై నుంచి ప్రారంభించండి. అప్పుడప్పుడు నియమం తప్పిపోవడం ఇక ఆమోదయోగ్యం కానంత ముఖ్యమైనదిగా మారిన వెంటనే కింది దశకు వెళ్లండి.

1. నియమాన్ని స్పష్టంగా రూపొందించండి. ఒక path, command లేదా condition ను పేర్కొనండి. ముందుగా చూపిన విధంగా, agent repositoryలో కనుగొనే వ్యతిరేక ఆధారాలను కూడా జోడించండి. దీనికి అదనపు ఖర్చు ఉండదు. ఇది ఊహించినదానికంటే ఎక్కువ సందర్భాలను పరిష్కరిస్తుంది.
2. నియమం నియంత్రించే అంశానికి దాన్ని మరింత దగ్గరగా ఉంచండి. Nested CLAUDE.md, .claude/rules/ లో path-scoped rule లేదా file పైభాగంలో ఉన్న comment ఉపయోగించండి. అప్పుడు నియమం వర్తించే code చదివే సమయంలోనే అది కూడా అందుబాటులోకి వస్తుంది. అయితే ఈ tradeoff ను అంగీకరించాలి: ఆ విధంగా load చేసినది తదుపరి compaction సమయంలో తొలగిపోతుంది. తదుపరి సరిపోలే 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 ప్రతి సారి సరిగ్గా పనిచేస్తుంది. దానికి 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 ను run చేసి, కొత్త session ప్రారంభించండి. తరువాత migrations/ కింద ఉన్న file ను edit చేయమని agent ను అడగండి. 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 అదే పని చేస్తుంది. దాన్ని నిర్వహించడానికి script అవసరం లేదు. మీ ముందస్తు అనుమతి లేకుండా ఏది run అవుతుందో permission modes నిర్ణయిస్తాయి. ఒక instruction నిజంగా user message లో కాకుండా system prompt స్థాయిలో ఉండాల్సి వస్తే, --append-system-prompt దాన్ని అక్కడ ఉంచుతుంది. అయితే ప్రతి invocation సమయంలో దాన్ని pass చేయాలి. అందువల్ల ఇది interactive work కంటే scripts కు అనుకూలంగా ఉంటుంది.

మీరు ఆదేశాలతో మార్చలేని విషయాలు

ఇందులో ఏ సగం మీ పరిధిలో ఉందో స్పష్టంగా తెలుసుకోండి. Placement, phrasing, files మధ్య conflicts, file size వంటివి author సమస్యలు; వాటికి author స్థాయిలో పరిష్కారాలు ఉన్నాయి. మిగిలినవి model behaviour కు సంబంధించినవి. మెరుగైన wording వాటిని తొలగించదు.

Agreement compliance కాదు. Agent ఒక rule ను అంగీకరించినట్లు చెప్పవచ్చు, దాన్ని మీకు సరిగ్గా మళ్లీ చెప్పవచ్చు, కానీ రెండు tool calls తర్వాత అదే rule ను ఉల్లంఘించవచ్చు. ఆ acknowledgement కు ఎలాంటి ఖర్చు ఉండదు; దాని ఆధారంగా భవిష్యత్ ప్రవర్తనను అంచనా వేయలేరు. దాన్ని fix గా పరిగణించవద్దు. దాన్ని test గా కూడా లెక్కించవద్దు.

కొన్ని అలవాట్లు persistent గా ఉంటాయి. Comments జోడించడం, defensive error handling జోడించడం, closing summary రాయడం, తదుపరి స్పష్టమైన command ను అమలు చేయడం వంటివి rule నిషేధించినా తిరిగి కనిపిస్తాయి. వాటి రేటు zero కాకుండా తగ్గుతుంది. మీ స్వంత rate ను కొలవచ్చు: అదే task ను fresh sessions లో పది సార్లు run చేసి violations ను లెక్కించండి. ఆ సంఖ్య zero కావాల్సి ఉంటే, rule ను prompt నుంచి తీసివేయాలి. పని ఇంకా కొంత మిగిలి ఉండగానే పూర్తయిందని చెప్పడం కూడా ఇదే తరహా అలవాటు. దానికి పరిష్కారం verbal కాదు, structural: unlazy skill sentence స్థానంలో Depth Tree ను ఉంచుతుంది; పూర్తయిందని చెప్పే ముందు agent clear చేయాల్సిన gate files ను కూడా అందిస్తుంది.

మీ స్వంత session ఒక ఉదాహరణగా మారుతుంది. Agent turn 12 వద్ద rule ను ఉల్లంఘించినప్పుడు మీరు దాన్ని పట్టించుకోకపోతే, ఆ violation context లో demonstration గా నిలుస్తుంది. అది rule కంటే చాలా recent గా ఉంటుంది. Violation కనిపించిన వెంటనే దాన్ని సరిచేయండి. సరిచేయని violation session లోని మిగిలిన భాగానికి బోధనగా మారుతుంది.

Instruction file security boundary కాదు. అది behaviour ను ప్రభావితం చేస్తుంది కానీ దాన్ని enforce చేయదు. Miss వల్ల ఖర్చు ఎక్కువయ్యే విషయాలు, ముఖ్యంగా credentials లేదా destructive commands, permissions లేదా hook పరిధిలో ఉండాలి. agent కు secrets అందకుండా ఉంచడం data విషయంలో ఇదే సూత్రాన్ని వర్తింపజేస్తుంది: agent ఒక file ను చదవకూడదని అడగవద్దు; ఆ file readable కాకుండా ఏర్పాటు చేయండి.

సంక్షిప్తంగా: file load అయిందని నిరూపించండి, rule ను check చేయగలిగేలా చేయండి, అది నియంత్రించే అంశం పక్కనే ఉంచండి. Miss rate ఇంకా ముఖ్యంగా ఉంటే, దాన్ని prose నుంచి తీసివేయండి. Agent ignore చేయలేని rule అనేది agent ను ఎప్పుడూ అడగని rule.

FAQ

Claude Code నా CLAUDE.md ను ఎందుకు పట్టించుకోదు?

దాన్ని పట్టించుకోలేదని భావించే ముందు, అది లోడ్ అయిందో లేదో తనిఖీ చేయండి. /context ను అమలు చేసి Memory files జాబితాను చూడండి; అక్కడ పేరు లేని ఫైల్ conversation లో ఉండదు. Instruction files ను system prompt తర్వాత user message గా పంపుతారు. అందువల్ల అవి enforced configuration గా కాకుండా context గా పరిగణించబడతాయి. కాబట్టి కఠినమైన compliance కు హామీ ఉండదు. వాస్తవ పరిస్థితుల్లో సాధారణంగా నాలుగు కారణాల్లో ఒకటి ఉంటుంది: agent ఎప్పుడూ చదవని subdirectory లో ఫైల్ ఉండటం, రెండు ఫైళ్లు పరస్పరం విరుద్ధంగా ఉండటంతో model ఒకదాన్ని యాదృచ్ఛికంగా ఎంచుకోవడం, ఒక చర్యకు వ్యతిరేకంగా తనిఖీ చేయలేనంత అస్పష్టంగా rule ఉండటం, లేదా చుట్టుపక్కల code ఆ rule కు విరుద్ధమైన ప్రవర్తనను చూపించడం.

Session మధ్యలో instruction file ను సవరించడం వల్ల ఏమైనా మారుతుందా?

ఇప్పటికే conversation లో ఉన్న copy విషయంలో మారదు. మీ working directory పైన ఉన్న ఫైళ్లు launch సమయంలో పూర్తిగా లోడ్ అవుతాయి. కాబట్టి model వద్ద ఉన్న text launch సమయంలో ఉన్నదే. సవరణను లోడ్ చేయడానికి కొత్త session ప్రారంభించండి. లేదా agent తన సాధారణ file tools తో ఫైల్‌ను చదవమని అడగండి. అప్పుడు ప్రస్తుత version కొత్త message గా conversation లోకి వస్తుంది. Compaction తర్వాత project root file disk నుంచి మళ్లీ చదవబడుతుంది. అందువల్ల ఆ సమయంలో కొత్త version కూడా వస్తుంది.

Root CLAUDE.md మరియు nested CLAUDE.md పరస్పరం విభేదిస్తే ఏ ఫైల్ ప్రాధాన్యం పొందుతుంది?

ఏదీ విశ్వసనీయంగా ప్రాధాన్యం పొందదు. కనుగొన్న ఫైళ్లను ఒకదానిని మరొకటి override చేసే బదులు context లో కలిపి ఉంచుతారు. అవి filesystem root నుంచి మీ working directory వరకు క్రమంలో ఉంటాయి. అందువల్ల అత్యంత సమీపంలోని ఫైల్ చివరగా చదవబడుతుంది. విరుద్ధతలను పరిష్కరించే precedence engine లేదు. విరుద్ధమైన rules ను యాదృచ్ఛికంగా పరిష్కరించవచ్చని Claude Code documentation పేర్కొంటుంది. Nested files ను అవి నియంత్రించే path ను స్పష్టంగా పేర్కొనే additions గా రాయండి. ఒక rule ను మరొకదానికంటే పైచేయి చేయడానికి ప్రయత్నించే బదులు విరుద్ధమైన rule ను తొలగించండి.

/compact తర్వాత నా instructions కొనసాగుతాయా?

అవి ఎలా లోడ్ అయ్యాయనే దానిపై ఆధారపడి ఉంటుంది. Project root CLAUDE.md, unscoped rules మరియు auto memory compaction తర్వాత disk నుంచి మళ్లీ inject చేయబడతాయి. paths: frontmatter ఉన్న rules మరియు subdirectories లోని nested CLAUDE.md files మళ్లీ సరిపడే file చదివే వరకు కోల్పోతారు. మీరు chat లో మాత్రమే టైప్ చేసిన విషయం summariser దాన్ని ఉంచి ఉంటేనే కొనసాగుతుంది. ఒక rule మొత్తం session లో కొనసాగాలి అనుకుంటే, paths: frontmatter లేకుండా project root file లో ఉంచండి.

Prose కు బదులుగా rule ను hook గా ఎప్పుడు మార్చాలి?

తనిఖీ deterministic గా ఉండి, తనిఖీ తప్పిపోవడం వల్ల కలిగే నష్టం చిన్న script రాసే ఖర్చుకంటే ఎక్కువగా ఉన్నప్పుడు మార్చాలి. File path restrictions, commit కు ముందు అవసరమైన commands మరియు నిషేధిత tool calls ఈ వర్గంలోకి వస్తాయి. Status 2 తో ముగిసే PreToolUse hook tool call ను నేరుగా అడ్డుకుంటుంది. అలాగే మీ stderr text ను కారణంగా model కు అందిస్తుంది. అందువల్ల rule context లో ఇంకా ఉన్నా లేకపోయినా అది అమలవుతుంది. Formatter లేదా linter నిర్ణయించగల విషయాలను ఆ tool కే అప్పగించి, instruction file నుంచి పూర్తిగా తొలగించాలి.