Kwa nini coding agents hupuuza maelekezo yako

Kwa nini mawakala wa uandishi wa msimbo (coding agents) hupuuza maelekezo yako

Mawakala wa uandishi wa msimbo hupuuza maelekezo yako kwa sababu nne, na hakuna hata moja inayotokana na wewe kuwa na adabu kupita kiasi. Kanuni hiyo haikuwepo kabisa kwenye dirisha la muktadha (context window). Kanuni hiyo ilikuwa ya jumla mno kiasi cha kushindwa kuthibitisha hatua dhidi yake. Kitu kingine kwenye muktadha kilipingana nayo, kwa kawaida ni msimbo ambao wakala alikuwa amesoma punde. Au kanuni hiyo bado imepakiwa lakini iko mbali sana nyuma ya hatua ya sasa, na wakala anafanya kazi kulingana na kile kilicho karibu naye.

Kila sababu ina suluhisho lake, kwa hivyo kazi ya kwanza ni kuzitofautisha. Herufi kubwa na neno IMPORTANT si utambuzi wa tatizo. Mitambo iliyo hapa chini inatumia Claude Code kama mfano wa kazi, kwa sababu tabia yake ya upakiaji na ufinyanzi (compaction) imeandikwa kwa kina kufikia Agosti 2026. Zana nyingine hutofautiana katika maelezo lakini hufanya kazi kwa njia ileile kimsingi.

Kwanza, maneno mawili. Context window ni kizuizi cha maandishi ambacho modeli hukiona katika hatua fulani: system prompt, faili zako za maelekezo, mazungumzo, na kila faili ambayo wakala amesoma. Harness ni programu inayozunguka modeli, kitu kinachosoma faili kutoka kwenye diski na kukusanya kizuizi hicho. Karibu kila malalamiko katika chapisho hili ni malalamiko kuhusu harness, si kuhusu modeli.

Faili la maelekezo ni ujumbe, si mpangilio

Faili la maelekezo si usanidi (configuration). Hakuna kitu katika runtime kinachosoma CLAUDE.md na kukitekeleza kwa lazima. Harness husoma faili hilo kutoka kwenye diski na kubandika matini hiyo kwenye mazungumzo. Katika Claude Code, maudhui hayo huwasilishwa kama ujumbe wa mtumiaji uliowekwa baada ya system prompt, jambo linalomaanisha kuwa modeli huona kanuni zako kama inavyoona kitu kingine chochote ulichoandika.

Hali hiyo ina matokeo yasiyopendeza. Kanuni zako hushindana na kila kipande kingine cha matini kilicho kwenye dirisha, kwa usawa. Kanuni ni madai. Faili ambalo wakala (agent) amelifungua hivi punde ni ushahidi. Pale ambapo hayo mawili yanapokinzana, ushahidi mara nyingi hushinda, na hakuna kinachotoa error, kwa sababu kwa mtazamo wa modeli, hakuna kilichoharibika.

Nyaraka rasmi zinasema hili wazi: faili za maelekezo huchukuliwa kama muktadha, si usanidi wa lazima. Ili kuzuia kitendo chochote bila kujali kile ambacho modeli imeamua, unahitaji hook, si sentensi. Shikilia mstari huo. Marekebisho mengi yaliyo mwishoni mwa chapisho hili ni mstari huo uliotumika katika kisa maalum.

Which instruction files load, and when

Claude Code walks up the directory tree from the directory you started it in. Every CLAUDE.md and CLAUDE.local.md from the filesystem root down to your working directory loads in full at launch. They are concatenated in that order, so the file closest to where you launched is read last, and within one directory the .local file is appended after the main one.

Files in subdirectories below your working directory behave differently. They do not load at launch. They load when the agent reads a file in that directory. The same is true of path scoped rules in .claude/rules/ that carry a paths: frontmatter field: they enter the context when a matching file is read, not on every turn.

That one difference explains a large share of reported failures. You put a rule in packages/api/CLAUDE.md, you ask a question about the API, and the agent answers without ever opening a file under packages/api/. The rule was not ignored. It was never present. If your repository splits guidance across per package instruction files in a monorepo, this is the first thing to check, every time.

One more loading trap, and it is the most common version of "the agent ignored my instructions": Claude Code reads CLAUDE.md, not AGENTS.md. A repository that standardised on AGENTS.md and has no CLAUDE.md gives Claude Code nothing to load at all. The supported bridge is a CLAUDE.md whose first line is @AGENTS.md, which imports the file at launch, with any Claude specific notes underneath. A symlink works too when you have nothing extra to add. Deciding what belongs in that file in the first place is a separate question, covered in splitting agent instructions from human documentation.

Thibitisha faili limepakiwa kabla ya kuliandika upya

Usibadilishe maandishi yoyote hadi uwe na uthibitisho kuwa wakala anaweza kuona faili hilo. Kuna hatua mbili za ukaguzi, na ile rahisi hufanyika kwanza.

Tekeleza /context ndani ya session. Amri hii huchapisha dirisha la sasa likiwa limegawanywa kwa kategoria, na orodha ya Memory files hutaja kila faili la maelekezo ambalo limepakiwa kikamilifu. Faili lisilokuwepo kwenye orodha hiyo halipo kwenye mazungumzo, kwa hivyo chochote unachoandika ndani yake hakitakuwa na athari. /memory huorodhesha maeneo ya faili na kuyafungua kwa ajili ya kuhaririwa, ikiwemo yale ambayo hayajakuwepo bado.

Kwa jibu la uhakika zaidi, fuatilia upakiaji wa faili. Tukio la hook la InstructionsLoaded huwashwa kila wakati CLAUDE.md au faili la sheria linapoingia kwenye muktadha, na kichujio chake hukuambia sababu ya upakiaji huo: session_start, nested_traversal, path_glob_match, include, au compact. Weka hili ndani ya .claude/settings.json:

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

Hook hupokea data yake kama JSON kupitia standard input, kwa hivyo cat huongeza rekodi nzima kwenye faili. Fuatilia kwa kutumia tail -f /tmp/instructions-loaded.log wakati unafanya kazi. Hali ya kutoka (exit status) ya tukio hili hupuuzwa, kwa hivyo hook inaweza tu kuchunguza, haiwezi kuzuia. Ikiwa faili lako lililowekwa ndani halionekani kwenye logi hiyo wakati wa session ambapo ulitarajia liwepo, acha kuliandika upya. Tatizo ni mahali lilipowekwa.

Athari za kipindi kirefu cha mazungumzo kwenye sheria zako

Kuna athari mbili tofauti zinazojitokeza hapa, na zinahitaji majibu tofauti.

Umbali. Sheria iliyowekwa katika zamu ya 1 bado iko kwenye dirisha la muktadha katika zamu ya 90, lakini sasa inashindana na zamu 90 za maandishi yaliyotolewa hivi karibuni na ambayo ni mahususi zaidi kwa kile unachokifanya sasa. Huwezi kurekebisha hili kwa usanidi, lakini unaweza kulipima. Tekeleza kazi hiyo hiyo katika kipindi kipya. Ikiwa sheria inafanya kazi hapo na kufeli ukiwa ndani sana ya kipindi kirefu, basi umbali ndio sababu.

Ufupishaji (Compaction). Dirisha linapojaa, mfumo hufupisha mazungumzo yote yaliyopita na kuendelea kutoka kwenye muhtasari huo. Kinachobaki ni kile ambacho mfumo wa ufupishaji ulihukumu kuwa muhimu, ambacho si sawa na kile unachokiona wewe kuwa muhimu. Claude Code huandika matokeo kulingana na kila utaratibu, na tofauti zake ni kubwa. Mizizi ya mradi CLAUDE.md na sheria zisizo na upeo maalum huingizwa tena kutoka kwenye diski baada ya ufupishaji. Kumbukumbu ya kiotomatiki (Auto memory) huingizwa tena kutoka kwenye diski. Sheria zenye sehemu ya mbele ya paths: hupotea hadi faili inayolingana isomwe tena. Faili za CLAUDE.md zilizowekwa ndani ya saraka ndogo hupotea hadi faili iliyo katika saraka hiyo ndogo isomwe tena.

Panga maelekezo yako kulingana na jedwali hilo na utaona mpangilio wa udhaifu unavyojitokeza. Sheria uliyoiandika kwenye gumzo pekee ndiyo kitu dhaifu zaidi katika kipindi: inabaki tu ikiwa muhtasari uliamua kuihifadhi. Sheria iliyo katika packages/api/CLAUDE.md inafuata, kwa sababu ilisomwa mara moja, ikafutwa kwenye muhtasari, na inarudi tu wakati wa usomaji unaofuata katika saraka hiyo. Sheria iliyo katika faili ya mzizi wa mradi ndiyo inayodumu zaidi, kwa sababu inasomwa tena kutoka kwenye diski kila wakati.

Kwa hivyo, ikiwa maelekezo lazima yadumu kwa kipindi chote, yanapaswa kuwekwa kwenye faili ya mzizi wa mradi bila sehemu ya mbele ya paths:. Kila kitu kingine ni makubaliano (tradeoff) unayopaswa kufanya kwa makusudi. Kusimamia kinachobaki kwenye dirisha la muktadha inashughulikia /compact kwa hoja ya mwelekeo na /clear kati ya kazi zisizohusiana, ambazo zote hubadilisha jinsi mfumo wa ufupishaji unavyoamua sheria zako zilikuwa nini.

Kwa nini msimbo uliopo unashinda kanuni

Hii ndiyo hitilafu ambayo watu huielezea mara nyingi na kuichunguza kwa uchache. Faili yako inasema ufikiaji wa database hupitia safu ya repository. Wakala huandika handler inayopiga simu kwa ORM (object relational mapper) moja kwa moja. Hukupuuzwa kwa misingi ya mtindo. Ulishindwa kwa kura na ushahidi.

Kanuni inaelezea upendeleo. Msimbo unaonyesha mmoja. Wakati wakala anapofungua faili tatu kwenye moduli inayokaribia kuhaririwa na zote tatu zinapiga simu kwa ORM moja kwa moja, muktadha unashikilia sentensi moja ya dhahania upande mmoja na mifano mitatu madhubuti, ya hivi karibuni, na inayolingana na kazi upande mwingine. Kunakili muundo wa ndani kwa kawaida ni tabia sahihi. Ni makosa hapa kwa sababu tu unajua kitu ambacho muktadha haujui: faili hizo ni za urithi (legacy).

Kwa hivyo andika hilo kwenye kanuni. Kanuni zinazotaja ushahidi wao wa kupinga huishi baada ya kukutana na repository halisi. Kanuni zinazoeleza upendeleo mtupu hazifanyi hivyo.

Ufikiaji mpya wa database hupitia app/repositories/. Faili zilizo chini ya app/legacy/ bado zinapiga simu kwa ORM moja kwa moja. Huo ni msimbo wa zamani, si muundo. Usiunakili.

Sentensi ya pili inafanya kazi hiyo. Inamwambia wakala kile anachokaribia kukuta na jinsi ya kukisoma, kabla hajajikuta nacho. Urekebishaji uleule unatumika kwa kanuni yoyote ambayo repository yako inapingana nayo waziwazi: mtindo wa commit ambao historia yako haufuati, mpangilio wa majaribio ambao nusu ya suite yako inaupuuza, au mkataba wa import unaoshikilia kwenye msimbo mpya pekee. Popote ambapo msimbo haukubaliani na faili, taja kutokubaliana huko kwenye faili.

Kanuni isiyo wazi haiwezi kuhakikiwa, hivyo haiwezi kufuatwa

"Andika code safi." "Usifanye over-engineering." "Iweke rahisi." "Kuwa makini na migrations." Hakuna hata moja kati ya hizi inayoweza kupimwa dhidi ya hatua mahususi, iwe na wakala (agent) au na wewe mwenyewe. Wakala anayepewa kanuni ambayo hawezi kuikagua dhidi ya matokeo yake anabahatisha, na wewe unakadiria ubashiri huo kwa hisia.

Hii hapa ni jaribio la kutumia kwa kila mstari kwenye faili yako. Andika shell command ambayo itatoa exit code isiyo zero wakati kanuni imevunjwa. Ikiwa huwezi kuandika command hiyo, kanuni hiyo haiwezi kuhakikiwa. Linganisha jozi hizi:

• Haiwezi kuhakikiwa: "Weka functions ndogo." Inayoweza kuhakikiwa: "Function ndefu zaidi ya mistari 60 inahitaji maelezo juu yake yakielezea kwa nini."
• Haiwezi kuhakikiwa: "Jaribu mabadiliko yako." Inayoweza kuhakikiwa: "Endesha npm test na ubandike idadi ya makosa kabla ya kutangaza kazi imekamilika."
• Haiwezi kuhakikiwa: "Weka faili zikiwa zimepangwa." Inayoweza kuhakikiwa: "HTTP handlers hukaa katika src/api/handlers/. Hakuna kitu kingine kinachopaswa kuwemo kwenye saraka hiyo."
• Haiwezi kuhakikiwa: "Format code vizuri." Inayoweza kuhakikiwa: "Tumia nafasi 2 za indentation katika faili za .ts."

"Usifanye over-engineering" ndiyo kanuni ambayo watu hukata tamaa nayo haraka, kwa sababu suluhisho si sentensi fupi, bali ndefu zaidi: kufafanua maana halisi ya mabadiliko madogo zaidi yanayofanya kazi humpa wakala vigezo ambavyo anaweza kuvilinganisha na diff yake mwenyewe.

Ukubwa ni tatizo lilelile lililojivika kofia tofauti. Mwongozo wa Claude Code unalenga chini ya mistari 200 kwa kila faili ya maelekezo na unasema wazi kuwa faili ndefu hupunguza ufuatiliaji. Faili ya mistari 700 si maelekezo imara zaidi. Ni mistari 700 ya madai yenye nafasi zaidi ya kujipinga yenyewe, na inatozwa dhidi ya window yako katika kila hatua, jambo ambalo linaonekana moja kwa moja kwenye matumizi yako ya token. Kupanga faili ili kila kanuni ikae chini ya kichwa cha habari ambacho msomaji anaweza kukichanganua kumejadiliwa katika kuandika faili ya maelekezo ambayo wakala anaweza kuitekeleza. Bora zaidi, kata sehemu zinazoelezea badala ya kutoa maelekezo: ziara ya saraka ya mahali ambapo handlers na models hukaa ni muundo ambao wakala anaweza kuutafuta anapohitaji kutoka ramani iliyochanganuliwa ya repository badala ya kuibeba kwenye window katika kila hatua.

Jinsi ya kuitambua ndani ya dakika kumi

Tekeleza hatua hizi kwa mpangilio. Kurukia hatua ya mwisho ndiyo sababu watu huishia na faili ndefu ya sheria zilizopigwa kelele ambazo bado hazifanyi kazi.

1. Thibitisha kuwa imepakiwa. Tekeleza /context na usome orodha ya faili za Memory. Ikiwa faili haipo, rekebisha eneo lake na usimame. Hakuna hatua nyingine katika orodha hii inayohusika kwa sasa.
2. Zalisha upya katika kikao kipya. Anzisha kikao kipya na upe kazi ndogo zaidi ambayo inapaswa kuchochea sheria hiyo. Kufanya kazi hapa lakini kushindwa katika kikao kirefu kunaashiria umbali au mgandamizo (compaction). Kushindwa hapa pia inamaanisha sheria yenyewe ndiyo tatizo.
3. Ondoa ushindani. Omba mabadiliko yaleyale katika saraka ambayo msimbo wake uliopo tayari unafuata sheria hiyo. Ikiwa utiifu utarejea, msimbo uliouzunguka ulikuwa ukipinga maelekezo yako.
4. Tafuta mgongano. Faili mbili zinazotoa mwongozo tofauti kwa tabia ileile ni hitilafu iliyoandikwa: mfano unaweza kuchagua moja kiholela, na hautakuambia kuwa umefanya hivyo.
5. Ifanye iweze kukaguliwa na ujaribu tena. Andika upya sheria kwa kutumia njia mahususi na sharti fulani. Kuruka kwa kiasi kikubwa katika utiifu kunamaanisha uundaji wa sentensi ulikuwa ndio chanzo cha tatizo.

Hatua ya 4 ni amri moja. Tafuta (grep) kila chanzo cha maelekezo kwa ajili ya mada hiyo, si tu faili uliyokuwa ukihariri:

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

Matokeo katika faili mbili zinazosema mambo tofauti ndiyo hitilafu yako. Futa moja. Usijaribu kuzipanga kwa kutumia maneno makali zaidi, kwa sababu hakuna injini ya kupanga (ranking engine) ya kukata rufaa.

Mbinu za kurekebisha, kulingana na ufanisi wake

Kila hatua hapa chini ina ufanisi mkubwa zaidi kuliko ile iliyotangulia, lakini inahitaji gharama kubwa zaidi ya usanidi. Anza juu wakati sheria ni rahisi kurekebisha. Sogeza chini pale sheria inapokuwa muhimu kiasi kwamba makosa ya mara kwa mara hayakubaliki.

1. Fanya sheria iwe dhahiri. Taja path, command, au sharti. Ongeza ushahidi wa kukanusha ambao wakala ataupata kwenye repository, kama ilivyoonyeshwa awali. Hii haina gharama na inatatua sehemu kubwa ya matatizo.
2. Iweke karibu na kitu inachokisimamia. CLAUDE.md iliyowekwa ndani ya nyingine, sheria inayohusu path maalum katika .claude/rules/, au maoni (comment) juu ya faili husika. Sheria hiyo itasomwa wakati uleule na msimbo (code) inayoihusu. Kubali matokeo yake: chochote kinachopakiwa kwa njia hiyo huondoka wakati wa compaction inayofuata na kurudi kwenye usomaji unaofuata.
3. Hamishia utekelezaji kwenye hook. Maelezo ya maandishi huomba. Hook huamua. Hook huendeshwa kama msimbo katika matukio maalum ya lifecycle na hutumika bila kujali kile ambacho modeli imeamua.
4. Ipe sheria hiyo zana ya kiufundi (deterministic tool) na ufute maelezo ya maandishi. Uumbizaji (formatting), mpangilio wa import, urefu wa mstari, import zilizopigwa marufuku, umbo la commit message. ruff format, prettier --write, eslint, au hook ya pre-commit. Kifaa cha kuumbiza huwa sahihi kila wakati na hakitumii tokens. Sentensi huwa sahihi mara nyingi lakini hutumia tokens kila wakati.

Hatua ya 3 kwa ukamilifu. Tuseme faili za migration hazipaswi kuhaririwa na wakala. Iweke hii katika .claude/settings.json:

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

Na hii katika .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

Endesha chmod +x .claude/hooks/guard-migrations.sh, kisha anza session mpya na umwombe wakala kuhariri faili iliyo chini ya migrations/. Uhariri huo utakataliwa na ujumbe wako utarudi kama sababu. Exit status 2 kwenye PreToolUse huzuia wito wa zana (tool call) kabla haujaanza, na maandishi yako ya stderr hupelekwa kwa modeli kama ujumbe wa kuzuia. ${CLAUDE_PROJECT_DIR} inarejelea mzizi wa mradi (project root), kwa hivyo hook hufanya kazi bila kujali saraka (directory) ambayo wakala yupo. Wakala hahitaji kukubaliana na sheria, kukumbuka sheria, au kuwa na sheria hiyo kwenye muktadha wake. Uhariri hautafanyika.

Kwa kizuizi cha jumla kisicho na mantiki yoyote, permissions.deny katika mipangilio yako hufanya kazi hiyo hiyo bila kuhitaji script ya kutunza, na njia za ruhusa huamua nini kinaendeshwa bila kukuuliza kwanza. Ikiwa maelekezo yanapaswa kuwa katika kiwango cha system prompt badala ya ujumbe wa mtumiaji, --append-system-prompt huiweka hapo, ingawa lazima ipitishwe kila wakati inapoitwa, jambo ambalo linafaa zaidi kwa script kuliko kazi za maingiliano (interactive work).

Mambo ambayo huwezi kuyaondoa kwa maelekezo

Elewa wazi ni sehemu ipi ya mchakato huu ni ya kwako. Mpangilio, uandishi, migogoro kati ya faili, na ukubwa wa faili ni matatizo ya mwandishi yanayohitaji marekebisho ya mwandishi. Sehemu nyingine ni tabia ya mfumo, na kutumia maneno bora zaidi hakutaiondoa.

Kukubali siyo kutii. Wakala atakubali sheria, atairudia kwako kwa usahihi, na kuivunja baada ya hatua mbili za kutumia zana. Kukubali huko hakugharimu chochote na hakutabiri chochote. Usikichukulie kama suluhisho, na usikihesabu kama jaribio.

Baadhi ya tabia ni sugu. Kuongeza maoni, kuongeza ushughulikiaji wa makosa wa kujilinda, kuandika muhtasari wa kuhitimisha, kuendesha amri inayofuata iliyo dhahiri. Hizi hurudi hata chini ya sheria inayozikataza, kwa kiwango kilichopungua badala ya kutoweka kabisa. Unaweza kupima kiwango chako mwenyewe: endesha kazi ileile mara kumi katika vipindi vipya na uhesabu ukiukaji. Pale ambapo namba hiyo inahitaji kuwa sifuri, sheria hiyo lazima iondolewe kwenye maelekezo. Kusema kazi imekamilika wakati sehemu yake bado haijafanyika ni tabia ya aina moja, na ukarabati wake ni wa kimuundo badala ya maneno: ujuzi wa kutokuwa mvivu hubadilisha sentensi na kutumia Depth Tree pamoja na faili za kizuizi ambazo wakala lazima azimalize kabla ya kudai kazi imekamilika.

Kipindi chako mwenyewe kinakuwa mfano. Ikiwa wakala alivunja sheria katika hatua ya 12 na ukamwacha apite, ukiukaji huo sasa unakaa kwenye muktadha kama kielelezo, na ni wa hivi karibuni zaidi kuliko sheria yenyewe. Sahihisha ukiukaji pindi tu unapoona. Ukiukaji usiosahihishwa hufundisha sehemu iliyobaki ya kipindi hicho.

Faili ya maelekezo siyo mpaka wa usalama. Inaunda tabia na haitekelezi kwa nguvu. Kitu chochote ambacho kukikosea ni ghali, kama vitambulisho au amri za uharibifu, kinapaswa kuwa katika ruhusa au hook. Kuweka siri nje ya uwezo wa wakala kunatumia kanuni hiyo hiyo kwa data: usimwombe wakala asisome faili, panga faili hiyo isiweze kusomeka.

Toleo fupi. Thibitisha kuwa faili imepakiwa, fanya sheria iweze kukaguliwa, iweke karibu na kitu inachokisimamia, na wakati kiwango cha makosa bado ni muhimu, iondoe kwenye maelezo ya maandishi. Sheria ambayo wakala hawezi kuipuuza ni sheria ambayo haikuwahi kuombwa kwa wakala.

FAQ

Kwa nini Claude Code inapuuza CLAUDE.md yangu?

Hakikisha kuwa faili imepakiwa kabla ya kudhani imepuuzwa. Tekeleza /context na uangalie orodha ya Memory files; faili ambayo haijaorodheshwa hapo haipo kwenye mazungumzo. Faili za maelekezo huwasilishwa kama ujumbe wa mtumiaji baada ya system prompt na huchukuliwa kama muktadha badala ya usanidi wa lazima, kwa hivyo hakuna hakikisho la utiifu mkali. Kesi nyingi za kweli hutokana na moja ya mambo haya manne: faili iko kwenye subdirectory ambayo wakala haijawahi kuisoma, faili mbili zinakinzana na modeli ikachagua moja kiholela, kanuni ni ya jumla sana kiasi kwamba haiwezi kutumika kukagua kitendo, au msimbo uliopo unaonyesha kinyume cha kile kanuni inachosema.

Je, kuhariri faili ya maelekezo katikati ya kipindi cha kazi hubadilisha kitu?

Hapana kwa nakala iliyo tayari kwenye mazungumzo. Faili zilizo juu ya saraka yako ya kazi hupakiwa kikamilifu wakati wa kuanza, kwa hivyo maandishi yaliyo na modeli ni yale ya wakati wa kuanza. Ili kutumia marekebisho, anza kipindi kipya, au mwambie wakala asome faili hiyo kwa kutumia zana zake za kawaida za faili, jambo ambalo huweka toleo la sasa kwenye mazungumzo kama ujumbe mpya. Baada ya compaction, faili ya mzizi wa mradi husomwa tena kutoka kwenye diski, kwa hivyo toleo jipya hufika wakati huo pia.

Ni faili ipi inayoshinda wakati CLAUDE.md ya mzizi na ile ya ndani zinapokinzana?

Hakuna inayoshinda kwa uhakika. Faili zilizogunduliwa huunganishwa kwenye muktadha badala ya kubatilisha nyingine, zikipangwa kutoka mzizi wa mfumo wa faili hadi kwenye saraka yako ya kazi, kwa hivyo faili iliyo karibu zaidi husomwa mwisho. Hakuna injini ya kipaumbele inayotatua migongano, na nyaraka za Claude Code zinasema kuwa kanuni zinazokinzana zinaweza kutatuliwa kiholela. Andika faili za ndani kama nyongeza zinazotaja njia wanayoisimamia, na ufute mgongano badala ya kujaribu kuushinda.

Je, maelekezo yangu yanabaki baada ya /compact?

Inategemea jinsi yalivyopakiwa. Faili ya mzizi wa mradi CLAUDE.md, kanuni zisizo na upeo, na kumbukumbu ya kiotomatiki huingizwa tena kutoka kwenye diski baada ya compaction. Kanuni zenye paths: frontmatter na faili za CLAUDE.md zilizomo ndani ya subdirectories hupotea hadi faili inayolingana isomwe tena. Chochote ulichoandika kwenye gumzo pekee hubaki ikiwa tu summariser imekihifadhi. Ikiwa kanuni lazima idumu katika kipindi chote, iweke kwenye faili ya mzizi wa mradi bila paths: frontmatter.

Ni lini kanuni inapaswa kuwa hook badala ya maelezo?

Wakati ukaguzi ni wa kideterministi na gharama ya kukosa ni kubwa kuliko gharama ya kuandika script ndogo. Vizuizi vya njia ya faili, amri zinazohitajika kabla ya commit, na wito wa zana zilizopigwa marufuku zote zinafaa. Hook ya PreToolUse inayotoka na status 2 huzuia wito wa zana moja kwa moja na kurudisha maandishi yako ya stderr kwa modeli kama sababu, kwa hivyo inabaki bila kujali kama kanuni bado iko mahali popote kwenye muktadha. Chochote ambacho formatter au linter inaweza kuamua kinapaswa kumilikiwa na zana hiyo na kufutwa kabisa kutoka kwenye faili ya maelekezo.