Plan Mode v Claude Code: průvodce krok za krokem a 4 fáze v roce 2026

Další pokyny najdete v dokumentaci Ailoot.

Co je Plan Mode v Claude Code a proč sám nestačí?#

V běžném režimu Claude Code píše kód okamžitě, a pokud změny nesledujete, můžete z ničeho nic dostat diff napříč mnoha soubory. Plan Mode obrací pořadí kroků: nejprve průzkum a plánování, potom schválení a nakonec změny.

Anthropic popisuje Plan Mode ve své oficiální dokumentaci takto:

Zní to jednoduše, ale skrývá se v tom zásadní změna. Plan Mode mění rytmus práce: nejprve se domluvit, potom jednat. Jde o změnu režimu, ne o kosmetickou úpravu. Pro vibe codery je problém v tom, že AI agenti mají tendenci spěchat. Když v běžném režimu požádáte: „Přidej přihlášení přes Google“, Claude napíše kód za minutu, ale polovina souborů bude špatná. V Plan Mode se stejná žádost změní na textový plán, který si můžete za dvě minuty přečíst a opravit, než se kdokoli dotkne kódu.

Tady je úskalí, o kterém se v mezinárodních průvodcích nepíše. Samotný Plan Mode je slabý nástroj: plán existuje jen v aktuální konverzaci. Zavřete okno a plán je pryč. Nemůžete ho předat jinému agentovi. Neexistují verze ani historie. Pokud je úkol velký (refaktoring modulu o 30 souborech, migrace na novou databázi), plán brzy narazí na limit kontextového okna a začne se zhoršovat.

Proto Plan Mode dobře funguje společně se složkou plans/ v repozitáři. Plán se uloží jako plans/2026-05-21-google-oauth.md, rozdělí se do fází s políčky k zaškrtnutí a může na něj navázat kterýkoli další agent. Tak funguje context engineering — správa kontextu před zadáním, nikoli během něj.

Jak zapnout Plan Mode v Claude Code?#

Nejrychlejší způsob během relace je klávesová zkratka:

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

Po dvou stisknutích se ve spodní části terminálu objeví indikátor ⏸ plan mode on. Třetí stisknutí vrátí běžný režim. Je to nejpohodlnější metoda — přepnete se do něj za běhu, když vidíte, že se úkol rozrůstá.

Druhý způsob je přidat předponu před jedno zadání:

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

Tato možnost se hodí, když používáte režim automatického přijímání a nechcete ho měnit pro celou relaci. Jedna žádost v Plan Mode, a pak práce pokračuje jako předtím.

Třetí způsob je při spuštění relace:

claude --permission-mode plan

Použijte ho, když předem víte, že úkol vyžaduje plánování. Například před rozsáhlým refaktoringem nebo migrací.

Čtvrtým způsobem je nastavit výchozí režim v souboru .claude/settings.json v projektu:

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

Kdy se to hodí? Když tým pracuje na složitém systému, kde může každá změna ovlivnit sousední moduly. Výchozí Plan Mode pak všechny chrání před náhodnými změnami.

Pátý trik se často přehlíží: Ctrl+G otevře plán v textovém editoru. Použijte ho, když je plán skoro správný, ale potřebujete přeformulovat 2–3 body nebo doplnit omezení. Upravte ho ručně, uložte a Claude bude pokračovat s vaší verzí.

Jaké jsou kanonické 4 fáze Plan Mode podle Anthropic: Explore, Plan, Implement, Commit?#

Mnoho průvodců popisuje 3 fáze (Explore-Plan-Execute) nebo jen 2 (Plan-Implement). To jsou zjednodušení. Ve svém oficiálním průvodci osvědčenými postupy Anthropic popisuje přesně 4 fáze. Na rozdílu záleží: samostatná fáze Commit vás vede k zaznamenání výsledku, místo abyste skončili u „ještě jsem udělal pár úprav, commitnu to později“ — což je nejčastější příčina ztracené práce.

Čím přesnější plán, tím méně iterací implementace vyžaduje. Když strávíte 10 minut plánem, implementaci zvládne jedno zadání. Když plán načrtnete za minutu, implementace zabere hodinu oprav.

Takto vypadají 4 fáze při přidávání Google OAuth (příklad z dokumentace Anthropic):

Zadání se v každé fázi také liší. Ve fázi Explore: „přečti /src/auth a zjisti, jak řešíme sessions a přihlášení“. Ve fázi Plan: „Chci přidat Google OAuth. Které soubory je třeba změnit? Vytvoř plán.“ Ve fázi Implement: „implementuj OAuth flow podle svého plánu, napiš testy, spusť sadu testů a oprav chyby“. Ve fázi Commit: „vytvoř commit s výstižnou zprávou a otevři PR“.

Důležitá nuance: Plan Mode nebrání Claudovi spouštět příkazy pro průzkum. Povoleny jsou Read, LS, Glob, Grep, web fetch a shellové příkazy pro průzkum. Zakázány jsou pouze Edit, Write a jakékoli operace se souborovým systémem, které něco mění. Claude tak může číst strukturu projektu, spustit git log a podívat se na testy, ale nemůže nic omylem změnit.

Jak číst Claudeův plán a rozhodnout, zda ho schválit?#

Když Claude dokončí tvorbu plánu, nabídne možnosti dalšího postupu:

• Schválit a spustit v automatickém režimu
• Schválit a přijímat úpravy
• Schválit a ručně kontrolovat každou úpravu
• Pokračovat v plánování se zpětnou vazbou
• Upřesnit pomocí Ultraplan (kontrola v prohlížeči)

Schopnost poznat, zda plán schválit, je v Plan Mode klíčová. Je snadné automaticky stisknout „Schválit“ a pak muset vracet commity. AI pochlebovač chce rychle odpovědět a vy se chcete rychle dostat ke kódu. Mýlíte se oba.

Dobrý plán splňuje 7 kritérií:

1. Konkrétní názvy souborů. Ne „aktualizuji auth“, ale „změním src/auth/login.ts:42-58, vytvořím src/auth/oauth-callback.ts a aktualizuji src/auth/session.ts:103.“
2. Je určené pořadí. Plán je rozdělen do fází nebo kroků, místo „nějak to všechno udělám“.
3. Jsou uvedené externí závislosti. Pokud úkol vyžaduje novou knihovnu, je uvedena. Totéž platí pro potřebné proměnné prostředí.
4. Jsou uvedena rizika. Dobrý plán říká: „Migrace může rozbít stávající sessions; je třeba ověřit X.“ Špatný o vedlejších účincích mlčí.
5. Jsou stanovena kritéria úspěchu. „Testy test/auth projdou, linter je čistý a vývojový server se spustí bez chyb.“
6. Nejsou v něm předpoklady „vytažené z klobouku“. Když Claude řekne „použiji knihovnu Z“, ověřte: nainstalovali jste ji vůbec do projektu? Pokud si ji AI vymyslela, zjistíte, že není uvedena v package.json.
7. Plán se vejde na obrazovku. Pokud má plán jednoduché funkce 200 řádků, je úkol nejspíš příliš velký pro jeden plán. Rozdělte ho na části.

Pokud plán kontrolou neprojde, máte tři možnosti:

• Pokračovat v plánování se zpětnou vazbou — napište Claudovi konkrétní připomínku k tomu, co se vám nelíbí, a on plán přepíše.
• Ctrl+G — otevřete plán v editoru, ručně ho upravte a uložte. Claude bude pokračovat s vaší verzí.
• Upřesnit pomocí Ultraplan — plán přejde do režimu prohlížeče Claude Code na webu, kde zkontrolujete jednotlivé části a přidáte komentáře, potom ho spustíte lokálně nebo v cloudu.

Když se něco pokazí uprostřed implementace, netlačte na pilu. Vraťte se do Plan Mode a přepište plán. Je to 10krát levnější než později vracet 40 commitů.

Plan Mode + složka plans/: kombinace pro dlouhý kontext#

Plan Mode je režim Claude Code. Složka plans/ je metodika postavená na něm. Pokud používáte Plan Mode bez složky, narazíte po hodině práce na limit.

Logika je následující. Kontextové okno Claudea je paměť relace. V Opus 4.7 se do něj vejde 1 million tokenů, ale to je objem celé vaší konverzace. Když v jedné konverzaci naplánujete složitý úkol, požádáte o implementaci, potom řešíte chybu a pak něco dalšího, okno se „nafoukne“. Claude začne zapomínat dřívější rozhodnutí, zaměňovat kontexty a znovu se ptát.

Řešením je zlaté pravidlo: jeden úkol — jedna konverzace.

Postupujte takto:

1. Konverzace 1 — vytvoření plánu. Zapněte Plan Mode, popište úkol a Claude vytvoří plán. Uložte ho jako plans/2026-05-21-feature-name.md. Zavřete okno.
2. Konverzace 2 — rozdělení do fází. Otevřete nový chat. Požádejte: „vezmi plans/2026-05-21-feature-name.md a rozděl ho do fází“. Aktualizovaný soubor uložte.
3. Konverzace 3 — implementace fáze 1. Otevřete nový chat. Požádejte: „implementuj fázi 1 z plans/2026-05-21-feature-name.md a po dokončení odškrtávej položky“. Zavřete okno.
4. Konverzace 4 — implementace fáze 2. Postupujte stejně.

Co vám to přinese? Kontextové okno každé konverzace zůstane čerstvé. Claude ve fázi 3 nezná podrobnosti fáze 1, ale zná plán, protože soubor plans/ je v repozitáři. Kterýkoli další agent (ať už subagent, nová relace nebo běh přes /goal) může navázat na plán a pokračovat.

Srovnání přístupů:

Každá funkce má vlastní soubor s plánem. Když si potřebujete po třech měsících připomenout, proč jste zvolili jednoho poskytovatele plateb místo jiného, můžete otevřít příslušný plán a přečíst si historii rozhodování: co se probíralo, které možnosti se zvažovaly a proč se zvolila právě tato cesta.

Jde o živé pracovní plány; statická dokumentace zastará během několika měsíců.

Jak nechat Claude pracovat, zatímco spíte, pomocí Plan Mode a /goal?#

Hlavním omezením dlouhých relací s AI není samotný model, ale člověk, který mačká Enter. Pokaždé, když Claude dokončí tah, čeká na vaši odpověď. /goal toto čekání odstraňuje.

Syntaxe je jednoduchá:

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

Podmínka může mít až 4000 znaků. Pro každou relaci lze nastavit jeden cíl. Po každém tahu se model Haiku mini podívá na přepis a rozhodne: „podmínka splněna — skončit“ nebo „nesplněna — další tah“. Vyhodnocovací model nepoužívá nástroje, pouze čte.

Příkazy pro jeho zrušení: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Kombinace s Plan Mode vypadá takto:

1. Zapněte Plan Mode (dvakrát stiskněte Shift+Tab).
2. Požádejte: „vytvoř plán migrace databáze z MySQL na Postgres a ulož ho do plans/2026-05-21-postgres-migration.md s fázemi a kritérii“.
3. Plán zkontrolujte, upravte a schvalte.
4. Ukončete Plan Mode (ještě jednou stiskněte Shift+Tab).
5. Nastavte cíl: „dokonči všechny fáze v plans/2026-05-21-postgres-migration.md, odškrtni políčka, všechny testy musí projít, nebo skonči po 50 tazích“.
6. Zavřete notebook a jděte spát.

Ráno zkontrolujte výsledek: buď „✓ cíl dokončen“, nebo „◎ zastaveno po 50 tazích“, včetně historie provedených kroků.

U /goal platí tři zásadní pravidla, jinak budete plýtvat tokeny:

Pravidlo 1: Měřitelný konečný stav. „Ať to vypadá hezky“ je špatně. „npm test vrátí 0, npm run lint vrátí 0 a do CHANGELOG.md bude přidána položka“ je správně.

Pravidlo 2: Výslovné ověření. Podmínka se má vztahovat k něčemu ověřitelnému: příkazu, souboru nebo endpointu. Ne „všechno funguje“, ale „curl localhost:3000/api/users vrací 200“.

Pravidlo 3: Omezte počet tahů. Vždy přidejte „or stop after N turns“. Anthropic to výslovně doporučuje v dokumentaci:

Pokud zapnete /goal bez omezení „or stop after“, může váš rozpočet přes noc zmizet.

Jaký 4krokový cyklus promění Plan Mode v inženýrský proces?#

Častou chybou je zeptat se „jak to mám opravit?“: Claude navrhne řešení, vy ho použijete, ale nic nefunguje nebo se situace zhorší. Tohle je „AI pochlebovač“: je vytrénovaný odpovídat rychle a vy se chcete rychleji dostat ke kódu. Řeší to 4krokový cyklus.

4krokový cyklus tomuto režimu brání. Používá se postupně během jedné relace v Plan Mode:

Krok 1. Zjistit fakta bez návrhu řešení.

Zadání: „Pozoruji následující: [popis příznaku]. Vaším úkolem je nyní zjistit fakta. Jakákoli řešení, nápady a rady jsou zakázány. Pouze: co pozoruji, které kroky lze zopakovat, jaká data jsou k dispozici a která chybí. Pevná podmínka zastavení: NENAVRHUJTE řešení; pouze zaznamenejte diagnózu.“

Tím se zablokuje první impuls AI: „tady je řešení“. Claude se musí zastavit u „co je známo a co neznámé“.

Krok 2. Vypracovat možnosti s oporou v příkladech.

Zadání: „Teď, když je diagnóza hotová, najděte na internetu příklady řešení podobných problémů. Alespoň 3 různé přístupy. U každého uveďte: odkaz na primární zdroj, stručný popis a výhody a nevýhody pro naši situaci.“

Tím se zablokuje druhý impuls AI: „vymyslet řešení z ničeho“. Přimějeme ji vyjít do světa a přinést přístupy, které lze ověřit.

Krok 3. Podrobný plán s riziky.

Zadání: „Vezměte nejlepší možnost z kroku 2 a sestavte podrobný plán: kterých konkrétních souborů se dotknout, co přidat, co odstranit, které testy napsat, co by se mohlo pokazit a jaká rizika hrozí za 2–3 kroky.“

Jde o známou fázi Plan, ale s jedním rozdílem: vychází z ověřených možností z kroku 2, ne z Claudeových odhadů.

Krok 4. Sebekontrola plánu.

Zadání: „Nyní povinně proveďte sebekontrolu. Poctivě plán znovu prověřte: jsou v něm místa, kde jste si něco vycucali z prstu a neověřili to vůči kódu, dokumentaci nebo příkladům z kroku 2? Pokud ano, označte je a plán upravte.“

To je závěrečný filtr. Claude musí zkontrolovat vlastní úvahy a přiznat, kde halucinoval. V této fázi se obvykle upraví alespoň 2 položky plánu.

Po dokončení 4 kroků je plán připravený ke schválení. K implementaci přistoupíte s jistotou, že úkolu rozumíte, zvážili jste možnosti a promysleli rizika.

Tato metodika je určena pro diagnostiku obtížných chyb a pro architektonická rozhodnutí, kde je cena omylu vysoká. Při použití v Plan Mode odstraňuje hlavní problém vibe coderů: „AI mi navrhla řešení, použil jsem ho a všechno se rozbilo.“

Kterých 5 hotových zadání funguje v Plan Mode pro běžné úkoly?#

Šablona 1. Refaktoring modulu.

Zapínám Plan Mode. Úkol: refaktorovat modul {module-name}.

Krok 1: Prozkoumej aktuální strukturu modulu {module-path}. Popiš:
- které soubory jsou součástí modulu
- jaké má externí závislosti
- které části se opakují
- které funkce jsou příliš složité

Krok 2: Najdi online 2-3 příklady refaktoringu podobných modulů.
Alespoň 1 zdroj musí být oficiální dokumentace Anthropic nebo souvisejícího frameworku.

Krok 3: Vytvoř plán refaktoringu v plans/YYYY-MM-DD-refactor-{module}.md:
- které soubory přejmenovat
- které funkce vyčlenit do samostatných modulů
- které testy ponechat a které přepsat
- rizika: co by se mohlo uživatelům pokazit

Krok 4: Sebekontrola. Jsou v plánu nějaké předpoklady „vytažené z klobouku“?
Přepiš je nebo odstraň.

Šablona 2. Migrace databáze.

Zapínám Plan Mode. Úkol: migrovat databázi z {old} na {new}.

Krok 1: Prozkoumej aktuální schéma databáze pomocí {schema-reading-command}. Popiš:
- které tabulky existují a jaká je jejich velikost
- jaké existují vztahy, indexy a omezení
- kde jsou uloženy migrace
- která data jsou kritická

Krok 2: Najdi příklady migrací {old → new} v produkčních projektech.
Alespoň 3 různé přístupy: pg_dump, dual-write, blue-green.
U každého uveď výhody a rizika pro naši velikost dat.

Krok 3: Vytvoř migrační plán v plans/YYYY-MM-DD-db-migration.md:
- fáze (záloha, migrace, ověření, přepnutí)
- kritéria úspěchu pro každou fázi
- plán návratu zpět, pokud se něco pokazí
- výpadek, nebo bez výpadku

Krok 4: Sebekontrola. Jsou všechny údaje podložené dokumentací?
Byly všechny kroky pomyslně ověřeny vůči vývojovému prostředí?

Šablona 3. Přidání nové funkce.

Zapínám Plan Mode. Úkol: přidat do projektu funkci {description}.

Krok 1: Prozkoumej, jak podobné funkce v projektu aktuálně fungují.
Podívej se konkrétně na:
- {file-1}
- {file-2}
- které architektonické vzory se používají
- které testy se píšou pro podobné funkce

Krok 2: Zjisti, jak je tato funkce implementována v open-source projektech
s podobnou architekturou. Alespoň 2 různé přístupy.

Krok 3: Vytvoř plán v plans/YYYY-MM-DD-feature-{name}.md:
- seznam nových souborů
- seznam změněných souborů s konkrétními řádky
- pořadí implementace
- které testy přidat
- jaké pravidlo přidat do CLAUDE.md pro budoucí relace

Krok 4: Sebekontrola. Odpovídá plán architektuře projektu?
Předpokládá knihovny, které ještě nejsou nainstalované?

Šablona 4. Psaní testů.

Zapínám Plan Mode. Úkol: pokrýt modul {name} testy.

Krok 1: Prozkoumej modul {path}. Urči:
- veřejné funkce a jejich signatury
- interní funkce, které NEBUDEME testovat (detaily implementace)
- hraniční případy: prázdný vstup, chyby, souběžný přístup

Krok 2: Najdi příklady testů pro podobnou třídu úkolů
v populárních open-source projektech používajících stejný framework.

Krok 3: Vytvoř plán testů v plans/YYYY-MM-DD-tests-{module}.md:
- pro každou veřejnou funkci seznam testů
- potřebné mocky
- které fixtures
- jaký přístup k ověření (styl assertion)

Krok 4: Sebekontrola. Ověřují všechny testy chování místo implementace?
Zahrnuje pokrytí i hraniční případy?

Šablona 5. Ladění složité chyby.

Zapínám Plan Mode. Úkol: zjistit příčinu chyby {symptom-description}.

Krok 1: ZJISTIT FAKTA. Řešení a nápady jsou zakázány. Pouze:
- co pozoruji (přesné znění chyby)
- opakovatelné kroky
- dostupná data (logy, traces, verze knihoven)
- chybějící data (co je třeba ještě shromáždit)

Krok 2: Najdi příklady této chyby.
Alespoň 3 zdroje: GitHub issues, dokumentace.
U každého uveď odkaz a stručné shrnutí řešení.

Krok 3: Vytvoř diagnostický plán v plans/YYYY-MM-DD-bug-{name}.md:
- které hypotézy ověřit (seřazené podle pravděpodobnosti)
- které příkazy/skripty spustit k ověření každé z nich
- očekávaný výsledek každé kontroly

Krok 4: Sebekontrola. Nejsou v plánu hypotézy „vycucané z prstu“?
Vycházejí všechny hypotézy z faktů z kroku 1?

Zkopírujte každou šablonu, nahraďte {parameters} vlastními hodnotami a vložte ji do Claude Code v Plan Mode. Výsledkem bude pracovní plán ve složce plans/, který schválíte a použijete při implementaci.

Plan Mode vs. běžný režim: který zvolit?#

Anthropic to ve své dokumentaci říká přímo:

Samostatný plán přeskočte jen při skutečně malé, pochopené a málo rizikové změně. Plánujte, když potřebujete zjistit přístup nebo koordinovat rizikové změny napříč komponentami. Znalost názvů souborů či shrnutí cíle jednou větou neodstraňuje rizika migrace, přihlášení a integrity dat.

Rozhodovací tabulka:

Před volbou režimu se ptejte, zda rozumíte postupu, vedlejším účinkům a ověřování. Přímo pracujte na malé místní změně s nízkým rizikem a zřejmou kontrolou. Při nejistotě, neznámém kódu, migraci, přihlášení či koordinaci komponent plánujte předem, i když umíte pojmenovat všech 3–5 souborů.

Jak spojit Plan Mode + CLAUDE.md + subagenty pro spolehlivou práci?#

CLAUDE.md je soubor, který Claude čte na začátku každé relace, včetně Plan Mode. Pokud CLAUDE.md říká „nikdy nevkládej data natvrdo; vždy je získávej z databáze“, plán nikdy nenavrhne natvrdo vložené hodnoty. Pokud takové pravidlo chybí, může plán navrhovat cokoli.

Kombinace funguje takto:

Vrstva 1. CLAUDE.md stanovuje pravidla.

Soubor uvádí technologický stack projektu, architektonické principy, zákazy („nepoužívej zastaralá API“) a požadavky („všechny e-maily procházejí sdílenou šablonou“). Podrobný průvodce: Jak nastavit CLAUDE.md.

Vrstva 2. Plan Mode uplatňuje pravidla na úkol.

Když zapnete Plan Mode a požádáte „přidej OAuth“, Claude si přečte CLAUDE.md, uvidí pravidla („ukládej tokeny do Redis, ne do databáze“) a hned je zohlední v plánu. Plán odpovídá architektuře projektu.

Vrstva 3. Subagenti rozdělují práci.

Pokud je plán rozdělen do fází, lze každou fázi přidělit samostatnému subagentovi. Každý subagent pracuje ve vlastním kontextovém okně, aniž by zahlcoval hlavní okno. Plán ve složce plans/ zůstává hlavním zdrojem pravdy: subagenti si ho přečtou, provedou svou fázi a aktualizují políčka k zaškrtnutí.

Kterých 7 chyb narušuje Plan Mode?#

Chyba 1. Plán existuje jen v chatu.

Příznak: napsali jste plán, zavřeli okno a potřebujete se k němu vrátit další den — ale nic tam není, kontext zmizel. Řešení: plán vždy ukládejte do plans/YYYY-MM-DD-feature-name.md v repozitáři. Chat je pracovní stůl, soubor je archiv.

Chyba 2. Všechny úkoly jsou v jednom chatu.

Příznak: v jedné relaci řešíte auth, pak migraci, potom návrh UI a nakonec chybu. Kontextové okno se „nafoukne“ a Claude zapomene dřívější věci. Řešení: jeden úkol — jedna konverzace. Dokončili jste plán? Zavřete okno. Začínáte s implementací? Otevřete nové.

Chyba 3. Jeden plán o 3000 řádcích bez fází.

Příznak: plán existuje, ale nemá políčka k zaškrtnutí ani členění. Nelze poznat, co je hotové a co ne. Delegace není možná. Řešení: každý plán rozdělte do 3-7 fází. Každá fáze je seznam políček s konkrétními kroky.

Chyba 4. Před plánem chybí hloubkový průzkum.

Příznak: Claude navrhuje řešení z ničeho, protože jste ho nepožádali o hledání příkladů. O týden později zjistíte, že open source už dávno nabízí lepší přístup. Řešení: krok 2 čtyřkrokového cyklu — požádejte Claudea, aby před vytvořením plánu našel online 2-3 příklady.

Chyba 5. AI pochlebovač navrhne řešení bez diagnózy.

Příznak: zeptáte se „jak opravím chybu X?“, Claude navrhne řešení, použijete ho a nic nefunguje nebo se situace zhorší. Řešení: vždy začněte slovy „zjisti fakta; řešení jsou zakázána“. K možnostem přejděte až po diagnóze.

Chyba 6. Vynechání sebekontroly.

Příznak: plán vypadá věrohodně, ale obsahuje 2-3 předpoklady „vytažené z klobouku“ (vymyšlenou knihovnu, neexistující API nebo nesprávnou verzi). Implementace na nich selže. Řešení: krok 4 čtyřkrokového cyklu — požádejte Claudea, aby plán poctivě znovu prověřil a označil předpoklady.

Chyba 7. Vágní podmínky v /goal.

Příznak: nastavíte /goal ať to vypadá hezky, necháte ho běžet přes noc a ráno zjistíte, že vyčerpal limit v hodnotě $200. Řešení: používejte pouze měřitelné podmínky s ověřovacím příkazem a povinným „or stop after N turns“. Žádné „ať je to dobré“ nebo „ještě to vylepši“.

Osmou chybou, kterou vibe codeři dělají nejčastěji, je ignorování samotné myšlenky složky plans/. Plan Mode bez složky plans/ není metodika, ale hračka. Pokud používáte Plan Mode, ale nevytváříte soubory, získáváte 10 % jeho možností.

Co dělat po první zkušenosti s Plan Mode?#

Tři konkrétní kroky seřazené podle náročnosti:

Krok 1. Nastavte CLAUDE.md, pokud ho ještě nemáte.

Bez CLAUDE.md funguje Plan Mode „ve vakuu“ — Claude nezná pravidla projektu a navrhuje plány, které narušují architekturu. Úplný průvodce: Jak nastavit CLAUDE.md. Minimální CLAUDE.md má 50-80 řádků popisujících stack, pravidla a zákazy. Délka je vedlejší. Rozhodující je konkrétnost.

Krok 2. Vytvořte v repozitáři složku plans/.

Přidejte složku plans/ do kořene projektu. Dohodněte se na formátu pojmenování: YYYY-MM-DD-feature-name.md. Každý plán bude mít vlastní soubor. Za měsíc budete mít 20-30 souborů, za šest měsíců 100+. To je živá historie rozhodnutí projektu.

Krok 3. Vyzkoušejte /goal na jednom úkolu.

Vyberte si úkol, který obvykle děláte ručně 30-40 minut. Zapněte Plan Mode, vytvořte plán a uložte ho do plans/. Ukončete Plan Mode. Nastavte /goal dokonči všechny fáze v plans/file.md, všechny testy projdou, nebo skonči po 30 tazích. Zavřete na hodinu notebook a dělejte něco jiného. Vraťte se a zkontrolujte výsledek.

Tyto tři kroky jsou minimum. Všechno se buduje postupně; nesnažte se dát vše dohromady za jeden večer. Začněte s CLAUDE.md, po týdnu přidejte plans/ a za měsíc vyzkoušejte /goal přes noc.

Až budete připraveni, seznamte se s Ailoot.