implement · git:20261103.d40ac78 · 2026-11-03 · sha256 2292522d2a32e07f

implement git:20261103.d40ac78A

Immutable. This exact content never changes and is served at /api/v1/blob/2292522d2a32e07f.

---
name: implement
description: Skill se použije, když uživatel zadá "/implement", nebo chce podle hotového implementačního plánu v docs/plan.md odpracovat úkoly jeden po druhém – včetně testů, ověření a commitů. Umí navázat na rozpracovaný plán.
allowed-tools: [Read, Write, Edit, Glob, Grep, Bash, Agent, AskUserQuestion, Skill]
---

# Implement

## Co skill dělá

Vezme **`docs/plan.md`** a odpracuje ho úkol po úkolu – u každého test, implementace, ověření a commit. V *Životním cyklu projektu* (`~/.claude/standards/rules.md`) je to šestý krok osy: navazuje na `/breakdown` a předává na `/release`; v mezeře mezi nimi stojí `/review` po každé hotové featuře.

## Co skill nedělá

- **Nemění plán.** Ukáže-li se, že je plán špatně, zastaví se – viz *Když plán neplatí*. Plán píše `/breakdown` a opravit ho patří jemu; tady se odpracovává.
- **Nedodělává, co v plánu není.** Nápad nad rámec plánu jde do `docs/todo.md` nebo `docs/backlog.md`, ne do kódu.
- **Neuzavírá feature.** Hotovou práci prověřuje `/review`, vnitřní konzistenci `/consistency` samostatné kontrolní kroky (`~/.claude/standards/lifecycle.md`, *Co smí stát v které mezeře*), a zápis session `/end`, kterým session končí.

## Jak je to postavené uvnitř

Skill dnes řídí **`superpowers:subagent-driven-development`** nebo **`superpowers:executing-plans`**. To je **implementační detail, ne rozhraní** – vnitřek se může kdykoliv změnit, aniž se změní, jak se skill volá.

Co je závazné: vstupem je `docs/plan.md`, pracuje se úkol po úkolu, každý úkol končí ověřeným a commitnutým stavem, a po posledním úkolu se feature neuzavírá automaticky.

------

## Fáze 0 – Příprava

**Společný začátek drží `~/.claude/skills/preflight.md`** – načti si ho a řiď se jím **včetně bodu 4**: průběžná kontrola musí být zelená dřív, než se dotkneš prvního souboru, jinak nepůjde poznat, co jsi rozbil ty. Bod 5 odpadá, tenhle skill pracuje nad plánem, ne nad diffem větve.

Navíc si ověř tohle:

1. **Najdi plán.**

   | Stav | Co dělat |
   |---|---|
   | `docs/plan.md` neexistuje | **Zastav se.** Nabídni `/breakdown`, a pokud chybí i zadání, `/specify`. |
   | Existuje, nic není odškrtnuté | Normální běh od prvního úkolu. |
   | Existuje, část odškrtnutá | **Naváž na prvním neodškrtnutém úkolu.** Nejdřív ale ověř, že odškrtnuté opravdu hotové jsou – viz bod 5. |
   | Vše odškrtnuté | Řekni to a nabídni uzavírání podle *Životního cyklu projektu*. Nehledej si práci navíc. |

2. **Rozpracované změny jsou tu riziko navíc.** Smíchají se s prací podle plánu a přestane být poznat, co je čí. Vypiš je a zeptej se, jestli je commitnout, odložit, nebo pokračovat i tak.
3. **Ověř skutečný stav proti plánu.** U navazování nevěř zaškrtávátkům – podívej se, jestli soubory a testy z odškrtnutých úkolů opravdu existují a procházejí. Plán mohl zůstat odškrtnutý po přerušené session, kde se práce nedokončila. Nesedí-li to, ohlas to a zeptej se, než začneš.
4. **Izolace větve.** Má-li projekt worktree layout, pracuje se v už existující větvi – **nezakládej další worktree**. Nemá-li ho a jde o větší práci, nabídni izolaci; pokud ji uživatel chce, použij `superpowers:using-git-worktrees`.

------

## Fáze 1 – Volba režimu

Zeptej se **přes `AskUserQuestion`** – jedna otázka, tři volby, v lidské řeči:

- **Po úkolech se čtením mezi nimi** *(doporuč tuhle)* – na každý úkol jde čerstvý pracovník, který nevidí předchozí konverzaci, a mezi úkoly se výsledek zkontroluje. Chytá to, když se plán někde rozejde se skutečností, a nehromadí se kontext. Vhodné na cokoliv delšího než pár úkolů.
- **V jednom kuse s kontrolními body** – rychlejší, méně režie, ale chyba se odhalí až o několik úkolů dál. Vhodné na krátký plán a na práci, kterou dobře znáš.
- **Bez zastávek do splnění cíle** – nabízej **jen tehdy, když jsou splněné všechny podmínky níž**, jinak tuhle volbu vůbec neuváděj.

Podle volby vyvolej `superpowers:subagent-driven-development`, respektive `superpowers:executing-plans`, a předej mu cestu k plánu, kořen projektu a doménové znalosti z `CLAUDE.md`.

### Bez zastávek do splnění cíle

Nejsamostatnější režim: cíl se nastaví jako podmínka přes `/goal` (vestavěný příkaz Claude Code, ne skill odsud), oddělený evaluátor ji přehodnocuje po každé odpovědi a práce běží, dokud se cíl nevyřeší. **Není to rychlejší varianta předchozích dvou, je to výměna** – míň přerušení za horší bezpečnostní profil, protože zranitelností v kódu přibývá s počtem iterací, které nad ním agent stráví bez nezávislé kontroly.

**Nabídni ho, jen když platí všech pět** (`~/Context/Coding/quality.md`, *Autonomie se stupňuje, nezapíná*):

1. **Každý úkol v plánu má akceptační kritérium rozsouditelné strojem** – příkaz z kontraktu, ne věta.
2. **Projekt má `test` v kontraktu a testy něco tvrdí** – ideálně doložené mutation score, ne jen pokrytím.
3. **Zadání se během práce nemění** – refactoring, migrace, oprava reprodukovatelné chyby ano; rozdělaný nový produkt ne.
4. **Průběžná kontrola je vynucená hookem**, ne jen instrukcí.
5. **Uživatel o tom režimu ví a vybral si ho** – nikdy ho nezapínej sám proto, že se ti zdá vhodný.

**Když ho pustíš, drž tři pojistky:**

- **Strop na iterace i na tokeny**, řečený dopředu. Smyčka bez stropu se nezastaví, jen dojde.
- **Diff testovacích souborů hlídej zvlášť.** Jakákoliv změna v testech během běhu je **zásah, který se ohlásí** – ne tichá součást práce. Čím delší smyčka, tím větší pokušení ohnout to, co ji měří.
- **Po doběhnutí povinné `/review`**, i když je všechno zelené. Průběžná kontrola říká, že testy prošly, ne že kód dělá, co má.

------

## Fáze 2 – Průběh

**Přeruš včas, nabyl-li kontext.** Dlouhý běh přes mnoho úkolů je místo, kde session narazí na strop okna. Práh a tvar nabídky drží `~/.claude/skills/handoff.md`, *Přerušení dlouhého průchodu*, a zápis dělá `/end` v režimu `break`; ukládá se tu ale **méně** než u nálezů – úkoly už v `docs/plan.md` stojí, takže do `todo.md` jde jen to, co v plánu není: odchylky, na které jsi narazil, a rozhodnutí, která z nich vzešla.

**Výchozí model, `medium`–`high`** (Volba modelu a effortu podle `~/.claude/standards/delegation.md`, *Model a effort podle úkolu*.) Odpracování dobrého plánu je z velké části uplatnění hotového rozhodnutí, ne vymýšlení – proto sem nepatří nejdražší tier. **Eskaluj ale u konkrétního úkolu**, který se nedaří: nejdřív zvyš effort, teprve pak sáhni po silnějším modelu. Opakované „skoro to funguje“ na jednom úkolu je signál, že je málo chytrosti nebo špatný plán, ne že se má zkoušet dál totéž.

Při práci hlídej osm věcí, které se z plánu samy neuhlídají:

**Průběžná kontrola po každém úkolu.** Úkol není hotový, když je napsaný kód – je hotový, když projde `typecheck`, `lint` a `test` podle *Kontraktu příkazů* v projektovém `CLAUDE.md`. Teprve pak commit a další úkol. Podrobně `~/Context/Coding/quality.md`.

**Netvrď, že to prošlo, bez výstupu.** Do shrnutí patří příkaz a jeho návratový kód, ne věta „testy procházejí“. Nemá-li projekt příkaz v kontraktu, řekni, co se tím nezkontrolovalo.

**Testy jsou jen ke čtení.** Plán je napsal a uživatel je schválil dřív, než vznikl kód – v tom je jejich cena. Nesedí-li test s implementací, **první hypotéza je, že je špatně kód**. Ukáže-li se, že je špatně test, je jeho změna **samostatný zásah, který ohlásíš a necháš schválit**, ne tichá součást úkolu. Přidání `skip`, zeslabení `assert` nebo smazání testu je vždycky chyba, i když je pak zeleno.

**Commity.** Plán má commit jako poslední krok každého úkolu. Má-li projekt zapnutý autocommit, **necommituj dvakrát** – řiď se plánem a autocommit nech na změny mimo úkoly. Commit message piš česky a věcně: co se změnilo, ne které soubory.

**Doménové znalosti.** Kód se má psát podle nich rovnou, ne se k nim vracet až v `/review`. Neznamená to duplikovat kontrolu – znamená to je respektovat.

**Nápady nad rámec plánu.** Cokoliv, co tě při psaní napadne a v plánu to není, zapiš s celou úvahou – do kódu ne. *Nerozhoduj potichu nad rámec zadání.* **Kam:** chybějící kus práce, který se udělat musí, do `docs/todo.md`; volný nápad, o kterém nikdo nerozhodl, do `docs/backlog.md` (`~/.claude/standards/structure.md`, *`backlog.md`*). Fronta úkolů zaplevelená nápady přestane být frontou. **Nemá-li projekt `backlog.md`, založ ho** a řekni to; do `todo.md` nápad nepatří, tím by se z fronty stal mišmaš (`~/.claude/standards/rules.md`, *Odložené věci pojmenuj a zaparkuj*).

**Průběžné zápisy.** Padne-li během práce rozhodnutí (a padá), jde do `docs/decisions.md` hned, i se zavrženými variantami. Vybroušený princip do `docs/rules.md`. **Hotovou položku z `docs/todo.md` přesuň do `docs/done.md`** hned, jak je hotová – neodškrtává se na místě (`~/.claude/standards/rules.md`, *Odložené věci pojmenuj a zaparkuj*). Nečekej na `/end`; ten je jen záchranná síť.

**Po každém větším celku levné review.** Po skupině souvisejících úkolů (ne po každém) spusť **`/code-review low`** – úroveň uveď jako parametr, ne slovem: bez ní se použije ta, kterou uživatel zadal naposledy, klidně v jiném projektu. Běží v čerstvém kontextu, takže vidí, co ty už nevidíš, a chyba nalezená teď stojí minuty. Plný panel je až `/review` při uzavírání.

------

## Když plán neplatí

Při psaní kódu se pravidelně ukáže, že plán někde nesedí. **Neopravuj to potichu v kódu** – tím se plán rozejde se skutečností a přestane být k čemu.

Podle toho, jak hluboko problém sahá:

| Kam sahá | Co udělat |
|---|---|
| Jen úkol – špatný název souboru, chybějící krok | Oprav plán i kód, řekni to v jedné větě a pokračuj. |
| Návrh – takhle postavené to nefunguje | **Zastav se.** Vrať se do `docs/architecture.md`, uprav ho a nech přepsat dotčené nehotové úkoly. |
| Zadání – ukázalo se, že chceme něco jiného | **Zastav se a zeptej se.** Změna produktového záměru není tvoje rozhodnutí; teče shora dolů, viz `structure.md`. |

**Nikdy neškrtej úkol jako hotový, aby se dalo pokračovat.** Zablokovaný úkol nech neodškrtnutý, zapiš proč, a zeptej se.

------

## Fáze 3 – Závěr

Po posledním úkolu **feature neuzavírej**. Vypiš stav a předej to na řetěz uzavírání:

```
## Implementace hotová

- **Plán:** docs/plan.md – <hotovo>/<celkem> úkolů
- **Režim:** <po úkolech / v jednom kuse / bez zastávek>
- **Commity:** <N>

**Odchylky od plánu**
- [co se muselo změnit a proč, nebo „žádné“]

**Nedokončeno**
- [zablokované úkoly i s důvodem, nebo „nic“]

**Zapsáno mimo kód**
- docs/decisions.md: N
- docs/done.md: N · docs/todo.md: N · docs/backlog.md: N · docs/rules.md: N

**Průběžná kontrola:** <výstup posledního běhu – příkaz a návratový kód>
```

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 odpracovaný a průběžná kontrola je zelená, můžeš pustit kontrolní kroky z mezery a pak /release.`
- `Odpracovaný není – zbývá: <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:

- `/end`, pak `/clear`, a `/review` až v nové session – prověření hotové práce, kterou tahle session psala; za ním zbytek mezery před `/release` (`~/.claude/standards/lifecycle.md`, *Co smí stát v které mezeře*)
- zbyl-li v plánu zablokovaný úkol, je další krok jeho odblokování, ne revize – pojmenuj, co k němu chybí