# Plan Mode v Claude Code: průvodce krok za krokem a 4 fáze v roce 2026 > Plan Mode v Claude Code: co to je, jak jej aktivovat pomocí Shift+Tab, 4 fáze Anthropic, hotové šablony zadání a příkaz /goal pro autonomní úkoly přes noc. Source: https://ailoot.ai/blog/cs/claude-code-plan-mode/ Canonical: https://ailoot.ai/blog/cs/claude-code-plan-mode/ Language: cs Publisher: Ailoot (https://ailoot.ai/) Translation: guide-197 Revision: sha256-c0989fd33e1e97491d39e36b5074c13c37a16a8aaa7c4efd3f6f14276eb16340 Další pokyny najdete v [dokumentaci Ailoot](https://ailoot.ai/docs/). ## Co je Plan Mode v Claude Code a proč sám nestačí?
Hlavní body Plan Mode v Claude Code je režim, ve kterém AI čte soubory, analyzuje kód a navrhuje plán změn, ale nic nezapisuje, dokud ho neschválíte. Aktivujete ho dvojím stisknutím Shift+Tab nebo pomocí příznaku `--permission-mode plan`. Hodí se při nejistém postupu, neznámém kódu nebo významném riziku napříč soubory či provozem. Jasná oprava překlepu s malým rizikem obvykle samostatné plánování nepotřebuje.
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:

Režim plan říká Claudovi, aby prozkoumal situaci a navrhl změny, aniž by je provedl. Claude čte soubory, spouští shellové příkazy k průzkumu a píše plán, ale neupravuje váš kód.

— Anthropic Docs, https://code.claude.com/docs/en/permission-modes
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](https://ailoot.ai/blog/cs/context-engineering/) — správa kontextu před zadáním, nikoli během něj. ## Jak zapnout Plan Mode v Claude Code?
Hlavní body Existují čtyři oficiální způsoby, jak zapnout Plan Mode. Během relace stiskněte dvakrát Shift+Tab nebo před zadání napište předponu `/plan`. Při spuštění použijte příznak `claude --permission-mode plan`. Globálně nastavte pole `defaultMode` v `.claude/settings.json`. Indikátor aktivního režimu je `⏸ plan mode on` ve spodní části terminálu.
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: ```bash 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: ```json { "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?
Hlavní body Anthropic ve svých osvědčených postupech uvádí kanonický pracovní postup se čtyřmi fázemi: Explore (čtení souborů a průzkum kontextu), Plan (vytvoření plánu změn bez úprav), Implement (přepnutí do běžného režimu a provedení plánu) a Commit (vytvoření commitu s výstižnou zprávou a PR). Každá fáze má vlastní omezení nástrojů.
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](https://www.anthropic.com/engineering/claude-code-best-practices) 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): | Fáze | Co dělá Claude | Co děláte vy | Režim | |----|----|----|----| | **Explore** | Čte `/src/auth` a zjišťuje, jak se pracuje se sessions a proměnnými prostředí | Určíte rozsah průzkumu | Plan Mode | | **Plan** | Vytvoří plán: které soubory změnit, které nové vytvořit a jaká jsou rizika | Přečtete si plán, upravíte ho pomocí Ctrl+G a schválíte ho | Plan Mode | | **Implement** | Postupuje podle plánu, píše kód OAuth flow, testy a callback | Sledujete každou prováděnou změnu | Default nebo acceptEdits | | **Commit** | Vytvoří commit s popisem a otevře Pull Request | Zkontrolujete zprávu a projdete PR | Default | 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?
Hlavní body Dobrý Claudeův plán obsahuje seznam konkrétních souborů a změn, které je třeba provést, seřazený sled kroků, výslovně uvedená rizika a kritéria úspěchu. Špatný plán používá obecné fráze jako „aktualizuji modul auth“ bez podrobností. O schválení rozhodněte podle 7 níže uvedených znaků. Upravte ho zpětnou vazbou nebo přímo pomocí Ctrl+G.
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
Hlavní body Samotný Plan Mode funguje jen v aktuální konverzaci. Zavřete okno a plán zmizí. Složka `plans/YYYY-MM-DD-feature.md` v repozitáři promění plán v trvalý artefakt: soubor s fázemi, políčky k zaškrtnutí a stavy, na který může navázat kterýkoli další agent. Jde o posun od „plánu v paměti“ k „plánu v kódu“.
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ů: | Funkce | Pouze Plan Mode | Plan Mode + složka `plans/` | |----|----|----| | Trvalost | Jen v aktuálním chatu | V repozitáři navždy | | Předání jinému agentovi | Nemožné | `cat plans/file.md` | | Verze a historie | Žádné | Pomocí git diff | | Podpora subagentů | Jen v aktuální relaci | Každá fáze → vlastní subagent | | Políčka k zaškrtnutí a stavy | Jen text | Markdown checkbox `[ ]` / `[x]` | | Velikost plánu | Omezená oknem | Libovolná | 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í body `/goal` je autonomní smyčka, o které Anthropic mluví už rok. Příkaz `/goal` se objevil v Claude Code v2.1.139 (11. května 2026). Nastaví podmínku dokončení a Claude na ní pracuje bez lidského zásahu, dokud ji nesplní. Po každém tahu malý vyhodnocovací model kontroluje, zda byla podmínka splněna.
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á: ```bash /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:

Chcete-li omezit délku běhu cíle, přidejte do podmínky omezení počtu tahů nebo času, například „nebo skonči po 20 tazích“.

— Anthropic Docs, https://code.claude.com/docs/en/goal
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?
Hlavní body Jednoduchý Plan Mode bez struktury přináší průměrné výsledky. Silný pracovní postup má 4 kroky v jednom okně: zjistit fakta bez návrhu řešení, vypracovat možnosti s oporou v příkladech z internetu, vytvořit podrobný plán s riziky 2–3 kroky dopředu a vyžadovat sebekontrolu plánu kvůli předpokladům „vytaženým z klobouku“. Tato posloupnost brání AI v pochlebování.
Č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?
Hlavní body Hotová zadání ušetří 10-15 minut na úkol a zlepší kvalitu plánu. Existuje pět univerzálních šablon pro refaktoring modulu, migraci databáze, přidání nové funkce, psaní testů a ladění složité chyby. Každá využívá 4krokový cyklus a je propojená se složkou `plans/`.
**Š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?
Hlavní body Plan Mode použijte při nejistém postupu, neznámém kódu, architektonických rozhodnutích, migracích či významných vedlejších účincích. Počet souborů je podnět ke kontrole závislostí, ne tvrdé pravidlo. Malou, pochopenou a málo rizikovou změnu lze řešit přímo; jednovětý popis sám nečiní přihlášení či migraci bezpečnou.
Anthropic to ve své dokumentaci říká přímo:

Režim plan je užitečný, ale přináší režii. U úkolů s jasným rozsahem a malou změnou (překlep, řádek logu, přejmenování proměnné) požádejte Claudea, aby ji provedl rovnou. Plánování se hodí hlavně tehdy, když si nejste jistí postupem, změna se týká více souborů nebo kód neznáte. Pokud dokážete diff popsat jednou větou, plán přeskočte.

— Anthropic Docs, https://www.anthropic.com/engineering/claude-code-best-practices
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: | Úkol | Režim | Proč | |----|----|----| | Překlep v README | Default | Jeden soubor, jedna změna, zřejmý diff | | Přejmenování proměnné v jednom souboru | Default | Rozsah je jasný a reference lze ověřit; posuďte vedlejší účinky | | Přidání řádku logování | Default | Jednořádková změna, která neovlivní logiku | | Přidání nového tlačítka na stránku | Default | Pokud jde o jedno tlačítko a víte, kam patří, plán není potřeba | | Refaktoring modulu | Plan Mode | 5+ souborů, rizika vedlejších účinků | | Migrace databáze | Plan Mode + `/goal` | Vícekrokový proces, je potřeba plán návratu zpět | | Přidání ověřování | Plan Mode | Ovlivňuje 10+ souborů; bezpečnost je zásadní | | Psaní testů pro modul | Plan Mode | Je třeba určit, co testovat | | Ladění nejasné chyby | Plan Mode + 4krokový cyklus | Bez diagnózy řešení minou cíl | | Migrace celého frameworku | Plan Mode + `plans/` + `/goal` přes noc | Dlouhý úkol, který vyžaduje fáze a autonomní smyčku | 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?
Hlavní body Plan Mode je 10krát účinnější v kombinaci se správně nastaveným souborem [CLAUDE.md](https://ailoot.ai/blog/cs/claude-md-template/) a [subagenty](https://ailoot.ai/blog/cs/claude-code-subagents/). CLAUDE.md stanovuje pravidla, podle kterých Claude vytváří plán. Subagenti umožňují rozdělit fáze plánu mezi paralelní agenty. Bez této kombinace zůstává Plan Mode jednorázovým nástrojem.
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](https://ailoot.ai/blog/cs/claude-md-template/). **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](https://ailoot.ai/blog/cs/claude-code-subagents/). 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?
Hlavní body Plan Mode často selhává kvůli běžným chybám při používání, ne proto, že by byl nástroj slabý. Sedm hlavních chyb: ponechání plánu v paměti místo v souboru, řešení všech úkolů v jednom chatu, tvorba plánu bez fází, vynechání hloubkového průzkumu, dovolení AI pochlebovači navrhnout řešení bez diagnózy, vynechání sebekontroly a používání vágních podmínek v `/goal`.
**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?
Hlavní body První zkušenost s Plan Mode je začátek. Další kroky: nastavte [CLAUDE.md](https://ailoot.ai/blog/cs/claude-md-template/), pokud ho ještě nemáte (bez něj visí plán ve vzduchu), vytvořte v repozitáři složku `plans/` jako pracovní metodiku a před spaním vyzkoušejte `/goal` na jednom autonomním úkolu. Spojení všech tří — Plan Mode, CLAUDE.md a `plans/` — tvoří funkční systém.
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](https://ailoot.ai/blog/cs/claude-md-template/). 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.
### Zdroje - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Anthropic Docs - Common Workflows](https://code.claude.com/docs/en/common-workflows) - [Anthropic Engineering - Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) - [Anthropic Docs - /goal command](https://code.claude.com/docs/en/goal) - [Anthropic Docs - Changelog](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)
Až budete připraveni, seznamte se s [Ailoot](https://ailoot.ai/). ## Časté otázky ### Mohu plán přeskočit, když vím, které soubory se změní? Ne. Známé názvy souborů neodstraňují nejistotu vedlejších účinků ani ověřování. Migrace, přihlášení a koordinované změny komponent plánujte i s jasným seznamem souborů. ### Kdy není potřeba samostatný Plan Mode? U malé, pochopené a málo rizikové změny se zřejmou kontrolou, například místního překlepu, je přímá práce rozumná. Plánujte při nejistém přístupu, neznámém kódu či provozních a mezisouborových rizicích. ## Ailoot · Společnost a její portfolio projektů Ailoot staví na dlouhodobých provozních zkušenostech, široké klientské základně, stabilních službách a průběžném sledování KPI. Společnost a její portfolio projektů: miliony zákazníků; měsíční tržby v miliardách. Ailoot využívá tyto provozní zkušenosti k poskytování přístupu přes API k funkcím AI v produktech zákazníků, agentech, aplikacích a automatizacích.