Bakit Binabalewala ng Coding Agent ang Instructions

Bakit binabalewala ng coding agents ang iyong mga instruction

Binabalewala ng coding agents ang iyong mga instruction sa apat na dahilan, at hindi kasama rito ang pagiging masyado mong magalang. Maaaring hindi kailanman naisama sa context window ang rule. Maaaring masyadong malabo ang rule para maikumpara rito ang isang action. Maaaring may ibang bahagi ng context na sumasalungat dito, karaniwan ay ang code na kababasa pa lamang ng agent. O maaaring naka-load pa rin ang rule pero napakalayo nito sa kasalukuyang turn, kaya nakabatay ang agent sa mga bahaging malapit dito.

May sariling fix ang bawat sanhi, kaya ang unang gawain ay tukuyin kung alin sa mga ito ang naganap. Hindi diagnosis ang paggamit ng malalaking titik at ng salitang IMPORTANT. Ginagamit sa mga sumusunod na paliwanag ang Claude Code bilang halimbawa, dahil detalyadong dokumentado ang loading at compaction behaviour nito hanggang August 2026. Nagkakaiba ang ibang tool sa mga detalye, pero pareho ang pangkalahatang pagkilos ng mga ito.

Dalawang termino muna. Ang context window ay ang bloke ng text na nakikita ng model sa isang turn: system prompt, mga instruction file mo, conversation, at bawat file na nabasa ng agent. Ang harness ay ang program na nakapaligid sa model, o ang program na nagbabasa ng mga file mula sa disk at bumubuo sa blokeng iyon. Halos lahat ng reklamo sa post na ito ay talagang reklamo tungkol sa harness, hindi sa model.

Ang instruction file ay mensahe, hindi setting

Ang instruction file ay hindi configuration. Walang binabasa sa runtime na CLAUDE.md at nagpapatupad nito. Binabasa ng harness ang file mula sa disk at ipinapaste ang text nito sa conversation. Sa Claude Code, ipinapadala ang content bilang user message pagkatapos ng system prompt. Ibig sabihin, nakikita ng model ang mga rule mo sa parehong paraan ng pagkakita nito sa iba pang text na tina-type mo.

May hindi komportableng resulta ito. Nakikipagkompetensiya ang mga rule mo sa bawat iba pang text sa window at pantay ang katayuan ng mga ito. Ang isang rule ay claim. Ang file na kakabukas lang ng agent ay ebidensiya. Kapag hindi nagtutugma ang dalawa, madalas na nananalo ang ebidensiya. Walang naglalabas ng error dahil sa pananaw ng model, walang naging problema.

Malinaw itong sinasabi sa official documentation: itinuturing ang instruction files bilang context, hindi bilang configuration na awtomatikong ipinapatupad. Para harangan ang isang action anuman ang desisyon ng model, hook ang kailangan, hindi isang sentence. Tandaan ang linyang iyon. Karamihan sa mga fix sa dulo ng post na ito ay aplikasyon ng linyang iyon sa isang partikular na kaso.

Aling instruction file ang nilo-load, at kailan

Umaakyat si Claude Code sa directory tree mula sa directory kung saan mo ito sinimulan. Ang bawat CLAUDE.md at CLAUDE.local.md mula sa filesystem root hanggang sa working directory mo ay nilo-load nang buo sa pagsisimula. Pinagdudugtong ang mga ito ayon sa pagkakasunod-sunod, kaya huling binabasa ang file na pinakamalapit sa directory kung saan mo ito sinimulan. Sa loob ng isang directory, idinadagdag ang .local file pagkatapos ng pangunahing file.

Iba ang pagkilos ng mga file sa mga subdirectory sa ilalim ng working directory mo. Hindi sila nilo-load sa pagsisimula. Nilo-load ang mga ito kapag nagbasa ang agent ng file sa directory na iyon. Totoo rin ito para sa mga path-scoped rule sa .claude/rules/ na may paths: frontmatter field: ipinapasok ang mga ito sa context kapag binasa ang tumutugmang file, hindi sa bawat turn.

Ipinapaliwanag ng pagkakaibang ito ang malaking bahagi ng mga naiulat na failure. Naglagay ka ng rule sa packages/api/CLAUDE.md, nagtanong ka tungkol sa API, at sumagot ang agent nang hindi kailanman nagbubukas ng file sa ilalim ng packages/api/. Hindi binale-wala ang rule. Hindi pa ito naging bahagi ng context. Kung hinahati ng repository mo ang guidance sa mga instruction file bawat package sa isang monorepo, ito ang unang dapat suriin sa bawat pagkakataon.

May isa pang loading trap, at ito ang pinakakaraniwang anyo ng “binale-wala ng agent ang mga instruction ko”: binabasa ni Claude Code ang CLAUDE.md, hindi ang AGENTS.md. Kung nag-standardize ang repository sa AGENTS.md at wala itong CLAUDE.md, wala talagang ilo-load si Claude Code. Ang suportadong bridge ay isang CLAUDE.md na ang unang linya ay @AGENTS.md. Ini-import nito ang file sa pagsisimula, kasama ang anumang Claude-specific na tala sa mga kasunod na linya. Gumagana rin ang symlink kung wala ka nang kailangang idagdag. Ang pagpapasya kung ano ang dapat ilagay sa file na iyon ay hiwalay na tanong, at saklaw ito ng paghihiwalay ng agent instruction sa human documentation.

Kumpirmahin na na-load ang file bago ito muling isulat

Huwag baguhin ang wording hangga't wala kang patunay na nakikita ng agent ang file. May dalawang check, at unahin ang mas mabilis.

Patakbuhin ang /context sa loob ng session. Ipinapakita nito ang kasalukuyang window ayon sa category, at inililista sa Memory files ang bawat instruction file na aktuwal na na-load. Kapag wala ang file sa listahang iyon, wala ito sa conversation, kaya walang magiging epekto ang anumang isusulat mo rito. Inililista ng /memory ang mga lokasyon ng file at binubuksan ang mga ito para sa pag-edit, kasama ang mga file na hindi pa umiiral.

Para sa mas tiyak na sagot, i-log ang mga load. Nagti-trigger ang InstructionsLoaded hook event sa tuwing pumapasok sa context ang isang CLAUDE.md o rules file, at ipinapaliwanag ng matcher nito kung bakit naganap ang load: session_start, nested_traversal, path_glob_match, include, o compact. Ilagay ito sa .claude/settings.json:

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

Tinatanggap ng hook ang payload nito bilang JSON sa standard input, kaya idinadagdag ng cat ang buong record. I-monitor ito gamit ang tail -f /tmp/instructions-loaded.log habang nagtatrabaho ka. Hindi pinapansin ang exit status ng event na ito, kaya maaari lamang mag-observe ang hook at hindi mag-block. Kung hindi kailanman lumitaw ang nested file mo sa log sa session kung kailan mo inaasahang na-load ito, ihinto ang muling pagsulat. Placement ang problema.

Ang Epekto ng Mahabang Session sa Iyong mga Rule

May dalawang magkahiwalay na epekto rito, at magkaiba ang kinakailangang tugon sa bawat isa.

Layo. Ang rule na itinakda sa turn 1 ay nasa window pa rin sa turn 90, ngunit nakikipagkumpitensya na ito sa 90 turn ng text na mas bago at mas partikular sa kasalukuyan mong ginagawa. Hindi mo ito maaalis sa pamamagitan ng configuration, ngunit masusukat mo ito. Patakbuhin ang parehong task sa isang bagong session. Kung gumagana ang rule roon ngunit nabibigo pagdating sa malalim na bahagi ng mahabang session, layo ang sanhi.

Compaction. Kapag napuno ang window, bina-buod ng harness ang usapan hanggang sa puntong iyon at nagpapatuloy mula sa buod na iyon. Ang nananatili ay ang itinuring na mahalaga ng summariser, na maaaring iba sa itinuturing mong mahalaga. Idinodokumento ng Claude Code ang resulta para sa bawat mechanism, at malalaki ang pagkakaiba. Ang project root CLAUDE.md at mga unscoped rule ay muling ini-inject mula sa disk pagkatapos ng compaction. Ang auto memory ay muling ini-inject mula sa disk. Nawawala ang mga rule na may paths: frontmatter hanggang sa muling mabasa ang katugmang file. Nawawala ang mga nested CLAUDE.md file sa mga subdirectory hanggang sa muling mabasa ang isang file sa subdirectory na iyon.

I-rank ang iyong mga instruction ayon sa talahanayang iyon, at lilitaw ang pagkakasunod-sunod ng fragility. Ang rule na itina-type mo lamang sa chat ang pinaka-fragile sa session: mananatili lamang ito kung naisama ito sa buod. Kasunod ang rule sa packages/api/CLAUDE.md, dahil minsan lamang itong na-load, naisama sa buod at nawala, at babalik lamang sa susunod na pagbasa sa directory na iyon. Ang rule sa project root file ang pinakamatibay, dahil binabasa itong muli mula sa disk sa bawat pagkakataon.

Kaya kung kailangang manatili ang isang instruction sa buong session, ilagay ito sa project root file nang walang paths: frontmatter. Ang lahat ng iba pa ay tradeoff na dapat mong piliin nang sinasadya. Sinasaklaw ng Pamamahala sa nananatili sa context window ang /compact gamit ang focus argument at /clear sa pagitan ng magkakahiwalay na task; parehong nakaaapekto ang mga ito sa dalas ng pagkakataong mapagpasyahan ng summariser kung ano ang iyong mga rule.

Kung bakit mas nangingibabaw ang nakapaligid na code kaysa sa rule

Ito ang failure na pinakamadalas ilarawan ng mga tao at pinakamadalas ding hindi ma-diagnose. Sinasabi ng file mo na dapat dumaan sa repository layer ang database access. Sumulat ang agent ng handler na direktang tumatawag sa ORM (object relational mapper). Hindi ka binale-wala dahil sa style. Nadaig ng ebidensya ang rule mo.

Inilalarawan ng rule ang isang preference. Ipinapakita ito ng code. Kapag nagbukas ang agent ng tatlong file sa module na ie-edit nito at direktang tumatawag sa ORM ang lahat ng iyon, may isang abstract na pangungusap sa isang panig at tatlong kongkreto, bago, at angkop sa task na halimbawa sa kabilang panig. Karaniwang tamang gawi ang pagkopya sa lokal na pattern. Mali lamang ito rito dahil may alam ka na wala sa context: legacy ang mga file na iyon.

Kaya ilagay mo iyon sa rule. Nakalalampas sa aktuwal na repository ang mga rule na binabanggit ang sarili nitong counter-evidence. Hindi sapat ang mga rule na nagsasaad lamang ng isang payak na preference.

Ang bagong database access ay dapat dumaan sa app/repositories/. Direktang tumatawag sa ORM ang mga file sa ilalim ng app/legacy/. Lumang code iyon, hindi ang pattern. Huwag itong kopyahin.

Ang ikalawang pangungusap ang gumagawa ng mahalagang trabaho. Sinasabi nito sa agent kung ano ang malapit na nitong makita at kung paano ito dapat basahin, bago pa man nito makita. Ganoon din ang dapat gawin sa anumang rule na hayagang sinasalungat ng repository: isang commit style na hindi sinusunod ng history mo, isang test layout na hindi ginagamit ng kalahati ng test suite, o isang import convention na umiiral lamang sa bagong code. Kapag hindi nagtutugma ang code at ang file, tukuyin ang hindi pagkakatugmang iyon sa file.

Hindi nasusuri ang malabong rule, kaya hindi ito masusunod

Hindi masusuri ang mga sumusunod laban sa isang partikular na action, ng agent o ng iyong sarili: “Sumulat ng malinis na code.” “Huwag mag-overengineer.” “Panatilihing simple.” “Mag-ingat sa migrations.” Kapag binigyan ang agent ng rule na hindi nito ma-check laban sa sarili nitong output, nanghuhula ito, at hinuhusgahan mo ang hula batay sa pakiramdam.

Ito ang test na dapat ilapat sa bawat linya sa file mo. Isulat ang shell command na mag-e-exit na non-zero kapag nalabag ang rule. Kung hindi mo maisulat ang command na iyon, hindi checkable ang rule. Ihambing ang mga pares na ito:

• Hindi checkable: “Panatilihing maliit ang mga function.” Checkable: “Ang function na lalampas sa 60 lines ay nangangailangan ng comment sa itaas nito na nagpapaliwanag kung bakit.”
• Hindi checkable: “I-test ang mga pagbabago mo.” Checkable: “Patakbuhin ang npm test at i-paste ang failure count bago markahang tapos ang task.”
• Hindi checkable: “Panatilihing organisado ang mga file.” Checkable: “Nasa src/api/handlers/ ang mga HTTP handler. Walang ibang inilalagay sa directory na iyon.”
• Hindi checkable: “I-format nang maayos ang code.” Checkable: “Gumamit ng 2 space indentation sa mga .ts file.”

Ang “Huwag mag-overengineer” ang unang rule na karaniwang isinusuko ng mga tao, dahil ang tamang pag-aayos dito ay hindi mas maikling sentence kundi mas mahabang paliwanag: ang malinaw na pagtukoy sa pinakamaliit na gumaganang pagbabago ay nagbibigay sa agent ng criteria na maihahambing nito sa sarili nitong diff.

Pareho rin ang problema sa laki ng file, ngunit iba ang anyo nito. Tinutukoy ng guidance ng Claude Code ang mas mababa sa 200 lines bawat instruction file at tuwirang sinasabi na binabawasan ng mas mahahabang file ang adherence. Ang 700 line na file ay hindi mas matibay na instruction. Binubuo ito ng 700 claims na mas maraming pagkakataong magkasalungat, at ibinabawas ito sa window mo sa bawat turn, na direktang lumalabas sa paggamit mo ng token. Ang pag-istruktura ng file upang nasa ilalim ng heading na madaling i-scan ng reader ang bawat rule ay saklaw ng pagsulat ng instruction file na kayang isagawa ng agent. Mas mabuti pa, alisin ang mga bahaging naglalarawan sa halip na nag-uutos: ang directory tour na nagpapakita kung nasaan ang mga handler at model ay impormasyong maaaring hanapin ng agent kapag kailangan mula sa parsed map ng repository, sa halip na dalhin ito sa window sa bawat turn.

Paano ito i-diagnose sa loob ng sampung minuto

Patakbuhin ang mga ito ayon sa pagkakasunod-sunod. Kapag lumaktaw agad sa huling hakbang, nauuwi ang mga tao sa mahabang file ng mga tuntuning puro uppercase pero hindi pa rin gumagana.

1. Tiyaking na-load ito. Patakbuhin ang /context at basahin ang listahan ng Memory files. Kung wala roon ang file, ayusin ang lokasyon at huminto. Hindi pa naaangkop ang iba pang hakbang sa listahang ito.
2. Ulitin sa bagong session. Magsimula ng bagong session at ibigay ang pinakamaliit na task na dapat mag-trigger sa rule. Kung gumagana ito rito pero pumapalya sa mahabang session, malamang na distance o compaction ang sanhi. Kung pumapalya rin dito, ang rule mismo ang problema.
3. Alisin ang nakikipagkumpitensya. Hilingin ang parehong pagbabago sa directory na ang kasalukuyang code ay sumusunod na sa rule. Kung bumalik ang compliance, natatalo ng nakapaligid na code ang sentence mo.
4. Maghanap ng conflict. Ang dalawang file na nagbibigay ng magkaibang gabay para sa parehong behavior ay isang documented failure: maaaring pumili ang model ng isa nang arbitraryo, at hindi nito sasabihin sa iyo na ginawa nito iyon.
5. Gawing madaling i-check at subukan muli. Isulat muli ang rule gamit ang konkretong path at condition. Kung malaki ang itinaas ng compliance, ang phrasing ang sanhi.

Isang command ang Step 4. Mag-grep sa bawat source ng instruction para sa topic, hindi lamang sa file na ine-edit mo:

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

Ang hit sa dalawang file na magkaiba ang sinasabi ay ang bug mo. Burahin ang isa. Huwag subukang pagdesisyunan ang mga ito gamit ang mas matibay na wording, dahil walang ranking engine na mapagpapasahan.

Ang mga pag-aayos, ayon sa leverage

Mas malaki ang leverage ng bawat hakbang sa ibaba kaysa sa nauna rito, pero mas malaki rin ang gastos sa pag-set up. Magsimula sa itaas kapag mura lamang baguhin ang pagkakasulat ng isang rule. Bumaba sa susunod na antas kapag sapat na ang kahalagahan ng rule para hindi katanggap-tanggap ang paminsan-minsang pagpalya.

1. Gawing konkreto ang rule. Tukuyin ang path, command, o condition. Idagdag ang counter-evidence na makikita ng agent sa repository, gaya ng ipinakita kanina. Wala itong dagdag na gastos at nalulutas nito ang nakakagulat na dami ng kaso.
2. Ilapit ito sa saklaw nito. Maaaring gumamit ng nested CLAUDE.md, path-scoped rule sa .claude/rules/, o comment sa pinakataas ng file mismo. Sa ganitong paraan, nababasa ang rule kasabay ng code na saklaw nito. Tanggapin ang kapalit: anumang nilo-load sa paraang ito ay inaalis sa susunod na compaction at bumabalik sa susunod na matching read.
3. Ilipat ang enforcement sa isang hook. Humihingi lamang ang prose. Nagpapasya ang hook. Tumatakbo ang mga hook bilang code sa mga nakatakdang lifecycle event at nalalapat anuman ang maging konklusyon ng model.
4. Ibigay ang rule sa isang deterministic tool at alisin ang prose. Formatting, import order, line length, ipinagbabawal na import, at format ng commit message. ruff format, prettier --write, eslint, at isang pre-commit hook. Palaging tama ang formatter at walang token na ginagastos. Kadalasang tama ang sentence at gumagastos ng tokens sa bawat turn.

Buong halimbawa ng Step 3. Ipagpalagay na hindi dapat kailanman i-edit ng agent ang mga migration file. Ilagay ito sa .claude/settings.json:

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

At ilagay ito sa .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

Patakbuhin ang chmod +x .claude/hooks/guard-migrations.sh, pagkatapos ay magsimula ng bagong session at hilingin sa agent na mag-edit ng file sa ilalim ng migrations/. Tatanggihan ang edit at ibabalik sa iyo ang mensahe bilang dahilan. Kapag exit status 2 ang ibinalik ng PreToolUse, bina-block nito ang tool call bago ito tumakbo, at ipinapasa ang iyong stderr text sa model bilang blocking message. Tinutukoy ng ${CLAUDE_PROJECT_DIR} ang project root, kaya gumagana ang hook anuman ang directory kung nasaan ang agent. Hindi kailangang sumang-ayon ang agent sa rule, maalala ang rule, o nasa context pa nito ang rule. Hindi mangyayari ang edit.

Para sa simpleng prohibition na walang logic, pareho ang ginagawa ng permissions.deny sa iyong settings nang walang script na kailangang i-maintain, at tinutukoy ng permission modes kung ano ang tatakbo nang hindi muna humihingi ng pahintulot sa iyo. Kung talagang kailangang nasa system prompt level ang isang instruction sa halip na nasa user message, inilalagay ito roon ng --append-system-prompt, ngunit dapat itong ipasa sa bawat invocation. Mas angkop ito sa mga script kaysa sa interactive na paggamit.

Hindi mo maituturo sa prompt

Maging malinaw kung aling bahagi nito ang sakop mo. Problema ng author, at may katumbas na pag-aayos mula sa author, ang placement, phrasing, mga conflict sa pagitan ng files, at laki ng file. Model behaviour ang iba pa, at hindi ito mawawala sa mas maayos na wording.

Hindi compliance ang agreement. Maaaring kilalanin ng agent ang isang rule, ulitin ito nang tama, at labagin ito pagkalipas lamang ng dalawang tool call. Walang kapalit ang acknowledgement, at wala rin itong kakayahang hulaan ang susunod na behaviour. Huwag itong ituring na fix, at huwag itong bilangin bilang test.

May ilang persistent na habit. Kabilang dito ang pagdaragdag ng comments, pagdaragdag ng defensive error handling, pagsusulat ng closing summary, at pagpapatakbo ng halatang susunod na command. Bumabalik ang mga ito kapag may rule na nagbabawal sa kanila, ngunit mas mababa ang dalas kaysa sa zero. Maaari mong sukatin ang sarili mong rate: patakbuhin ang parehong task nang sampung beses sa magkakahiwalay na fresh session at bilangin ang mga violation. Kung kailangang zero ang bilang na iyon, kailangang alisin sa prompt ang rule. Kapag tinawag na tapos ang isang job kahit may bahagi pa itong hindi nagagawa, kapareho ito ng habit na iyon. Structural, hindi verbal, ang kailangan sa pag-aayos: pinapalitan ng unlazy skill ang pangungusap ng Depth Tree at mga gate file na kailangang ma-clear ng agent bago nito ma-claim na tapos na.

Nagiging halimbawa ang sarili mong session. Kung nilabag ng agent ang rule sa turn 12 at pinalampas mo ito, nasa context na ngayon ang violation bilang demonstration, at mas bago ito kaysa sa rule. Itama agad ang violation kapag nakita mo ito. Ang hindi naitama na violation ay nagtuturo sa natitirang bahagi ng session.

Hindi security boundary ang isang instruction file. Hinuhubog nito ang behaviour ngunit hindi nito ito ipinapatupad. Anumang mahalaga kapag hindi naisagawa, gaya ng credentials o destructive commands, ay dapat mapailalim sa permissions o hook. Ang pag-iwas na maabot ng agent ang secrets ay gumagamit ng parehong prinsipyo sa data: huwag hilingin sa agent na huwag basahin ang isang file; ayusin para hindi nito mabasa ang file.

Ito ang maikling bersyon. Patunayang na-load ang file, gawing mache-check ang rule, ilipat ito sa tabi ng bagay na pinamamahalaan nito, at kapag mahalaga pa rin ang miss rate, alisin ito sa prose. Ang rule na hindi maaaring i-ignore ng agent ay rule na hindi kailanman hiningi sa agent.

FAQ

Bakit binabalewala ng Claude Code ang CLAUDE.md ko?

Tiyaking na-load muna ito bago ipagpalagay na binabalewala ito. Patakbuhin ang /context at tingnan ang listahan ng Memory files; kung wala roon ang pangalan ng file, hindi ito kasama sa conversation. Inihahatid ang mga instruction file bilang user message pagkatapos ng system prompt, at itinuturing ang mga ito bilang context sa halip na enforced configuration, kaya walang mahigpit na garantiya ng pagsunod. Sa karamihan ng aktuwal na kaso, isa sa apat ang dahilan: nasa subdirectory ang file na hindi binasa ng agent, hindi nagtutugma ang dalawang file at arbitraryong pinili ng model ang isa, masyadong malabo ang rule para maiugnay sa isang action, o ipinapakita ng nakapaligid na code ang kabaligtaran ng sinasabi ng rule.

May epekto ba ang pag-edit ng instruction file habang nasa session?

Wala sa kopyang nasa conversation na. Buong nilo-load sa pagsisimula ang mga file na nasa itaas ng working directory, kaya ang tekstong hawak ng model ay ang bersyon mula noong launch. Para maisama ang edit, magsimula ng bagong session o ipabasa sa agent ang file gamit ang normal nitong file tools. Sa ganitong paraan, nailalagay ang kasalukuyang bersyon sa conversation bilang bagong message. Pagkatapos ng compaction, muling binabasa mula sa disk ang file sa project root, kaya dumarating din ang bagong bersyon sa puntong iyon.

Aling file ang mananaig kapag hindi nagtutugma ang root CLAUDE.md at nested na file?

Wala sa mga ito ang maaasahang mananaig. Pinagdudugtong ang mga natuklasang file sa context sa halip na i-override ang isa't isa. Inaayos ang mga ito mula sa filesystem root pababa sa working directory, kaya huling nababasa ang pinakamalapit na file. Walang precedence engine na lumulutas sa mga kontradiksyon, at nakasaad sa documentation ng Claude Code na maaaring lutasin nang arbitraryo ang magkakasalungat na rule. Isulat ang nested na file bilang dagdag na mga rule at tukuyin ang path na saklaw nito. Burahin ang kontradiksyon sa halip na subukang manaig dito.

Nananatili ba ang mga instruction ko pagkatapos ng /compact?

Depende ito sa paraan ng pag-load sa mga ito. Muling ini-inject mula sa disk pagkatapos ng compaction ang project root CLAUDE.md, mga unscoped rule, at auto memory. Nawawala hanggang sa muling mabasa ang mga rule na may paths: frontmatter at mga nested CLAUDE.md file sa mga subdirectory. Ang anumang itinype mo lamang sa chat ay mananatili lang kung naisama ito ng summariser. Kung kailangang manatili ang isang rule sa buong session, ilagay ito sa file sa project root nang walang paths: frontmatter.

Kailan dapat maging hook ang isang rule sa halip na prose?

Kapag deterministic ang check at mas malaki ang gastos ng isang hindi natukoy na paglabag kaysa sa pagsulat ng maliit na script. Kasama rito ang mga restriction sa file path, mga command na kailangang patakbuhin bago ang commit, at mga ipinagbabawal na tool call. Ang PreToolUse hook na nag-e-exit na may status 2 ay direktang humaharang sa tool call at ipinapasa ang iyong stderr text sa model bilang dahilan. Dahil dito, gumagana ito kahit wala na sa context ang rule. Ang anumang kayang desisyunan ng formatter o linter ay dapat ipaubaya sa tool na iyon at tuluyang alisin sa instruction file.