# Plan Mode v Claude Code: sprievodca krok za krokom a 4 fázy v roku 2026 > Plan Mode v Claude Code: čo to je, ako ho zapnúť pomocou Shift+Tab, 4 fázy Anthropic, hotové šablóny zadaní a príkaz /goal na autonómne nočné úlohy. Source: https://ailoot.ai/blog/sk/claude-code-plan-mode/ Canonical: https://ailoot.ai/blog/sk/claude-code-plan-mode/ Language: sk Publisher: Ailoot (https://ailoot.ai/) Translation: guide-197 Revision: sha256-15ac345ce668d8b9c55392f96151da3dc074061821c0187ae22a3c5dca30da70 Ďalšie pokyny nájdete v [dokumentácii Ailoot](https://ailoot.ai/docs/). ## Čo je Plan Mode a prečo sám osebe nestačí?
Kľúčové body Plan Mode v Claude Code je režim, v ktorom AI číta súbory, analyzuje kód a navrhuje plán zmien, ale nič nezapisuje, kým ho neschválite. Aktivuje sa dvojitým stlačením Shift+Tab alebo pomocou príznaku `--permission-mode plan`. Hodí sa pri neistom postupe, neznámom kóde alebo významnom riziku naprieč súbormi či prevádzkou. Jasná, málo riziková oprava preklepu zvyčajne nepotrebuje samostatné plánovanie.
V bežnom režime Claude Code píše kód okamžite, a ak nesledujete, čo robí, môžete nečakane dostať diff naprieč mnohými súbormi. Plan Mode obracia postup: najprv prieskum a plánovanie, potom schválenie a až potom zmeny. Anthropic opisuje Plan Mode v oficiálnej dokumentácii takto:

Plan mode hovorí Claudovi, aby preskúmal situáciu a navrhol zmeny bez toho, aby ich vykonal. Claude číta súbory, spúšťa shellové príkazy na prieskum a píše plán, ale váš kód neupravuje.

— Anthropic Docs, https://code.claude.com/docs/en/permission-modes
Znie to jednoducho, ale skrýva sa za tým zásadná zmena. Plan Mode mení rytmus práce: najprv sa dohodnúť, potom konať. Je to zmena režimu, nie kozmetická úprava. Problémom pre vibe coderov je, že AI agenti majú sklon ponáhľať sa. Ak zadáte „Pridaj autentifikáciu cez Google“, v bežnom režime Claude napíše kód za minútu, ale polovica súborov bude nesprávna. V Plan Mode sa rovnaká požiadavka zmení na textový plán, ktorý si môžete za dve minúty prečítať a opraviť ešte predtým, ako sa dotkne jediného riadka kódu. V medzinárodných návodoch sa nespomína jeden háčik. Samotný Plan Mode je slabý nástroj: plán existuje len v aktuálnej konverzácii. Zavrite okno a plán sa stratí. Nemôžete ho odovzdať inému agentovi. Neexistujú verzie ani história. Ak je úloha rozsiahla (refaktoring modulu s 30 súbormi, migrácia na novú databázu), plán rýchlo narazí na limit kontextového okna a začne sa zhoršovať. Preto Plan Mode dobre funguje spolu s priečinkom `plans/` v repozitári. Plán sa uloží ako `plans/2026-05-21-google-oauth.md`, rozdelí sa na fázy s políčkami na zaškrtnutie a každý ďalší agent môže pokračovať v práci. Takto funguje [kontextové inžinierstvo](https://ailoot.ai/blog/sk/context-engineering/)—správa kontextu pred zadaním, nie počas neho. ## Ako zapnúť Plan Mode v Claude Code?
Kľúčové body Existujú štyri oficiálne spôsoby, ako zapnúť Plan Mode. Počas relácie dvakrát stlačte Shift+Tab alebo pred zadaním vložte predponu `/plan`. Pri spustení použite príznak `claude --permission-mode plan`. Globálne nastavte pole `defaultMode` v `.claude/settings.json`. Aktívny režim signalizuje text `⏸ plan mode on` v spodnej časti terminálu.
Najrýchlejší spôsob počas relácie je použiť klávesnicu: ``` Shift+Tab # cyklicky prepína režimy: default → acceptEdits → plan ``` Po druhom stlačení sa v spodnej časti terminálu zobrazí indikátor `⏸ plan mode on`. Tretie stlačenie vás vráti do bežného režimu. Je to najpohodlnejší spôsob—režim zapnete za pochodu, keď vidíte, že sa úloha rozrastá. Druhý spôsob je pridať pred jednu požiadavku predponu: ``` /plan write a plan to migrate the database from MySQL to Postgres ``` Táto možnosť sa hodí, keď ste v režime automatického prijímania zmien a nechcete ho meniť pre celú reláciu. Jedna požiadavka v Plan Mode a potom práca pokračuje ako predtým. Tretí spôsob je pri spustení relácie: ```bash claude --permission-mode plan ``` Použite ho, keď vopred viete, že úloha si vyžaduje plánovanie. Napríklad pred veľkým refaktoringom alebo migráciou. Štvrtý spôsob je nastaviť predvolený režim projektu v `.claude/settings.json`: ```json { "permissions": { "defaultMode": "plan" } } ``` Kedy je to užitočné? Keď tím pracuje na zložitom systéme, kde každá zmena môže ovplyvniť susedné moduly. Predvolený Plan Mode potom všetkých chráni pred náhodnými zmenami. Často prehliadaný piaty trik: `Ctrl+G` otvorí plán v textovom editore. Použite ho, keď je plán takmer správny, ale potrebujete preformulovať 2-3 body alebo doplniť obmedzenie. Upravte ho ručne, uložte a Claude bude pokračovať podľa vašej verzie. ## Aké sú 4 kanonické fázy Anthropic v Plan Mode: Explore, Plan, Implement, Commit?
Kľúčové body Anthropic vo svojich osvedčených postupoch uvádza kanonický pracovný postup so štyrmi fázami: Explore (čítať súbory a preskúmať kontext), Plan (vytvoriť plán zmien bez úprav), Implement (prepnúť do bežného režimu a vykonať plán) a Commit (vytvoriť commit s výstižnou správou a PR). Každá fáza má vlastné obmedzenia nástrojov.
Mnohé návody opisujú 3 fázy (Explore-Plan-Execute) alebo len 2 (Plan-Implement). Ide o zjednodušenia. Vo svojom [oficiálnom návode na osvedčené postupy](https://www.anthropic.com/engineering/claude-code-best-practices) Anthropic opisuje presne 4 fázy. Rozdiel je dôležitý: samostatná fáza Commit vás núti zaznamenať výsledok, namiesto toho, aby práca zostala pri „ešte som tu urobil pár úprav, commit vytvorím neskôr“—čo je najčastejší dôvod straty práce. Čím presnejší plán, tým menej iterácií si vykonanie vyžiada. Ak plánovaniu venujete 10 minút, na vykonanie stačí jedno zadanie. Ak plán načrtnete za minútu, opravy zaberú hodinu. Takto vyzerajú 4 fázy pri pridávaní Google OAuth (príklad z Anthropic Docs): | Fáza | Čo robí Claude | Čo robíte vy | Režim | |----|----|----|----| | **Explore** | Číta `/src/auth` a zisťuje, ako sa pracuje so session a premennými prostredia | Určíte rozsah prieskumu | Plan Mode | | **Plan** | Vytvorí plán: ktoré súbory zmeniť, ktoré nové vytvoriť a aké sú riziká | Prečítate si plán, upravíte ho pomocou Ctrl+G a schválite | Plan Mode | | **Implement** | Postupuje podľa plánu, píše kód OAuth flow, testy a callback | Sledujete každú vykonávanú zmenu | Default alebo acceptEdits | | **Commit** | Vytvorí commit s opisom a otvorí Pull Request | Skontrolujete správu a prezriete PR | Default | V každej fáze sa líšia aj zadania. V Explore: „prečítaj /src/auth a zisti, ako spracúvame session a prihlasovanie“. V Plan: „Chcem pridať Google OAuth. Ktoré súbory treba zmeniť? Vytvor plán“. V Implement: „vykonaj OAuth flow podľa svojho plánu, napíš testy, spusti sadu testov a oprav zlyhania“. V Commit: „vytvor commit s výstižnou správou a otvor PR“. Dôležitá poznámka: Plan Mode Claudovi nezakazuje spúšťať príkazy na účely prieskumu. Povolené sú Read, LS, Glob, Grep, načítanie webových stránok a shellové príkazy na prieskum. Zakázané sú len Edit, Write a operácie meniace súborový systém. Claude tak môže čítať štruktúru projektu, spustiť `git log` a pozrieť si testy, ale nič náhodne nezmení. ## Ako čítať Claudeov plán a rozhodnúť sa, či ho schváliť?
Kľúčové body Dobrý plán od Clauda obsahuje zoznam konkrétnych súborov a zmien, ktoré treba vykonať, zoradený postup krokov, výslovne uvedené riziká a kritériá úspechu. Zlý plán používa všeobecné formulácie ako „aktualizujem autentifikačný modul“ bez podrobností. Pri rozhodovaní o schválení použite 7 znakov uvedených nižšie. Doplňte ho spätnou väzbou alebo ho upravte priamo pomocou Ctrl+G.
Keď Claude dokončí plán, zobrazí možnosti ďalšieho postupu: - Schváliť a spustiť v automatickom režime - Schváliť a povoliť úpravy - Schváliť a ručne skontrolovať každú úpravu - Pokračovať v plánovaní so spätnou väzbou - Spresniť pomocou Ultraplan (kontrola v prehliadači) Vedieť, či plán schváliť, je kľúčová zručnosť pri používaní Plan Mode. Je ľahké automaticky stlačiť „Schváliť“ a potom musieť vracať commity. Podlizujúca sa AI chce rýchlo odpovedať a vy sa chcete čo najskôr dostať ku kódu. Mýlite sa obaja. Dobrý plán spĺňa 7 kritérií: 1. **Konkrétne názvy súborov.** Nie „aktualizujem autentifikáciu“, ale „zmením `src/auth/login.ts:42-58`, vytvorím `src/auth/oauth-callback.ts` a aktualizujem `src/auth/session.ts:103`.“ 2. **Je určený postup.** Plán je rozdelený na fázy alebo kroky, nie na neurčité „nejako to celé urobím“. 3. **Sú uvedené externé závislosti.** Ak úloha vyžaduje novú knižnicu, je uvedená. Rovnako aj potrebné premenné prostredia. 4. **Sú uvedené riziká.** Dobrý plán hovorí: „Migrácia môže narušiť existujúce session; treba preveriť X.“ Zlý mlčí o vedľajších účinkoch. 5. **Sú stanovené kritériá úspechu.** „Testy v `test/auth` prejdú, linter nehlási chyby a vývojový server sa spustí bez chýb.“ 6. **Neobsahuje predpoklady vycucané z prsta.** Ak Claude povie „použijem knižnicu Z“, overte si: nainštalovali ste ju vôbec do projektu? Ak si ju AI vymyslela, zistíte, že nie je uvedená v `package.json`. 7. **Plán sa zmestí na obrazovku.** Ak má plán pre jednoduchú funkciu 200 riadkov, úloha je pravdepodobne príliš veľká na jeden plán. Rozdeľte ju na časti. Ak plán neprejde kontrolou, máte tri možnosti: - **Pokračovať v plánovaní so spätnou väzbou**—dajte Claudovi konkrétny komentár k tomu, čo sa vám nepáči, a on plán prepíše. - **Ctrl+G**—otvorte plán v editore, ručne ho upravte a uložte. Claude bude pokračovať podľa vašej verzie. - **Spresniť pomocou Ultraplan**—plán sa otvorí v režime prehliadača na webe Claude Code, kde môžete skontrolovať jednotlivé časti a komentovať ich, potom ho spustíte lokálne alebo v cloude. Ak sa počas vykonávania niečo pokazí, netlačte na pílu. Vráťte sa do Plan Mode a prepíšte plán. Je to 10-krát lacnejšie, ako neskôr vracať 40 commitov. ## Plan Mode + priečinok `plans/`: kombinácia pre dlhý kontext
Kľúčové body Samotný Plan Mode funguje len v aktuálnej konverzácii. Zavrite okno a plán zmizne. Priečinok `plans/YYYY-MM-DD-feature.md` v repozitári zmení plán na trvalý artefakt: súbor s fázami, políčkami na zaškrtnutie a stavmi, v ktorom môže pokračovať ktorýkoľvek ďalší agent. Ide o posun od „plánu v pamäti“ k „plánu v kóde“.
Plan Mode je režim Claude Code. Priečinok `plans/` je metodika postavená na ňom. Ak používate Plan Mode bez priečinka, po hodine práce narazíte na limit. Logika je takáto. Kontextové okno Clauda je pamäťou relácie. Do Opus 4.7 sa zmestí 1 milión tokenov, ale to je objem celej vašej konverzácie. Ak v jednej konverzácii naplánujete zložitú úlohu, potom požiadate Clauda o jej vykonanie, následne prediskutujete chybu a potom ešte niečo ďalšie, okno sa „nafúkne“. Claude začne zabúdať skoršie rozhodnutia, zamieňať si kontexty a znovu klásť otázky. Riešením je zlaté pravidlo: **jedna úloha—jedna konverzácia**. Postupujte takto: 1. **Konverzácia 1—vytvorte plán.** Zapnite Plan Mode, opíšte úlohu a Claude vytvorí plán. Uložte ho do `plans/2026-05-21-feature-name.md`. Zavrite okno. 2. **Konverzácia 2—rozdeľte ho na fázy.** Otvorte nový chat. Požiadajte: „vezmi `plans/2026-05-21-feature-name.md` a rozdeľ ho na fázy“. Uložte aktualizovaný súbor. 3. **Konverzácia 3—vykonajte fázu 1.** Otvorte nový chat. Požiadajte: „vykonaj fázu 1 z `plans/2026-05-21-feature-name.md` a po dokončení odškrtávaj položky“. Zavrite okno. 4. **Konverzácia 4—vykonajte fázu 2.** Postupujte rovnako. Čo tým získate? Kontextové okno každej konverzácie zostane čerstvé. Claude vo fáze 3 nepozná podrobnosti fázy 1, ale pozná plán, pretože súbor `plans/` je v repozitári. Ktorýkoľvek ďalší agent (či už subagent, nová relácia alebo spustenie cez `/goal`) môže prevziať plán a pokračovať. Porovnanie prístupov: | Vlastnosť | Iba Plan Mode | Plan Mode + priečinok `plans/` | |----|----|----| | Trvácnosť | Len v aktuálnom chate | Navždy v repozitári | | Odovzdanie inému agentovi | Nemožné | `cat plans/file.md` | | Verzie a história | Žiadne | Pomocou git diff | | Podpora subagentov | Len v aktuálnej relácii | Každá fáza → vlastný subagent | | Políčka na zaškrtnutie a stavy | Len text | Zaškrtávacie políčka Markdown `[ ]` / `[x]` | | Veľkosť plánu | Obmedzená oknom | Ľubovoľná | Každá funkcia má vlastný súbor s plánom. Keď si o tri mesiace potrebujete pripomenúť, prečo ste si vybrali jedného poskytovateľa platieb namiesto iného, môžete otvoriť príslušný plán a prečítať si históriu rozhodovania: o čom sa diskutovalo, ktoré možnosti sa zvažovali a prečo sa zvolil práve tento postup. Sú to priebežne aktualizované pracovné plány; statická dokumentácia zastaráva v priebehu niekoľkých mesiacov. ## Ako nechať Clauda pracovať, kým spíte, pomocou Plan Mode a /goal?
Kľúčové body `/goal` je autonómna slučka, o ktorej Anthropic hovorí už rok. Príkaz `/goal` sa objavil v Claude Code v2.1.139 (11. mája 2026). Nastaví podmienku dokončenia a Claude na nej pracuje bez ľudského zásahu, kým ju nesplní. Po každom ťahu malý evaluačný model skontroluje, či je podmienka splnená.
Hlavným obmedzením dlhých AI relácií nie je samotný model, ale človek, ktorý stláča Enter. Zakaždým, keď Claude dokončí ťah, čaká na vašu odpoveď. `/goal` toto čakanie odstraňuje. Syntax je jednoduchá: ```bash /goal all tests in test/auth pass and lint is clean, or stop after 20 turns ``` Podmienka môže mať až 4000 znakov. Na jednu reláciu pripadá jeden cieľ. Po každom ťahu Haiku mini-model prečíta prepis a rozhodne: „podmienka splnená—ukončiť“ alebo „nesplnená—ďalší ťah“. Evaluačný model nespúšťa nástroje; iba číta. Aliasy na zrušenie: `/goal stop`, `/goal off`, `/goal reset`, `/goal none`, `/goal cancel`. Kombinácia s Plan Mode vyzerá takto: 1. Zapnite Plan Mode (dvakrát stlačte `Shift+Tab`). 2. Požiadajte: „vytvor plán migrácie databázy z MySQL na Postgres, ulož ho do `plans/2026-05-21-postgres-migration.md` s fázami a kritériami“. 3. Skontrolujte plán, upravte ho a schváľte. 4. Ukončite Plan Mode (ešte raz stlačte `Shift+Tab`). 5. Nastavte cieľ: „dokonči všetky fázy v `plans/2026-05-21-postgres-migration.md`, odškrtávaj políčka, všetky testy musia prejsť, alebo sa zastav po 50 ťahoch“. 6. Zavrite notebook a choďte spať. Ráno skontrolujte výsledok: buď „✓ cieľ splnený“, alebo „◎ zastavené po 50 ťahoch“, spolu s históriou vykonanej práce. Pre `/goal` platia tri zásadné pravidlá; inak budete míňať tokeny: **Pravidlo 1: Merateľný konečný stav.** „Urob to tak, aby to vyzeralo dobre“ je zlé. „`npm test` vráti 0, `npm run lint` vráti 0 a do `CHANGELOG.md` bol pridaný záznam“ je dobré. **Pravidlo 2: Výslovné overenie.** Podmienka má odkazovať na niečo overiteľné: príkaz, súbor alebo koncový bod. Nie „všetko funguje“, ale „curl localhost:3000/api/users vráti 200“. **Pravidlo 3: Obmedzte počet ťahov.** Vždy pridajte „alebo sa zastav po N ťahoch“. Anthropic to výslovne odporúča v dokumentácii:

Ak chcete obmedziť dĺžku spustenia cieľa, pridajte do podmienky ustanovenie o počte ťahov alebo čase, napríklad „alebo sa zastav po 20 ťahoch“.

— Anthropic Docs, https://code.claude.com/docs/en/goal
Ak zapnete `/goal` bez limitu „alebo sa zastav po“, váš rozpočet sa môže minúť cez noc. ## Aký 4-krokový cyklus mení Plan Mode na inžiniersky proces?
Kľúčové body Jednoduchý Plan Mode bez štruktúry prináša priemerné výsledky. Dobrý pracovný postup má 4 kroky v jednom okne: zistiť fakty bez navrhovania riešenia, vytvoriť možnosti na základe precedensov z internetu, zostaviť podrobný plán s rizikami 2-3 kroky dopredu a vyžadovať, aby sa plán sám skontroloval na predpoklady „vycucané z prsta“. Tento postup brzdí podlizujúcu sa AI.
Častou chybou je opýtať sa „ako to opravím?“: Claude navrhne riešenie, vy ho použijete, no nič nefunguje alebo sa situácia zhorší. Toto je „podlizujúca sa AI“: je trénovaná tak, aby rýchlo odpovedala, a vy sa chcete čo najskôr dostať ku kódu. Rieši to 4-krokový cyklus. Tento 4-krokový cyklus takémuto správaniu predchádza. Používa sa postupne v rámci jednej relácie Plan Mode: **Krok 1. Zistite fakty bez navrhovania riešenia.** Zadanie: „Zažívam nasledujúce: \[opis príznaku\]. Teraz je vašou úlohou zistiť fakty. Akékoľvek riešenia, nápady a rady sú zakázané. Iba: čo pozorujem, aké kroky možno zopakovať, aké údaje sú k dispozícii a aké údaje chýbajú. Podmienka okamžitého zastavenia: NENAVRHUJTE riešenia; iba zaznamenajte diagnózu.“ Tým sa zablokuje prvý impulz AI: „tu je riešenie“. Claude sa musí zastaviť pri tom, „čo je známe a čo nie je známe“. **Krok 2. Vypracujte možnosti s precedensmi.** Zadanie: „Teraz, keď je diagnóza stanovená, nájdite online precedensy riešenia podobných problémov. Aspoň 3 rôzne prístupy. Pri každom: odkaz na primárny zdroj, stručný opis a výhody a nevýhody pre našu situáciu.“ Tým sa zablokuje druhý impulz AI: „vymyslieť riešenie z hlavy“. Prinútime ju vyjsť do sveta a priniesť späť prístupy, ktoré možno overiť. **Krok 3. Podrobný plán s rizikami.** Zadanie: „Vyberte najlepšiu možnosť z Kroku 2 a načrtnite podrobný plán: ktorých konkrétnych súborov sa dotknúť, čo pridať, čo odstrániť, ktoré testy napísať, čo sa môže pokaziť a aké riziká číhajú o 2 – 3 kroky ďalej.“ Je to známa fáza plánovania, no s jedným rozdielom: vychádza z overených možností z Kroku 2, nie z Claudeových odhadov. **Krok 4. Vykonajte samokontrolu plánu.** Zadanie: „Teraz vykonajte povinnú samokontrolu. Úprimne znovu skontrolujte svoj plán: sú v ňom miesta, kde ste si niečo vymysleli a neoverili to v kóde, dokumentácii alebo precedense z Kroku 2? Ak áno, označte ich a plán upravte.“ Toto je posledný filter. Claude musí skontrolovať vlastné uvažovanie a priznať, kde halucinoval. V tomto kroku sa zvyčajne upravia aspoň 2 položky plánu. Po 4 krokoch je plán pripravený na schválenie. Môžete prejsť k implementácii s istotou, že úloha je pochopená, možnosti zvážené a riziká posúdené. Táto metodika je určená na diagnostiku ťažko odhaliteľných chýb a prijímanie architektonických rozhodnutí, pri ktorých sú náklady na chybu vysoké. Keď sa uplatní v režime plánovania, odstraňuje hlavný problém vibe coderov: „AI mi dala riešenie, použil som ho a všetko sa pokazilo.“ ## Ktorých 5 pripravených zadaní funguje v režime plánovania pri bežných úlohách?
Kľúčový poznatok Pripravené zadania ušetria 10 – 15 minút na úlohu a zlepšujú kvalitu plánov. Existuje päť univerzálnych šablón na refaktorovanie modulu, migráciu databázy, pridanie novej funkcie, písanie testov a ladenie zložitej chyby. Každá je súčasťou 4-krokového cyklu a je prepojená s priečinkom `plans/`.
**Šablóna 1. Refaktorovanie modulu.** ``` Zapínam režim plánovania. Úloha: refaktorovať modul {module-name}. Krok 1: Preskúmaj aktuálnu štruktúru modulu {module-path}. Opíš: - ktoré súbory sú súčasťou modulu - aké externé závislosti má - ktoré časti sa duplikujú - ktoré funkcie sú zbytočne komplikované Krok 2: Nájdite online 2 – 3 príklady refaktorovania podobných modulov. Aspoň 1 zdroj musí byť oficiálna dokumentácia Anthropicu alebo súvisiaceho frameworku. Krok 3: Vytvorte plán refaktorovania v súbore plans/YYYY-MM-DD-refactor-{module}.md: - ktoré súbory premenovať - ktoré funkcie vyčleniť do samostatných modulov - ktoré testy ponechať a ktoré prepísať - riziká: čo sa môže používateľom pokaziť Krok 4: Samokontrola. Sú v pláne nejaké predpoklady „vycucané z prsta“? Prepíšte alebo odstráňte ich. ``` **Šablóna 2. Migrácia databázy.** ``` Zapínam režim plánovania. Úloha: migrovať databázu z {old} na {new}. Krok 1: Preskúmaj aktuálnu schému databázy pomocou {schema-reading-command}. Opíš: - ktoré tabuľky existujú a akú majú veľkosť - aké vzťahy, indexy a obmedzenia existujú - kde sú uložené migrácie - ktoré údaje sú kritické Krok 2: Nájdite precedensy migrácií {old → new} v produkčných projektoch. Aspoň 3 rôzne prístupy: pg_dump, dual-write, blue-green. Pri každom uveďte výhody a riziká vzhľadom na veľkosť našich údajov. Krok 3: Vytvorte plán migrácie v súbore plans/YYYY-MM-DD-db-migration.md: - fázy (zálohovanie, migrácia, overenie, prepnutie) - kritériá úspechu každej fázy - plán návratu späť, ak sa niečo pokazí - odstávka alebo bez odstávky Krok 4: Samokontrola. Sú všetky čísla podložené dokumentáciou? Boli všetky kroky v duchu overené vo vývojovom prostredí? ``` **Šablóna 3. Pridanie novej funkcie.** ``` Zapínam režim plánovania. Úloha: pridať do projektu funkciu {description}. Krok 1: Preskúmaj, ako podobné funkcie v projekte aktuálne fungujú. Pozri sa najmä na: - {file-1} - {file-2} - ktoré architektonické vzory sa používajú - aké testy sa píšu pre podobné funkcie Krok 2: Zisti, ako sa táto funkcia implementuje v open-source projektoch s podobnou architektúrou. Aspoň 2 rôzne prístupy. Krok 3: Vytvor plán v súbore plans/YYYY-MM-DD-feature-{name}.md: - zoznam nových súborov - zoznam zmenených súborov s konkrétnymi riadkami - postupnosť implementácie - ktoré testy treba pridať - čo pridať do súboru CLAUDE.md ako pravidlo pre budúce relácie Krok 4: Samokontrola. Riadí sa plán architektúrou projektu? Predpokladá knižnice, ktoré ešte nie sú nainštalované? ``` **Šablóna 4. Písanie testov.** ``` Zapínam režim plánovania. Úloha: pokryť modul {name} testami. Krok 1: Preskúmaj modul {path}. Identifikuj: - verejné funkcie a ich signatúry - interné funkcie, ktoré NEBUDEME testovať (implementačné detaily) - okrajové prípady: prázdny vstup, chyby, súbežný prístup Krok 2: Nájdite príklady testov pre podobnú triedu úloh v populárnych open-source projektoch používajúcich rovnaký framework. Krok 3: Vytvorte plán testov v súbore plans/YYYY-MM-DD-tests-{module}.md: - zoznam testov pre každú verejnú funkciu - ktoré mocky sú potrebné - ktoré fixtures - aký prístup k overovaniu použiť (štýl assertion) Krok 4: Samokontrola. Overujú všetky testy správanie, a nie implementáciu? Zahŕňa pokrytie okrajové prípady? ``` **Šablóna 5. Ladenie zložitej chyby.** ``` Zapínam režim plánovania. Úloha: pochopiť príčinu chyby {symptom-description}. Krok 1: ZISTIŤ FAKTY. Riešenia a nápady sú zakázané. Iba: - čo pozorujem (presné znenie chyby) - kroky na zopakovanie - aké údaje sú k dispozícii (logy, trasovania, verzie knižníc) - aké údaje chýbajú (čo treba dodatočne zozbierať) Krok 2: Nájdite precedensy tejto chyby. Aspoň 3 zdroje: problémy na GitHube, dokumentácia. Pri každom uveďte odkaz a stručné zhrnutie riešenia. Krok 3: Vytvorte diagnostický plán v súbore plans/YYYY-MM-DD-bug-{name}.md: - ktoré hypotézy overiť (zoradené podľa pravdepodobnosti) - ktoré príkazy/skripty spustiť na overenie každej z nich - očakávaný výsledok každej kontroly Krok 4: Samokontrola. Sú v pláne nejaké hypotézy „vycucané z prsta“? Sú všetky hypotézy naviazané na fakty z Kroku 1? ``` Skopírujte každú šablónu, nahraďte `{parameters}` vlastnými hodnotami a vložte ju do Claude Code v režime plánovania. Výsledkom je pracovný plán v priečinku `plans/`, ktorý schválite a použijete pri implementácii. ## Režim plánovania alebo bežný režim: ktorý si vybrať?
Kľúčový poznatok Plan Mode používajte pri neistom postupe, neznámom kóde, architektonických rozhodnutiach, migráciách a významných vedľajších účinkoch. Počet súborov je podnet na posúdenie závislostí, nie pevné pravidlo. Malý, pochopený a málo rizikový diff možno riešiť priamo; jednovetový opis sám nerobí autentifikáciu či migráciu bezpečnou.
Anthropic to vo svojej dokumentácii hovorí priamo: [Pokyny Anthropic](https://www.anthropic.com/engineering/claude-code-best-practices) odporúčajú zohľadniť réžiu plánovania. Pri jasnej malej zmene s nízkym rizikom možno pracovať priamo; samotné jednovetové pomenovanie cieľa však nenahrádza posúdenie vedľajších účinkov a potrebného overenia. Samostatný plán vynechajte iba pri skutočne malom, pochopenom a málo rizikovom diffe. Plánujte pri hľadaní postupu či koordinácii rizikových zmien naprieč komponentmi. Znalosť názvov súborov ani jednovetové zhrnutie cieľa neodstraňujú riziká migrácie, autentifikácie a integrity dát. Rozhodovacia tabuľka: | Úloha | Režim | Prečo | |----|----|----| | Preklep v README | Predvolený | Jeden súbor, jedna zmena, zrejmý rozdiel | | Premenovanie premennej v jednom súbore | Predvolený | Rozsah je jasný a odkazy sa dajú overiť; posúďte vedľajšie účinky | | Pridanie riadka logovania | Predvolený | Jednoriadková zmena, ktorá neovplyvní logiku | | Pridanie nového tlačidla na stránku | Predvolený | Ak ide o jedno tlačidlo a vidíte, kam patrí, plán netreba | | Refaktorovanie modulu | Režim plánovania | 5+ súborov, riziká vedľajších účinkov | | Migrácia databázy | Režim plánovania + `/goal` | Viackrokový proces; potrebný je plán návratu späť | | Pridanie overovania | Režim plánovania | Ovplyvňuje 10+ súborov; bezpečnosť je kritická | | Písanie testov pre modul | Režim plánovania | Treba určiť, čo testovať | | Ladenie nejasnej chyby | Režim plánovania + 4-krokový cyklus | Bez diagnózy riešenia minú cieľ | | Kompletná migrácia frameworku | Režim plánovania + `plans/` + `/goal` cez noc | Dlhá úloha, ktorá potrebuje fázy a autonómny cyklus | Pred výberom režimu si overte pochopenie postupu, vedľajších účinkov a kontroly. Priamo riešte malú lokálnu zmenu s nízkym rizikom a jasnou skúškou. Najprv plánujte pri neistote, neznámom kóde, migrácii, autentifikácii či koordinácii komponentov, aj keď už poznáte všetkých 3 – 5 dotknutých súborov. ## Ako skombinovať režim plánovania + CLAUDE.md + subagentov na spoľahlivú prácu?
Kľúčový poznatok Režim plánovania je 10-krát účinnejší v kombinácii so správne nastaveným súborom [CLAUDE.md](https://ailoot.ai/blog/sk/claude-md-template/) a [subagentmi](https://ailoot.ai/blog/sk/claude-code-subagents/). CLAUDE.md stanovuje pravidlá, podľa ktorých Claude zostavuje plán. Subagenti umožňujú rozdeliť fázy plánu medzi paralelných agentov. Bez tejto kombinácie zostáva režim plánovania jednorazovým nástrojom.
CLAUDE.md je súbor, ktorý Claude číta na začiatku každej relácie vrátane režimu plánovania. Ak súbor CLAUDE.md hovorí „nikdy nezapisujte dátumy natvrdo; vždy ich získajte z databázy“, plán nikdy nenavrhne pevne zakódované dátumy. Ak také pravidlo chýba, plán môže navrhnúť čokoľvek. Táto kombinácia funguje takto: **Vrstva 1. CLAUDE.md stanovuje pravidlá.** Súbor určuje technologický stack projektu, architektonické princípy, zákazy („nepoužívajte zastarané API“) a požiadavky („všetky e-maily prechádzajú cez zdieľanú šablónu“). Podrobný návod: [Ako nastaviť CLAUDE.md](https://ailoot.ai/blog/sk/claude-md-template/). **Vrstva 2. Režim plánovania uplatňuje pravidlá na úlohu.** Keď zapnete režim plánovania a požiadate „pridaj OAuth“, Claude si prečíta CLAUDE.md, uvidí pravidlá („ukladaj tokeny do Redis, nie do databázy“) a hneď ich zohľadní v pláne. Plán bude v súlade s architektúrou projektu. **Vrstva 3. Subagenti rozdeľujú prácu.** Ak je plán rozdelený na fázy, každú fázu možno prideliť samostatnému [subagentovi](https://ailoot.ai/blog/sk/claude-code-subagents/). Každý subagent pracuje vo vlastnom kontextovom okne bez zahltenia hlavného okna. Plán v `plans/` zostáva ústredným zdrojom pravdy: subagenti ho čítajú, vykonávajú svoju fázu a aktualizujú zaškrtávacie políčka. ## Ktorých 7 chýb narúša režim plánovania?
Kľúčový poznatok Režim plánovania často zlyháva pre bežné chyby pri používaní, nie preto, že je nástroj slabý. Sedem hlavných chýb: ponechať plán v pamäti namiesto súboru, riešiť všetky úlohy v jednom chate, vytvoriť plán bez fáz, vynechať dôkladný prieskum, nechať AI pochlebovača ponúknuť riešenie bez diagnózy, vynechať samokontrolu a použiť nejasné podmienky v príkaze `/goal`.
**Chyba 1. Plán existuje iba v chate.** Príznak: napísali ste plán, zavreli okno a na druhý deň sa k nemu chcete vrátiť, no nič tam nie je; kontext je preč. Riešenie: vždy uložte plán do súboru `plans/YYYY-MM-DD-feature-name.md` v repozitári. Chat je pracovný stôl; súbor je archív. **Chyba 2. Všetky úlohy sú v jednom chate.** Príznak: v jednej relácii najprv rozoberáte overovanie, potom migráciu, následne návrh používateľského rozhrania a potom chybu. Kontextové okno sa „nafúkne“ a Claude zabudne predchádzajúce veci. Riešenie: jedna úloha – jedna konverzácia. Dokončili ste plán? Zatvorte okno. Začínate implementáciu? Otvorte nové. **Chyba 3. Jeden 3000-riadkový plán bez fáz.** Príznak: plán existuje, ale nemá zaškrtávacie políčka ani členenie. Nedá sa zistiť, čo je hotové a čo nie. Delegovanie je nemožné. Riešenie: rozdeľte každý plán na 3 – 7 fáz. Každá fáza je zoznam zaškrtávacích políčok s konkrétnymi činnosťami. **Chyba 4. Pred plánom neprebehol dôkladný prieskum.** Príznak: Claude navrhne riešenie z hlavy, pretože ste ho nepožiadali, aby vyhľadal precedensy. O týždeň zistíte, že open source už dávno ponúka lepší prístup. Riešenie: Krok 2 štvor-krokového cyklu – nechajte Claudea vyhľadať online 2 – 3 precedensy pred vytvorením plánu. **Chyba 5. AI pochlebovač ponúkne riešenie bez diagnózy.** Príznak: spýtate sa „ako opravím chybu X?“, Claude ponúkne riešenie, použijete ho a nič nefunguje alebo sa situácia zhorší. Riešenie: vždy začnite vetou „zistite fakty; riešenia sú zakázané“. K možnostiam prejdite až po diagnóze. **Chyba 6. Vynechanie samokontroly.** Príznak: plán vyzerá vierohodne, ale obsahuje 2 – 3 predpoklady „vycucané z prsta“ (vymyslenú knižnicu, neexistujúce API alebo nesprávnu verziu). Implementácia na týchto miestach zlyhá. Riešenie: Krok 4 štvor-krokového cyklu – požiadajte Claudea, aby úprimne znovu skontroloval plán a označil predpoklady. **Chyba 7. Nejasné podmienky v príkaze `/goal`.** Príznak: zadáte `/goal nech to vyzerá pekne`, necháte ho cez noc a ráno zistíte, že sa minulo 200 $ kvóty. Riešenie: používajte iba merateľné podmienky s príkazom na overenie a povinným „alebo zastav po N ťahoch“. Žiadne „urob to dobre“ ani „vylešti to“. Ôsma chyba, ktorú vibe coderi robia najčastejšie, je ignorovanie samotnej koncepcie priečinka `plans/`. Režim plánovania bez priečinka `plans/` nie je metodika; je to hračka. Ak používate režim plánovania, ale nevytvárate súbory, využívate 10 % jeho možností. ## Čo by ste mali urobiť po prvej skúsenosti s režimom plánovania?
Kľúčový poznatok Prvá skúsenosť s režimom plánovania je východiskom. Ďalšie kroky: nastavte [CLAUDE.md](https://ailoot.ai/blog/sk/claude-md-template/), ak ho ešte nemáte (bez neho plán visí vo vzduchu), v repozitári vytvorte priečinok `plans/` ako pracovnú metodiku a pred spaním vyskúšajte príkaz `/goal` na jednej autonómnej úlohe. Kombinácia všetkých troch – režimu plánovania, CLAUDE.md a `plans/` – tvorí funkčný systém.
Tri konkrétne kroky zoradené podľa náročnosti: **Krok 1. Nastavte CLAUDE.md, ak ho ešte nemáte.** Bez CLAUDE.md funguje režim plánovania „vo vákuu“ – Claude nepozná pravidlá projektu a navrhuje plány, ktoré narúšajú architektúru. Úplný návod: [Ako nastaviť CLAUDE.md](https://ailoot.ai/blog/sk/claude-md-template/). Minimálny CLAUDE.md má 50 – 80 riadkov, ktoré opisujú stack, pravidlá a zákazy. Dĺžka je druhoradá. Dôležitá je konkrétnosť. **Krok 2. Vytvorte v repozitári priečinok `plans/`.** Pridajte priečinok `plans/` do koreňového priečinka projektu. Dohodnite si formát názvov: `YYYY-MM-DD-feature-name.md`. Každý plán má vlastný súbor. Po mesiaci budete mať 20 – 30 súborov; po šiestich mesiacoch ich bude 100+. To je živá história rozhodnutí projektu. **Krok 3. Vyskúšajte `/goal` na jednej úlohe.** Vyberte úlohu, ktorú zvyčajne robíte ručne 30 – 40 minút. Zapnite režim plánovania, vytvorte plán a uložte ho do `plans/`. Ukončite režim plánovania. Zadajte `/goal dokonči všetky fázy v plans/file.md, všetky testy musia prejsť, alebo sa zastav po 30 ťahoch`. Na hodinu zatvorte notebook a venujte sa niečomu inému. Vráťte sa a skontrolujte výsledok. To sú tri základné kroky. Všetko sa buduje postupne; nesnažte sa to celé poskladať za jeden večer. Začnite s CLAUDE.md, po týždni pridajte `plans/` a po mesiaci vyskúšajte príkaz `/goal` cez 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)
Keď budete pripravení, zoznámte sa s [Ailoot](https://ailoot.ai/). ## Otázky a odpovede: Plan Mode v Claude Code: sprievodca krok za krokom a 4 fázy v roku 2026 ### Môžem vynechať plán iba preto, že viem, ktoré súbory sa zmenia? Nie. Známe názvy neodstraňujú neistotu vedľajších účinkov či overenia. Migrácie, autentifikáciu a koordinované zmeny komponentov plánujte aj pri známom zozname súborov. ### Kedy samostatná fáza Plan Mode nie je potrebná? Pri malom pochopenom diffe s nízkym rizikom a zrejmou kontrolou, napríklad lokálnom preklepe, je priama práca rozumná. Plánujte pri nejasnom postupe, neznámom kóde a potrebe premyslieť prevádzkové riziká či závislosti súborov. ## Ailoot · Spoločnosť a jej portfólio projektov Ailoot stavia na dlhodobých prevádzkových skúsenostiach, širokej klientskej základni, stabilných službách a priebežnom sledovaní KPI. Spoločnosť a jej portfólio projektov: milióny zákazníkov; mesačné tržby v miliardách. Ailoot využíva tieto prevádzkové skúsenosti na poskytovanie prístupu cez API k funkciám AI v produktoch zákazníkov, agentoch, aplikáciách a automatizáciách.