Breakdown

Co skill dělá

Vezme schválené zadání a rozpadne ho na docs/plan.md – seřazený seznam úkolů, kde každý má konkrétní soubory, kód testu, příkaz na spuštění a commit. Plán je psaný pro někoho, kdo projekt vůbec nezná.

V Životním cyklu projektu (~/.claude/standards/rules.md) je to pátý krok osy: navazuje na /architect a předává na /implement.

Co skill nedělá

• Neimplementuje. Ani první úkol „na ukázku“. Implementaci dělá /implement.
• Nepíše zadání. Když chybí, pošle tě na /specify.
• Neoponuje zadání. Jestli dává smysl, je otázka pro /oponent, ne pro rozpad. Tady se bere jako platné a rozpad se dělá proti němu, ne proti vlastnímu názoru na něj.
• Neřeže rozsah sám. Co je v MVP, rozhodl /specify. Tady se to jen respektuje.

Jak je to postavené uvnitř

Skill dnes řídí superpowers:writing-plans a jména souborů v plánu prověří skript denied.py v adresáři skillu. Obojí je implementační detail, ne rozhraní – může se kdykoliv změnit za jiný nástroj nebo za vlastní postup, aniž se změní, jak se skill volá a co z něj leze. Volající se o vnitřek nestará.

Co je naopak závazné a nesmí se změnit tiše:

• vstup je schválené zadání v docs/,
• výstup je docs/plan.md,
• plán pokrývá jen MVP,
• po dokončení se nepokračuje do implementace automaticky.

Fáze 0 – Příprava

Společný začátek drží ~/.claude/skills/preflight.md – načti si ho a řiď se jím. Body 4 a 5 odpadají: tenhle skill nesahá na kód, takže nemá co ověřovat před startem, a pracuje nad zadáním, ne nad diffem větve.

Navíc si ověř tohle:

1. Co je v kontraktu příkazů. Plán z něj bere příkazy na ověření; chybí-li a projekt má kód, ohlas to – úkoly by pak neměly co napsat do kroku ověření.

2. Najdi zadání. V tomhle pořadí:

   Co existuje	Co je zadání pro plán
   docs/architecture.md	architecture.md jako spec, docs/requirements.md jako doplňkový kontext
   jen docs/requirements.md a projekt má kód, který se teprve navrhuje	Zastav se. Nabídni /architect – návrh řešení se nepřeskočil, jen ještě nevznikl.
   jen docs/requirements.md	requirements.md – návrh řešení byl vědomě přeskočen, což je legitimní
   ani jedno	Zastav se. Nabídni /specify a skonči. Plán bez zadání je jen seznam dohadů.

   Má-li docs/todo.md neprázdnou sekci ## Kola návrhu, nebo chybí-li v docs/done.md za posledními záznamy kol řádek Návrh uzavřen, zastav se bez ohledu na tabulku: návrh běží po kolech a zadání je zatím poloviční. Nabídni /architect, který kola vede i sešívá, a skonči.

3. Ověř, že je zadání schválené. Není-li jasné, že jím uživatel prošel, zeptej se. Plán postavený na neschváleném zadání se zahazuje celý.

4. Existuje už docs/plan.md? Nepřepisuj ho:

   Stav	Co dělat
   Plán je hotový a všechny úkoly odškrtnuté	Jde o další fázi. Přidej úkoly, hotové nech být jako historii.
   Plán je rozpracovaný	Zeptej se: dopsat chybějící část, nebo přepracovat? Rozpracovaný plán obsahuje odškrtnuté úkoly, které už jsou v kódu – přepsat je znamená rozejít plán se skutečností.
   Plán je zastaralý oproti zadání	Vypiš, co se v zadání změnilo, a uprav jen dotčené nehotové úkoly.

Fáze 1 – Rozsah plánu

Jen MVP. Zadání popisuje celou věc, plán jen první verzi – viz ~/.claude/standards/rules.md, Navrhuj kompletně, implementuj postupně. Vypiš, které položky z MVP checklistu plán pokryje, a nech to potvrdit.

Když je toho moc. Pokrývá-li zadání víc nezávislých podsystémů, řekni to a rozděl to na víc plánů – každý musí sám o sobě dát funkční, otestovatelný software. Neposílej do implementace plán, který nejde dokončit v rozumném celku.

Doménové znalosti. Předej dál, co si projekt importuje v CLAUDE.md – ~/Context/Coding/coding.md vždy, dál podle povahy Web/web.md, Web/admin.md, Analytics/analytics.md. Plán je má respektovat, ne je objevovat až při /review.

Fáze 2 – Sepsání plánu

Nejsilnější model, xhigh (Volba modelu a effortu podle ~/.claude/standards/delegation.md, Model a effort podle úkolu.) Plán řídí veškerou práci pod sebou: špatně nařezaný úkol nebo chybějící akceptační kritérium rozsévá chyby do všech kroků, které po něm přijdou, a projeví se až u posledního. Proto se na plánovači nešetří, i když samotné sepsání vypadá mechanicky. Odpovídá to i vestavěnému režimu opusplan – plánuje silný model, provádí levnější.

Vyvolej superpowers:writing-plans a předej mu výslovně:

• zadání = docs/architecture.md (nebo docs/requirements.md, byl-li návrh řešení přeskočen),
• kontext = docs/requirements.md – ať v hlavičce plánu sedí pole **Spec:** a je vidět, proč se to staví, a docs/scenarios.md, vede-li ho projekt,
• cíl = docs/plan.md, ne docs/superpowers/plans/… – tohle mu musíš říct, jinak si založí vlastní adresářový strom vedle tvého (~/.claude/standards/structure.md: v docs/ jednoslovné anglické názvy bez datumových prefixů),
• rozsah = jen položky MVP odsouhlasené ve Fázi 1,
• doménové znalosti z Fáze 1,
• že volbu způsobu implementace na konci nenabízí – tu řeší /implement,
• že každý úkol musí mít ověřitelné akceptační kritérium – viz Fáze 3.
• že každý úkol odkazuje na konkrétní sekce dokumentace s kotvou, ne na celé soubory – viz Fáze 3.
• že jména souborů nesmějí odpovídat vzorům Read, Edit a Write v permissions.deny (~/.claude/settings.json a nastavení projektu) – zákaz by zápis zablokoval až uprostřed implementace; nejčastěji jde o slova credentials a secrets ve jménu,
• že nadpis úkolu zní doslova ### Task <N>: <název> i v českém plánu – slovo Task a číslo čtou skripty implementace, takže jsou identifikátor; česky je jen název.

Fáze 3 – Kontrola

writing-plans má vlastní sebe-revizi. Neopakuj ji – ověř, že proběhla, a doplň, co jí chybí:

1. Proběhla vůbec? Plán musí být bez „TBD“, „doplnit později“, „ošetřit chyby“ a bez „podobně jako úkol N“.
2. Pokrytí MVP. Projdi MVP checklist ze zadání položku po položce a ukaž, který úkol ji plní. Nepokrytá položka je nález, ne detail.
3. Nic navíc. Obráceně: je v plánu úkol, který v MVP není? Buď patří do další fáze, nebo se zapomnělo aktualizovat zadání. Zeptej se, neřeš to sám.
4. Konzistence názvů. Funkce, typy a parametry použité v pozdějších úkolech musí sedět s tím, co definují dřívější. clearLayers() v úkolu 3 a clearFullLayers() v úkolu 7 je chyba.
5. Zadání se nezměnilo pod rukama. Sáhl-li někdo během psaní plánu do requirements.md nebo architecture.md, ohlas to.
6. Každý úkol má ověřitelné akceptační kritérium. Ne holou větu („funguje přihlášení“), ale zaškrtávací seznam, u kterého jde jednoznačně říct ano/ne – a u kódu příkaz z kontraktu, který to ověří. Kritérium, které neumí rozsoudit stroj ani jednoznačně člověk, je nedopsaný úkol.
7. Testy pokrývají scénáře, ne řádky. Projdi scénáře a Varianty a ukaž, který úkol je pokrývá testem. Nepokrytý scénář je nález. Scénáře ber ze docs/scenarios.md, vede-li ho projekt – je taxativní, takže pokrytí jde spočítat; jinak ze sekce Hlavní scénáře v docs/requirements.md.
8. Testy jsou psané tak, aby šly schválit teď. Tenhle plán je jediné místo, kde si člověk testy přečte dřív, než existuje kód – potom už je nemůže nezaujatě posoudit, protože bude posuzovat, jestli procházejí. Piš je konkrétně, včetně vstupů a očekávaných hodnot.
9. Úkol unese svůj kontext. Každý úkol odkazuje na konkrétní sekce dokumentace s kotvou (model.md#order), ne na celý soubor ani na kapitolu, a kód nebo cestu v backticku nebere jako odkaz. Implementující agent dostane jen to, nač úkol ukazuje: odkaz na soubor o stovkách tisíc znaků znamená, že buď čte obří text a ztratí zadání, nebo hádá. Hlavičkové pole **Spec:** nese cestu v backticku, ne odkaz. Má-li projekt mez velikosti sekce a součtu za úkol hlídanou testem, plán ji musí splnit; úkol nad mezí se rozdělí, nebo odkáže na podsekci.
10. Žádný soubor plánu nezakazuje permissions.deny. Pusť python3 ~/.claude/skills/breakdown/denied.py docs/plan.md . z kořene projektu; každý vypsaný soubor přejmenuj v celém plánu i v návrhu, který ho jmenuje, a skript pusť znovu, dokud neskončí kódem 0. Kód 2 znamená, že plán nejde přečíst – řekni to.

Nálezy oprav rovnou. Sporné předlož uživateli po jednom přes AskUserQuestion.

Commitni, má-li projekt zapnutý autocommit.

Fáze 4 – Předání

Nepokračuj do implementace sám. Plán se schvaluje, než se podle něj začne psát kód – to je poslední levné místo, kde se dá otočit.

Plán je hotový a commitnutý v docs/plan.md – <N> úkolů. Přečti si ho prosím; až ho odsouhlasíš, pustíme implementaci přes /implement.

Nabídni před tím ještě /oponent docs/plan.md, je-li plán rozsáhlý. Hlediska nevypisuj – sestaví si je sám podle svého katalogu (~/.claude/standards/rules.md, Single source of truth).

## Plán hotový

- **Soubor:** docs/plan.md – <N> úkolů
- **Spec:** <architecture.md / requirements.md>
- **Rozsah:** <které položky MVP>
- **Pokrytí scénářů:** <N z M scénářů ze scenarios.md, nebo z requirements.md, má test>
- **Generativní testy:** <kde plán zavádí fuzzing / property-based testy podle architecture.md, nebo „architektura je nepředepisuje">

**Nepokryto vědomě**
- [co zůstalo na další fázi, nebo „nic“]

Vypisuj to jako Markdown, ne jako blok kódu, a řádky nezalamuj natvrdo – ~/.claude/standards/rules.md, Styl odpovědí.

Zakonči jednou z těchto vět, nikdy ničím vágním mezi tím:

• Plán je hotový, můžeš ho projít a pak spustit /implement.
• Plán hotový není – brání tomu: <konkrétní seznam>.

Kudy dál je poslední blok odpovědi, za verdiktem – tvar a pravidla, kdy odrážka musí vypsat celý řetěz včetně ukončení session, drží ~/.claude/skills/handoff.md. Odtud vede:

• /implement – až uživatel plán přečte a odsouhlasí
• volitelně před tím, je-li plán rozsáhlý, /end, pak /clear, a /oponent docs/plan.md až v nové session – tahle plán psala a je na něj zaujatá