Plan Mode v Claude Code: vodnik po korakih in 4 faze v 2026

Dodatna navodila so v dokumentaciji Ailoot.

Kaj je Plan Mode in zakaj sam po sebi ni dovolj?#

V običajnem načinu Claude Code takoj piše kodo, in če ne spremljate dogajanja, lahko od nikoder dobite diff v številnih datotekah. Plan Mode obrne vrstni red korakov: najprej raziskava in načrtovanje, nato odobritev in šele zatem spremembe.

Anthropic v uradni dokumentaciji Plan Mode opisuje takole:

Sliši se preprosto, vendar se za tem skriva glavna sprememba. Plan Mode spremeni ritem dela: najprej se dogovorimo, potem ukrepamo. Gre za spremembo načina, ne za kozmetični popravek. Težava za vibe coderje je, da agenti umetne inteligence radi hitijo. Če v običajnem načinu prosite: »Dodaj Googlovo avtentikacijo«, bo Claude v minuti napisal kodo, vendar bo polovica datotek napačnih. V Plan Mode se ista zahteva spremeni v besedilni načrt, ki ga lahko v dveh minutah preberete in popravite, preden se dotaknete kakršne koli kode.

Tu je past, o kateri mednarodni vodiči nikoli ne pišejo. Plan Mode je sam po sebi šibko orodje: načrt obstaja samo v trenutnem pogovoru. Zaprite okno in načrt je izgubljen. Ne morete ga predati drugemu agentu. Ni različic ali zgodovine. Če je naloga velika (refaktoriranje modula s 30 datotekami, selitev v novo podatkovno bazo), bo načrt hitro dosegel mejo kontekstnega okna in začel izgubljati kakovost.

Zato Plan Mode dobro deluje skupaj z mapo plans/ v repozitoriju. Načrt se shrani kot plans/2026-05-21-google-oauth.md, razdeli na faze s potrditvenimi polji in vsak naslednji agent ga lahko prevzame. Tako deluje inženiring konteksta — upravljanje konteksta pred pozivom, ne med njim.

Kako v Claude Code vklopite Plan Mode?#

Najhitrejši način med sejo je bližnjica na tipkovnici:

Shift+Tab           # cycles through modes: default → acceptEdits → plan

Po dveh pritiskih se na dnu terminala prikaže kazalnik ⏸ plan mode on. S tretjim pritiskom se vrnete v običajni način. To je najpriročnejša metoda — način vklopite sproti, ko opazite, da naloga postaja večja.

Drugi način je, da pred posamezen poziv dodate predpono:

/plan write a plan to migrate the database from MySQL to Postgres

Ta možnost je uporabna, ko ste v načinu samodejnega sprejemanja in ga ne želite spreminjati za celotno sejo. Ena zahteva v Plan Mode, nato pa se delo nadaljuje kot prej.

Tretji način je ob zagonu seje:

claude --permission-mode plan

Uporabite ga, ko vnaprej veste, da je za nalogo potrebno načrtovanje. Na primer pred večjim refaktoriranjem ali selitvijo.

Četrti način je, da v projektu določite privzeti način v .claude/settings.json:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Kdaj je to uporabno? Ko ekipa dela na kompleksnem sistemu, v katerem lahko vsaka sprememba vpliva na sosednje module. Privzeti Plan Mode takrat vse zaščiti pred nenamernimi spremembami.

Peti pogosto spregledani trik: Ctrl+G odpre načrt v urejevalniku besedila. Uporabite ga, ko je načrt skoraj pravi, vendar morate preoblikovati 2-3 točke ali dodati omejitev. Uredite ga ročno, shranite in Claude bo nadaljeval z vašo različico.

Katere so Anthropicove kanonične 4 faze v Plan Mode: Explore, Plan, Implement, Commit?#

Številni vodiči opisujejo 3 faze (Explore-Plan-Execute) ali samo 2 (Plan-Implement). To so poenostavitve. Anthropic v svojem uradnem vodniku po najboljših praksah opiše natanko 4 faze. Razlika je pomembna: ločena faza Commit poskrbi, da zabeležite rezultat, namesto da bi delo pustili pri »tu sem naredil še nekaj popravkov, potrdil jih bom pozneje« — kar je najpogostejši vzrok za izgubljeno delo.

Natančnejši kot je načrt, manj ponovitev zahteva izvedba. Če za načrtovanje porabite 10 minut, za izvedbo zadostuje en poziv. Če načrt na hitro skicirate v minuti, bo izvedba zahtevala eno uro popravljanja.

Tako so videti 4 faze pri dodajanju Google OAuth (primer iz Anthropic Docs):

Tudi pozivi se v vsaki fazi razlikujejo. V Explore: »preberi /src/auth in ugotovi, kako obravnavamo seje in prijavo«. V Plan: »Želim dodati Google OAuth. Katere datoteke je treba spremeniti? Pripravi načrt.« V Implement: »izvedi tok OAuth po svojem načrtu, napiši teste, zaženi testno zbirko in odpravi napake«. V Commit: »ustvari potrditev z opisnim sporočilom in odpri PR«.

Pomembna podrobnost: Plan Mode Claudu ne preprečuje izvajanja ukazov za raziskovanje. Dovoljeni so Read, LS, Glob, Grep, spletno pridobivanje vsebine in ukazi lupine za raziskovanje. Prepovedani so samo Edit, Write in vsa spreminjajoča se opravila v datotečnem sistemu. To pomeni, da Claude lahko prebere strukturo projekta, zažene git log in pregleda teste — ne more pa ničesar pomotoma spremeniti.

Kako preberete Claudeov načrt in se odločite, ali ga odobriti?#

Ko Claude konča pripravo načrta, prikaže možnosti za naslednji korak:

• Odobri in začni v samodejnem načinu
• Odobri in sprejmi urejanja
• Odobri in ročno preglej vsako urejanje
• Nadaljuj načrtovanje s povratnimi informacijami
• Dopolni z Ultraplan (pregled v brskalniku)

Spretnost odločanja o tem, ali načrt odobriti, je ključna pri Plan Mode. Zlahka samodejno pritisnete »Approve«, nato pa morate povrniti potrditve. Laskavi AI želi hitro odgovoriti, vi pa želite čim prej priti do kode. Oba se motita.

Dober načrt izpolnjuje 7 meril:

1. Konkretna imena datotek. Ne »posodobil bom avtentikacijo«, temveč »spremenil bom src/auth/login.ts:42-58, ustvaril src/auth/oauth-callback.ts in posodobil src/auth/session.ts:103.«
2. Določeno zaporedje. Načrt je razdeljen na faze ali korake, namesto da pravi »vse to bom naredil nekje«.
3. Navedene zunanje odvisnosti. Če naloga zahteva novo knjižnico, je ta navedena. Če so potrebne spremenljivke okolja, so navedene.
4. Navedena tveganja. Dober načrt pove: »Selitev lahko pokvari obstoječe seje; preveriti je treba X.« Slab načrt o stranskih učinkih molči.
5. Opredeljena merila uspeha. »Testi v test/auth uspešno prestanejo izvajanje, linter je brez napak, razvojni strežnik pa se zažene brez napak.«
6. Brez predpostavk, izmišljenih kar tako. Če Claude reče »uporabil bom knjižnico Z«, preverite: ali ste jo sploh namestili v projekt? Če si jo je umetna inteligenca izmislila, je ne boste našli v package.json.
7. Načrt se prilega na zaslon. Če načrt za preprosto funkcijo obsega 200 vrstic, je naloga verjetno prevelika za en načrt. Razdelite jo na dele.

Če načrt ne prestane preverjanja, imate tri možnosti:

• Nadaljujte načrtovanje s povratnimi informacijami — Claudu podajte konkreten komentar o tem, kaj vam ni všeč, in načrt bo preoblikoval.
• Ctrl+G — odprite načrt v urejevalniku, ga ročno uredite in shranite. Claude bo nadaljeval z vašo različico.
• Dopolnite z Ultraplan — načrt se prenese v način brskalnika Claude Code na spletu, kjer pregledate razdelke in jih komentirate, nato pa ga zaženete lokalno ali v oblaku.

Če gre med izvedbo kaj narobe, ne silite naprej. Vrnite se v Plan Mode in preoblikujte načrt. To je 10-krat ceneje kot pozneje povrniti 40 potrditev.

Plan Mode + mapa plans/: kombinacija za dolg kontekst#

Plan Mode je način Claude Code. Mapa plans/ je metodologija, ki je zgrajena na njem. Če Plan Mode uporabljate brez mape, boste po eni uri dela dosegli mejo.

Takole deluje. Claudeovo kontekstno okno je spomin seje. V Opus 4.7 lahko sprejme 1 milijon žetonov, vendar je to obseg celotnega pogovora. Če v enem pogovoru načrtujete kompleksno nalogo, nato zahtevate izvedbo, obravnavate napako in še nekaj drugega, se okno »napihne«. Claude začne pozabljati zgodnje odločitve, zamenjevati kontekste in znova postavljati vprašanja.

Rešitev je zlato pravilo: ena naloga — en pogovor.

Postopek je naslednji:

1. Pogovor 1 — oblikujte načrt. Vklopite Plan Mode, opišite nalogo in Claude pripravi načrt. Shranite ga v plans/2026-05-21-feature-name.md. Zaprite okno.
2. Pogovor 2 — razdelite ga na faze. Odprite nov klepet. Prosite: »vzemite plans/2026-05-21-feature-name.md in ga razdelite na faze«. Posodobljeno datoteko shranite.
3. Pogovor 3 — izvedite 1. fazo. Odprite nov klepet. Prosite: »izvedi 1. fazo iz plans/2026-05-21-feature-name.md in označi elemente kot dokončane.« Zaprite okno.
4. Pogovor 4 — izvedite 2. fazo. Ponovite postopek.

Kaj vam to prinese? Kontekstno okno vsakega pogovora ostane sveže. Claude v 3. fazi ne pozna podrobnosti 1. faze, pozna pa načrt, ker je datoteka plans/ v repozitoriju. Vsak naslednji agent (bodisi podagent, nova seja ali izvajanje prek /goal) lahko prevzame načrt in nadaljuje.

Primerjava pristopov:

Vsaka funkcija ima svojo datoteko z načrtom. Če se morate čez tri mesece spomniti, zakaj ste izbrali enega ponudnika plačil namesto drugega, lahko odprete ustrezen načrt in preberete zgodovino odločitev: o čem so razpravljali, katere možnosti so obravnavali in zakaj so izbrali prav to pot.

To so živi delovni načrti; statična dokumentacija zastara v nekaj mesecih.

Kako doseči, da Claude dela med vašim spanjem s Plan Mode in /goal?#

Glavna omejitev dolgih sej z umetno inteligenco ni sam model, ampak oseba, ki pritiska Enter. Vsakič, ko Claude doseže konec poteze, počaka na vaš odgovor. /goal odpravi to čakanje.

Skladnja je preprosta:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

Pogoj je lahko dolg do 4000 znakov. V posamezni seji je lahko aktiven en cilj. Po vsaki potezi mini model Haiku pregleda prepis in odloči: »pogoj izpolnjen — končaj« ali »ni izpolnjen — nadaljuj z naslednjo potezo«. Evalvator ne kliče orodij; samo bere.

Vzdevki za izklop: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Kombinacija s Plan Mode je videti takole:

1. Vklopite Plan Mode (dvakrat pritisnite Shift+Tab).
2. Prosite: »pripravi načrt za selitev podatkovne baze z MySQL na Postgres in ga shrani v plans/2026-05-21-postgres-migration.md skupaj s fazami in merili«.
3. Preglejte načrt, ga uredite in odobrite.
4. Zapustite Plan Mode (še enkrat pritisnite Shift+Tab).
5. Določite cilj: »dokončaj vse faze v plans/2026-05-21-postgres-migration.md, odkljukaj polja, vsi testi morajo uspešno prestati izvajanje, sicer se ustavi po 50 potezah«.
6. Zaprite prenosnik in pojdite spat.

Zjutraj preverite rezultat: prikazano bo »✓ cilj dosežen« ali »◎ ustavljeno po 50 potezah« ter zgodovina opravljenega dela.

Za /goal veljajo tri bistvena pravila, sicer boste zapravljali žetone:

Pravilo 1: Merljivo končno stanje. »Naj bo videti lepo« je slabo. »npm test vrne 0, npm run lint vrne 0 in v CHANGELOG.md je dodan vnos« je dobro.

Pravilo 2: Izrecno preverjanje. Pogoj se mora nanašati na nekaj preverljivega: ukaz, datoteko ali končno točko. Ne »vse deluje«, temveč »curl localhost:3000/api/users vrne 200«.

Pravilo 3: Omejite število potez. Vedno dodajte »ali se ustavi po N potezah«. Anthropic v dokumentaciji izrecno priporoča:

Če vklopite /goal brez omejitve »ali se ustavi po«, lahko vaš proračun izgine čez noč.

Kateri 4-stopenjski cikel spremeni Plan Mode v inženirski proces?#

Pogosta napaka je spraševati »kako naj to popravim?«: Claude poda rešitev, vi jo uporabite, a nič ne deluje ali pa se stanje poslabša. To je »laskavo pritrjevanje AI«: model je naučen hitro odgovoriti, vi pa želite čim prej priti do kode. To rešuje 4-stopenjski cikel.

Ta 4-stopenjski cikel to vedenje omeji. Uporablja se zaporedno v eni seji Plan Mode:

1. korak. Ugotovite dejstva brez rešitve.

Poziv: »Doživljam naslednje: [opis simptoma]. Vaša naloga je zdaj ugotoviti dejstva. Vse rešitve, zamisli in nasveti so prepovedani. Samo: kaj opažam, katere korake je mogoče ponoviti, kateri podatki so na voljo in kateri manjkajo. Trdi pogoj za ustavitev: NE predlagajte rešitev; zabeležite samo diagnozo.«

Tako zajezimo prvi vzgib umetne inteligence: »tukaj je rešitev«. Claude se mora ustaviti pri »kaj je znano in kaj ni znano«.

2. korak. Razvijte možnosti s primeri.

Poziv: »Zdaj, ko je diagnoza znana, na spletu poiščite primere reševanja podobnih težav. Najdite vsaj 3 različne pristope. Za vsakega navedite povezavo do primarnega vira, kratek opis ter prednosti in slabosti za naš primer.«

Tako zajezimo drugi vzgib umetne inteligence: »rešitev si bom izmislil na mestu«. Pošljemo jo v svet po pristope, ki jih lahko preverimo.

3. korak. Podroben načrt s tveganji.

Poziv: »Izberite najboljšo možnost iz 2. koraka in pripravite podroben načrt: katerih konkretnih datotek se dotakniti, kaj dodati, kaj odstraniti, katere teste napisati, kaj se lahko pokvari in katera tveganja se skrivajo 2-3 korake naprej.«

To je znana faza Plan, vendar z eno razliko: temelji na preverjenih možnostih iz 2. koraka, ne na Claudeovih ugibanjih.

4. korak. Samopreverjanje načrta.

Poziv: »Zdaj obvezno preverite načrt. Pošteno ga preglejte: ali vsebuje dele, ki ste si jih izmislili in jih niste preverili v kodi, dokumentaciji ali primerih iz 2. koraka? Če jih najdete, jih označite in popravite načrt.«

To je zadnji filter. Claude mora preveriti svoje sklepanje in priznati, kje je haluciniral. V tem koraku je običajno treba popraviti vsaj 2 elementa načrta.

Po teh 4 korakih je načrt pripravljen za odobritev. Izvedbe se lahko lotite z zaupanjem, da je naloga razumljena, da so bile možnosti pretehtane in tveganja upoštevana.

Ta metodologija je namenjena diagnosticiranju težkih napak in arhitekturnim odločitvam — tam, kjer je cena napake visoka. Pri uporabi s Plan Mode odpravi glavno težavo vibe coderjev: »AI mi je ponudil rešitev, uporabil sem jo in vse se je pokvarilo.«

Katerih 5 pripravljenih pozivov je uporabnih za običajne naloge v Plan Mode?#

Predloga 1. Refaktoriranje modula.

I'm enabling Plan Mode. Task: refactor the {module-name} module.

Step 1: Study the current structure of the {module-path} module. Describe:
- which files are part of the module
- which external dependencies it has
- which parts are duplicated
- which functions are overcomplicated

Step 2: Find 2-3 examples online of refactoring similar modules.
At least 1 source must be official Anthropic or related framework documentation.

Step 3: Create a refactoring plan in plans/YYYY-MM-DD-refactor-{module}.md:
- which files to rename
- which functions to extract into separate modules
- which tests to keep and which to rewrite
- risks: what could break for users

Step 4: Self-check. Are there any assumptions in the plan that are "pulled out of thin air"?
Rewrite or remove them.

Predloga 2. Selitev podatkovne baze.

I'm enabling Plan Mode. Task: migrate the database from {old} to {new}.

Step 1: Study the current database schema using {schema-reading-command}. Describe:
- which tables exist and their size
- which relationships, indexes, and constraints there are
- where migrations are stored
- which data is critical

Step 2: Find precedents for {old → new} migrations in production projects.
At least 3 different approaches: pg_dump, dual-write, blue-green.
For each, list the pros and risks for our data size.

Step 3: Create a migration plan in plans/YYYY-MM-DD-db-migration.md:
- phases (backup, migration, verification, switchover)
- success criteria for each phase
- rollback plan if something goes wrong
- downtime or no downtime

Step 4: Self-check. Are all figures supported by documentation?
Have all steps been mentally checked against the dev environment?

Predloga 3. Dodajanje nove funkcije.

I'm enabling Plan Mode. Task: add the {description} feature to the project.

Step 1: Study how similar features currently work in the project.
Specifically, look at:
- {file-1}
- {file-2}
- which architectural patterns are used
- which tests are written for similar features

Step 2: Find how this feature is implemented in open-source projects
with a similar architecture. At least 2 different approaches.

Step 3: Create a plan in plans/YYYY-MM-DD-feature-{name}.md:
- list of new files
- list of changed files with specific lines
- implementation sequence
- which tests to add
- what to add to CLAUDE.md as a rule for future sessions

Step 4: Self-check. Does the plan follow the project's architecture?
Does it assume libraries that haven't been installed yet?

Predloga 4. Pisanje testov.

I'm enabling Plan Mode. Task: cover the {name} module with tests.

Step 1: Study the {path} module. Identify:
- public functions and their signatures
- internal functions we will NOT test (implementation details)
- edge cases: empty input, errors, concurrent access

Step 2: Find test examples for a similar class of tasks
in popular open-source projects using the same framework.

Step 3: Create a test plan in plans/YYYY-MM-DD-tests-{module}.md:
- for each public function, a list of tests
- which mocks are needed
- which fixtures
- which verification approach (assertion style)

Step 4: Self-check. Do all tests check behavior rather than implementation?
Does the coverage include edge cases?

Predloga 5. Odpravljanje kompleksne napake.

I'm enabling Plan Mode. Task: understand the cause of the error {symptom-description}.

Step 1: ESTABLISH THE FACTS. Solutions and ideas are prohibited. Only:
- what I observe (exact wording of the error)
- reproducible steps
- what data is available (logs, traces, library versions)
- what data is missing (what needs to be collected additionally)

Step 2: Find precedents for this error.
At least 3 sources: GitHub issues and documentation.
For each, provide a link and a brief summary of the solution.

Step 3: Create a diagnostic plan in plans/YYYY-MM-DD-bug-{name}.md:
- which hypotheses to check (sorted by likelihood)
- which commands/scripts to run to check each one
- the expected result of each check

Step 4: Self-check. Are there any hypotheses in the plan that are "pulled out of thin air"?
Are all hypotheses tied to facts from Step 1?

Kopirajte predlogo, zamenjajte {parameters} s svojimi vrednostmi in jo prilepite v Claude Code v Plan Mode. Rezultat je delujoč načrt v mapi plans/, ki ga odobrite in uporabite za izvedbo.

Plan Mode ali običajni način: katerega izbrati?#

Anthropic to neposredno pove v svoji dokumentaciji:

Ločen načrt preskočite samo, kadar je dejanski diff majhen, razumljen in ima nizko tveganje. Načrtujte, kadar morate odkriti pristop ali uskladiti tvegane spremembe med komponentami. Poznavanje imen datotek ali povzetek cilja v enem stavku ne odpravi tveganj selitve, preverjanja pristnosti ali celovitosti podatkov.

Tabela za odločitev:

Pred izbiro načina vprašajte, ali razumete pristop, stranske učinke in preverjanje. Neposredno delajte na majhni, lokalni spremembi z nizkim tveganjem in očitnim preverjanjem. Najprej načrtujte pri negotovosti, neznani kodi, selitvi, preverjanju pristnosti ali usklajevanju komponent, tudi če lahko že naštejete vseh 3-5 prizadetih datotek.

Kako združiti Plan Mode + CLAUDE.md + podagente za zanesljivo delo?#

CLAUDE.md je datoteka, ki jo Claude prebere na začetku vsake seje, tudi v Plan Mode. Če v njej piše »nikoli ne zapiši datumov v kodo; vedno jih pridobi iz podatkovne baze«, načrt nikoli ne bo predlagal zapisovanja datumov v kodo. Če takega pravila ni, lahko načrt predlaga karkoli.

Kombinacija deluje takole:

1. plast. CLAUDE.md določa pravila.

Datoteka določa projektni sklad, arhitekturna načela, prepovedi (»ne uporabljaj opuščenih API-jev«) in zahteve (»vsa e-poštna sporočila morajo uporabljati skupno postavitev«). Podroben vodnik: Kako nastaviti CLAUDE.md.

2. plast. Plan Mode uporabi pravila za nalogo.

Ko vklopite Plan Mode in zahtevate »dodaj OAuth«, Claude prebere CLAUDE.md, upošteva pravila (»žetone shrani v Redis, ne v podatkovno bazo«) in jih vključi v načrt. Načrt je skladen s projektno arhitekturo.

3. plast. Podagenti razdelijo delo.

Če je načrt razdeljen na faze, lahko vsako dodelite ločenemu podagentu. Vsak podagent dela v svojem kontekstnem oknu in ne obremenjuje glavnega. Načrt v plans/ ostane osrednji vir resnice: podagenti ga preberejo, izvedejo svojo fazo in posodobijo potrditvena polja.

Katerih 7 napak pokvari Plan Mode?#

Napaka 1. Načrt obstaja samo v klepetu.

Simptom: napisali ste načrt, zaprli okno in se morate vrniti naslednji dan — vendar ni ničesar; kontekst je izgubljen. Rešitev: načrt vedno shranite v plans/YYYY-MM-DD-feature-name.md v repozitoriju. Klepet je miza, datoteka je arhiv.

Napaka 2. Vse naloge so v enem klepetu.

Simptom: v eni seji se pogovarjate o avtentikaciji, nato o selitvi, nato o oblikovanju uporabniškega vmesnika in še o napaki. Kontekstno okno se »napihne« in Claude pozabi prejšnje stvari. Rešitev: ena naloga — en pogovor. Ko je načrt končan, zaprite okno. Ko začnete izvedbo, odprite novega.

Napaka 3. En načrt s 3000 vrsticami brez faz.

Simptom: načrt obstaja, vendar nima potrditvenih polj ali razdelkov. Nemogoče je ugotoviti, kaj je končano in kaj ne. Naloge ni mogoče delegirati. Rešitev: vsak načrt razdelite na 3-7 faz. Vsaka faza naj bo seznam potrditvenih polj s konkretnimi dejanji.

Napaka 4. Pred načrtom ni temeljite raziskave.

Simptom: Claude predlaga rešitev po občutku, ker ga niste prosili, naj poišče primere. Teden pozneje ugotovite, da je odprtokodna skupnost že dolgo uporabljala boljši pristop. Rešitev: 2. korak 4-stopenjskega cikla — Claude naj pred pripravo načrta na spletu poišče 2-3 primere.

Napaka 5. Laskavi AI ponudi rešitev brez diagnoze.

Simptom: vprašate »kako naj odpravim napako X?«, Claude poda rešitev, uporabite jo, a nič ne deluje ali pa se stanje poslabša. Rešitev: vedno začnite z »ugotovi dejstva; rešitve so prepovedane«. Šele po diagnozi nadaljujte z možnostmi.

Napaka 6. Preskočite samopreverjanje.

Simptom: načrt je videti verjeten, vendar vsebuje 2-3 predpostavke, izmišljene kar tako (izmišljena knjižnica, neobstoječi API ali napačna različica). Izvedba se na teh mestih pokvari. Rešitev: 4. korak 4-stopenjskega cikla — Claude naj pošteno znova preveri načrt in označi predpostavke.

Napaka 7. Nejasni pogoji v /goal.

Simptom: nastavite /goal naj bo videti lepo, pustite ga čez noč in se zbudite z 200 $ porabljenega limita. Rešitev: uporabite samo merljive pogoje z ukazom za preverjanje in obveznim »ali se ustavi po N potezah«. Brez »naj bo dobro« ali »dodelaj ga«.

Osma napaka, ki jo vibe coderji delajo najpogosteje, je zanemarjanje same zamisli mape plans/. Plan Mode brez mape plans/ ni metodologija, temveč igrača. Če uporabljate Plan Mode, vendar ne ustvarjate datotek, izkoristite 10 % njegovih zmožnosti.

Kaj storiti po prvi izkušnji s Plan Mode?#

Trije konkretni koraki, razvrščeni po naraščajoči zahtevnosti:

1. korak. Nastavite CLAUDE.md, če ga še nimate.

Brez CLAUDE.md Plan Mode deluje »v prazno« — Claude ne pozna pravil projekta in predlaga načrte, ki kršijo arhitekturo. Celoten vodnik: Kako nastaviti CLAUDE.md. Minimalna datoteka CLAUDE.md vsebuje 50-80 vrstic, ki opisujejo sklad, pravila in prepovedi. Dolžina je drugotnega pomena. Pomembna je konkretnost.

2. korak. V repozitoriju ustvarite mapo plans/.

V korensko mapo projekta dodajte mapo plans/. Dogovorite se o obliki imen: YYYY-MM-DD-feature-name.md. Vsak načrt dobi svojo datoteko. Po mesecu dni jih boste imeli 20-30, po pol leta 100+. To je živa zgodovina odločitev projekta.

3. korak. Preizkusite /goal na eni nalogi.

Izberite nalogo, ki jo običajno ročno opravljate 30-40 minut. Vklopite Plan Mode, pripravite načrt in ga shranite v plans/. Zapustite Plan Mode. Nastavite /goal dokončaj vse faze v plans/file.md, vsi testi morajo uspešno prestati izvajanje, sicer se ustavi po 30 potezah. Za eno uro zaprite prenosnik in se posvetite čemu drugemu. Nato se vrnite in preverite rezultat.

Ti trije koraki so minimum. To se gradi postopoma; ne poskušajte vsega sestaviti v enem večeru. Začnite s CLAUDE.md, čez teden dodajte plans/, čez mesec pa preizkusite /goal čez noč.

Ko boste pripravljeni, spoznajte Ailoot.