Bakit Binabalewala ng Coding Agent ang Instructions Mo

Bakit binabalewala ng coding agents ang mga instruction mo

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

May sariling solusyon ang bawat sanhi, kaya ang unang gawain ay tukuyin kung alin sa mga ito ang nangyayari. Hindi diagnosis ang paggamit ng malalaking titik at ng salitang IMPORTANT. Gagamitin sa mga sumusunod na mekanismo ang Claude Code bilang halimbawa, dahil detalyadong dokumentado ang loading at compaction behaviour nito noong August 2026. Nagkakaiba ang ibang tool sa mga detalye, pero pareho ang pangkalahatang paraan ng pag-uugali.

Dalawang termino muna. Ang context window ay ang block ng text na nakikita ng model sa isang partikular na turn: system prompt, mga instruction file mo, conversation, at bawat file na nabasa ng agent. Ang harness ay ang program na nakapaligid sa model—ito ang nagbabasa ng mga file mula sa disk at nagtitipon ng block na 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 bahagi ng runtime ang bumabasa sa CLAUDE.md at nagpapatupad nito. Binabasa ng harness ang file mula sa disk at ipinapasok ang text nito sa conversation. Sa Claude Code, ipinapadala ang content bilang user message na inilalagay pagkatapos ng system prompt. Ibig sabihin, nakikita ng model ang iyong mga rule sa parehong paraan ng anumang iba pang text na inilagay mo.

May hindi komportableng resulta ito. Nakikipagkumpitensya ang iyong mga rule sa lahat ng iba pang text sa window, at pare-pareho ang bigat ng mga ito. Ang isang rule ay isang claim. Ang file na kababasa lamang ng agent ay evidence. Kapag hindi nagtutugma ang dalawa, madalas na nananalo ang evidence. Walang error na lumalabas dahil, mula sa pananaw ng model, walang nangyaring mali.

Malinaw itong sinasabi sa official documentation: itinuturing ang instruction files bilang context, hindi bilang enforced configuration. Para harangan ang isang action anuman ang desisyon ng model, kailangan mo ng hook, hindi ng 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

Umakyat si Claude Code sa directory tree mula sa directory kung saan mo ito sinimulan. Lahat ng 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 ganoong ayos, 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 kilos ng mga file sa mga subdirectory na nasa ibaba ng working directory mo. Hindi sila nilo-load sa pagsisimula. Nilo-load sila kapag nagbasa ang agent ng file sa directory na iyon. Ganoon din ang path-scoped rule sa .claude/rules/ na may paths: frontmatter field: pumapasok ang mga ito sa context kapag nagbasa ng 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 nagbukas ng file sa ilalim ng packages/api/. Hindi binale-wala ang rule. Hindi lang ito kailanman naging bahagi ng context. Kung hinahati ng repository mo ang guidance sa mga instruction file para sa bawat package sa isang monorepo, ito ang unang dapat suriin sa bawat pagkakataon.

May isa pang loading trap, at ito ang pinakakaraniwang anyo ng “binalewala 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, walang nilo-load si Claude Code. Ang supported bridge ay isang CLAUDE.md na ang unang linya ay @AGENTS.md. Ini-import nito ang file sa pagsisimula, at maaaring ilagay sa ibaba nito ang anumang Claude-specific na tala. Gumagana rin ang symlink kapag wala ka nang ibang kailangang idagdag. Ang pagpapasya kung ano ang dapat ilagay sa file na iyon ay hiwalay na usapin, at tinatalakay sa paghihiwalay ng agent instruction sa documentation para sa tao.

Kumpirmahing na-load ang file bago mo ito muling isulat

Huwag baguhin ang wording hanggang wala kang patunay na nakikita ng agent ang file. May dalawang check, at unahin ang mas mura.

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

Para sa mas matibay 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 ipinapakita ng matcher nito kung bakit nangyari 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 ina-append ng cat ang buong record. I-monitor ito gamit ang tail -f /tmp/instructions-loaded.log habang nagtatrabaho ka. Ini-ignore ang exit status ng event na ito, kaya makakapag-observe lamang ang hook at hindi ito makakapag-block. Kung hindi kailanman lumitaw ang nested file mo sa log sa isang session kung kailan inaasahan mong mai-load ito, itigil ang muling pagre-reword. Placement ang problema.

Ano ang ginagawa ng mahabang session sa iyong mga rule

Dalawang magkahiwalay na epekto ang nalalapat dito, at magkaiba ang kinakailangang tugon sa bawat isa.

Distansya. Ang rule na sinabi 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 malulutas sa pamamagitan ng configuration, ngunit masusukat mo ito. Patakbuhin ang parehong task sa isang bagong session. Kung gumagana ang rule roon ngunit hindi na gumagana sa malalim na bahagi ng mahabang session, distansya ang dahilan.

Compaction. Kapag napuno ang window, bina-buod ng harness ang buong conversation hanggang sa puntong iyon at nagpapatuloy mula sa buod na iyon. Ang natitira ay ang itinuring na mahalaga ng summariser, na maaaring iba sa itinuturing mong mahalaga. Idinadokumento 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 mabasa muli ang isang file sa subdirectory na iyon.

I-rank ang iyong mga instruction batay sa talahanayang iyon, at lilitaw ang pagkakasunod-sunod ng fragility. Ang rule na tina-type mo lamang sa chat ang pinaka-fragile sa session: nananatili lamang ito kung isinama ito ng summary. Kasunod nito ang rule sa packages/api/CLAUDE.md, dahil minsan lang itong na-load, nawala sa summary, at babalik lamang sa susunod na pagbasa sa directory na iyon. Ang rule sa project root file ang pinakamatibay, dahil muli itong binabasa 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 ang /clear sa pagitan ng magkakahiwalay na task; parehong nakaaapekto ang mga ito sa dalas ng pagkakataong magpasya ang summariser kung ano ang iyong mga rule.

Bakit mas nangingibabaw ang nakapaligid na code kaysa sa rule

Ito ang failure na pinakamadalas ilarawan ng mga tao ngunit pinakamadalang 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 binalewala dahil sa style. Nalamangan ka ng ebidensya.

Inilalarawan ng isang 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 tatlo, nasa isang panig ang isang abstract na pangungusap at nasa kabilang panig ang tatlong konkreto, bago, at akmang halimbawa. Karaniwang tamang behavior ang pagkopya sa lokal na pattern. Mali lamang ito rito dahil may alam ka na hindi alam ng context: legacy ang mga file na iyon.

Kaya ilagay mo iyon sa rule. Nakakayanan ng mga rule na binabanggit ang sarili nilang counter-evidence ang aktuwal na repository. Hindi ito nagagawa ng mga rule na nagsasaad lamang ng isang bare 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 makikita nito at kung paano ito dapat unawain, bago pa nito makita. Ganoon din ang dapat gawin sa anumang rule na malinaw na 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. Sa tuwing hindi nagtutugma ang code at ang file, pangalanan ang hindi pagtutugmang iyon sa file.

Hindi masusuri ang malabong rule, kaya hindi ito masusunod

Hindi masusuri ang mga pahayag na “Write clean code,” “Do not over engineer,” “Keep it simple,” at “Be careful with migrations” batay sa isang partikular na action ng agent o sa sarili mong pagsusuri. 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.

Ilapat ang test na ito sa bawat linya ng file mo. Isulat ang shell command na mag-e-exit gamit ang non-zero status kapag nilabag ang rule. Kung hindi mo maisulat ang command na iyon, hindi checkable ang rule. Ihambing ang mga pares na ito:

• Hindi checkable: “Keep functions small.” Checkable: “A function longer than 60 lines needs a comment above it explaining why.”
• Hindi checkable: “Test your changes.” Checkable: “Run npm test and paste the failure count before calling a task done.”
• Hindi checkable: “Keep files organised.” Checkable: “HTTP handlers live in src/api/handlers/. Nothing else goes in that directory.”
• Hindi checkable: “Format code properly.” Checkable: “Use 2 space indentation in .ts files.”

Pareho rin ang problema sa laki ng file, pero iba lang ang anyo. Itinatakda ng guidance ng Claude Code na dapat mas maikli sa 200 lines ang bawat instruction file, at malinaw nitong sinasabi na bumababa ang adherence kapag mas mahaba ang file. Ang 700-line file ay hindi mas matibay na instruction. Binubuo ito ng 700 linya ng mga pahayag na mas maraming pagkakataong magkasalungat, at kinakain nito ang window mo sa bawat turn, na direktang lumilitaw sa token usage mo. Saklaw ng pagsulat ng instruction file na maaaring sundin ng agent ang pag-structure ng file upang mailagay ang bawat rule sa ilalim ng heading na madaling ma-scan ng reader.

Paano i-diagnose sa loob ng sampung minuto

Patakbuhin ang mga ito ayon sa pagkakasunod-sunod. Kapag nilaktawan ang mga unang hakbang at dumiretso sa huli, nauuwi ang mga tao sa isang mahabang file ng mariing rules na 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 location at huminto. Hindi pa naaangkop ang iba pang hakbang sa listahang ito.
2. Ulitin sa isang 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 pumalya rin dito, ang rule mismo ang problema.
3. Alisin ang nakikipagkumpitensiya. Hilingin ang parehong pagbabago sa isang 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 guidance 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 nasusuri at subukan muli. Isulat muli ang rule gamit ang isang konkretong path at condition. Kung malaki ang itinaas ng compliance, ang phrasing ang naging sanhi.

Isang command lang ang Step 4. I-grep ang bawat instruction source para sa topic, hindi lamang ang 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 resulta sa dalawang file na magkaiba ang sinasabi ay ang bug mo. Burahin ang isa. Huwag subukang pagpasiyahin ang mga ito gamit ang mas matibay na wording, dahil walang ranking engine na mapagpapasahan.

Mga fix, ayon sa leverage

Mas malaki ang leverage ng bawat hakbang sa ibaba kaysa sa nauna rito, at mas malaki rin ang gastos sa pag-set up. Magsimula sa itaas kapag mura pa ang pag-reword ng isang rule. Bumaba sa susunod na hakbang kapag sapat nang mahalaga ang rule na hindi na katanggap-tanggap ang paminsan-minsang pagpalya.

1. Gawing konkreto ang rule. Magbanggit ng path, command, o condition. Idagdag ang counter-evidence na makikita ng agent sa repository, gaya ng ipinakita kanina. Libre ito at nakakaayos ng nakakagulat na dami ng mga kaso.
2. Ilapit ito sa pinamamahalaan nito. Maaaring isang nested CLAUDE.md, isang path-scoped rule sa .claude/rules/, o comment sa pinakataas ng mismong file. Sa ganitong paraan, nababasa ang rule kasabay ng code na saklaw nito. Tanggapin ang kapalit: anumang na-load sa ganitong paraan ay nawawala sa susunod na compaction at bumabalik sa susunod na matching read.
3. Ilipat ang enforcement sa isang hook. Humihiling ang prose. Nagpapasya ang hook. Tumatakbo ang hooks bilang code sa mga nakatakdang lifecycle event at ipinapatupad ang mga ito anuman ang naging konklusyon ng model.
4. Ibigay ang rule sa isang deterministic tool at alisin ang prose. Formatting, import order, line length, banned imports, at format ng commit message. ruff format, prettier --write, eslint, o isang pre-commit hook. Palaging tama ang formatter at zero tokens ang gastos nito. Karaniwang tama ang sentence at tokens ang gastos nito sa bawat turn.

Buong detalye 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 ito naman 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 ang iyong message bilang dahilan. Hinaharangan ng exit status 2 sa PreToolUse ang tool call bago ito tumakbo, at ipinapasa sa model ang iyong stderr text bilang blocking message. Nagre-resolve ang ${CLAUDE_PROJECT_DIR} sa project root, kaya gumagana ang hook kahit anong directory ang kinaroroonan ng agent. Hindi kailangang sumang-ayon ang agent sa rule, maalala ito, o nasa context pa rin nito ang rule. Hindi mangyayari ang edit.

Para sa isang flat 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 ka muna tinatanong. Kung talagang kailangang nasa system prompt level ang isang instruction sa halip na nasa user message, inilalagay ito roon ng --append-system-prompt, ngunit kailangan itong ipasa sa bawat invocation, kaya mas angkop ito sa mga script kaysa sa interactive na trabaho.

Mga bagay na hindi mo maipag-uutos na baguhin

Linawin kung aling bahagi nito ang saklaw mo. Problema ng author, at may kaukulang ayos mula sa author, ang placement, phrasing, mga conflict sa pagitan ng files, at laki ng file. Ang iba pa ay behavior ng model, at hindi ito mawawala sa mas magandang wording.

Hindi katumbas ng compliance ang pagsang-ayon. Maaaring kilalanin ng isang agent ang isang rule, maayos itong ulitin sa iyo, at labagin ito pagkalipas ng dalawang tool call. Walang kapalit ang acknowledgement at wala itong maaasahang prediksyon. 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, pagsulat ng closing summary, at pagpapatakbo ng halatang kasunod na command. Bumabalik ang mga ito kapag may rule na nagbabawal sa kanila, pero mas mababa ang dalas kaysa zero. Maaari mong sukatin ang sarili mong rate: patakbuhin ang parehong task nang 10 beses sa magkakahiwalay na fresh session at bilangin ang mga violation. Kung kailangang zero ang bilang na iyon, kailangang alisin ang rule sa prompt.

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

Hindi security boundary ang instruction file. Hinuhubog nito ang behavior ngunit hindi nito ipinapatupad ang rule. Anumang magastos kapag nagkamali, gaya ng credentials o destructive commands, ay dapat ilagay sa permissions o hook. Pareho ang prinsipyong inilalapat ng Pag-iwas na maabot ng agent ang mga secret sa data: huwag hilingin sa agent na huwag basahin ang isang file; ayusin na hindi ito mabasa ng agent.

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 kayang balewalain ng agent ay rule na hindi kailanman dapat ipinakiusap sa agent.

FAQ

Bakit binabalewala ni Claude Code ang CLAUDE.md ko?

Tingnan muna kung na-load ito bago ipagpalagay na binabalewala ito. Patakbuhin ang /context at tingnan ang listahan ng Memory files; kung wala roon ang file, hindi ito kasama sa conversation. Ipinapadala ang mga instruction file bilang user message pagkatapos ng system prompt at itinuturing ang mga ito bilang context, hindi bilang enforced configuration, kaya walang mahigpit na garantiya ng pagsunod. Sa karamihan ng aktuwal na kaso, isa ito sa apat na 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 ma-check laban sa isang action, o ipinapakita ng nakapaligid na code ang kabaligtaran ng sinasabi ng rule.

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

Wala sa kopyang nasa conversation na. Ang mga file sa itaas ng working directory ay buong nilo-load sa pagsisimula, kaya ang tekstong hawak ng model ay ang bersyon mula sa oras ng pagsisimula. Para maisama ang edit, magsimula ng bagong session o hilingin sa agent na basahin 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, nang maaasahan. Pinagdurugtong ang mga natuklasang file sa context sa halip na mag-override sa isa't isa. Inaayos ang mga ito mula sa filesystem root pababa sa working directory, kaya ang pinakamalapit na file ay binabasa lamang sa huli. Walang precedence engine na lumulutas sa mga contradiction, at sinasabi sa documentation ng Claude Code na maaaring arbitraryong lutasin ang magkakasalungat na rule. Isulat ang nested files bilang mga dagdag na rule na tumutukoy sa path na sakop ng mga ito, at burahin ang contradiction sa halip na subukang lampasan ito sa precedence.

Nananatili ba ang mga instruction ko pagkatapos ng /compact?

Depende ito sa paraan ng pag-load sa mga ito. Ang project root CLAUDE.md, mga unscoped rule, at auto memory ay muling ini-inject mula sa disk pagkatapos ng compaction. Nawawala ang mga rule na may paths: frontmatter at ang nested CLAUDE.md files sa mga subdirectory hanggang sa muling mabasa ang katugmang file. 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 project root file 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 hindi pagtukoy sa problema kaysa sa paggawa 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. Hinaharang kaagad ng PreToolUse hook na nag-e-exit na may status 2 ang tool call at ipinapasa nito sa model ang stderr text bilang dahilan, kaya gumagana ang rule kahit wala na ito sa context. Anumang kayang pagpasyahan ng formatter o linter ay dapat pangasiwaan ng tool na iyon at tuluyang alisin sa instruction file.