Consistency

Co skill dělá

Proveď audit vnitřní konzistence projektu. Cíl: najít vše, co si v projektu vzájemně odporuje, je redundantní, špatně zatříděné nebo nekonsistentní – a opravit to spolu s uživatelem.

V Životním cyklu projektu (~/.claude/standards/rules.md) je to kontrolní krok, ne bod na ose: stojí v mezeře před /breakdownem a v mezeře před /release, pokaždé až za /review – uklízí i to, co nastřílel on. Nečeká na pozici, ale na to, až se v projektu nasbírá dost změn.

Co skill nedělá

• Nehledá chyby v kódu. Na korektnost provedených změn je /review – ten uvnitř volá vestavěné /code-review jako jednoho ze svých specialistů, takže poslat uživatele rovnou na něj by ho připravilo o zbytek panelu i o ověření nálezů.
• Nekontroluje soulad s doménovými znalostmi. Na odchylky od předpisů v ~/Context/ je /review. Tenhle skill se ptá „sedí si projekt sám se sebou?“, ne „drží předpis?“ – projekt může být dokonale konzistentní a přitom konzistentně porušovat pravidla.
• Neposuzuje, jestli je návrh dobrý. Na to je /oponent.
• Nevytěžuje session. Zápis dohod do souborů dělá /end – ten se ptá „je v souborech všechno, co v session padlo?“, tenhle „sedí si projekt sám se sebou?“.
• Nemění chování. Nálezy, které by ho změnily, jsou vždy sporné a jdou přes uživatele.
• Neměří, co měří průběžná kontrola a /review. Typecheck, linter, testy, audit závislostí ani scan tajemství nejsou jeho otázka; průběžnou kontrolu před auditem pouští jen tehdy, když stav pracovního stromu nikdo neověřil (Fáze 0). Po každé vlastní opravě ano (Fáze 4 a 5): tou se stav změnil, takže dřívější doklad už neplatí. Tenhle skill dorovnává jen ten konzistenční zbytek, který ostatní kroky životního cyklu nepokrývají – ve výchozím rozsahu nad tím, čeho se dotkla větev, s full nad celým projektem.

Jak je to postavené uvnitř

Deterministickou vrstvu skill nepíše sám (Spusť nástroje, které jiné kroky životního cyklu nedělají): mrtvý kód a nepoužité závislosti měří knip, odkazy a kotvy v Markdownu ~/.claude/skills/links.py, zbytek grep a git blame. Který nástroj to je, je implementační detail – vymění se, jakmile bude lepší, a na tom, jak se /consistency volá a co vrací, se tím nezmění nic.

Závazné je proti tomu tohle a tiše se to změnit nesmí: co jde změřit nástrojem, nehledá agent čtením (~/.claude/standards/delegation.md, Model a effort podle úkolu, pravidlo nula); nespuštěná kontrola se vypisuje jako nespuštěná, nikdy jako nula nálezů; a nálezy z nástrojů nesou tag toolchain a neprocházejí posouzením, protože nástroj nehalucinuje.

links.py leží ve skills/, ne v adresáři skillu, a je to záměr. Volá ho i /end a skript uvnitř cizího skillu by se volat nesměl (~/.claude/skills/skills.md, Číslování a názvosloví). Kdo si nainstaluje /consistency bez /end, dostane ho stejně.

Rozsah

• /consistency nebo /consistency branch (výchozí) – soubory dotčené prací na aktuální větvi a soubory, které na ně odkazují. Ten druhý půlkruh je podstatný: nekonzistence skoro nikdy nežije v jednom souboru, ale mezi změněným a tím, co o něm mluví.
• /consistency full – celý projekt bez ohledu na diff. Použij, když uživatel napíše full, jinak nikdy.

Proč výchozí rozsah není celý projekt. Skill se pouští opakovaně – pokaždé, když se v projektu nasbírá dost změn –, ale cena kompletního auditu je úměrná velikosti projektu, ne velikosti změny. Na projektu s dvěma sty soubory to znamená, že se při každém běhu znovu najde tentýž starý dluh – a uživatel má dvě možnosti: znovu ho odklikat, nebo ho umlčet do ## Consistency. Druhá je levnější, takže se stane výchozí, a tím z ní roste umlčovací seznam. Ze stejného důvodu se /consistency jako první vynechá, jakmile se spěchá.

full se vyplatí jednou za čas a před /release, ne při každém běhu. U staršího projektu předem upozorni, kolik souborů se bude procházet, a při řádově stovkách se zeptej přes AskUserQuestion, jestli pokračovat, nebo omezit rozsah na konkrétní adresář – stejně jako to dělá /review full.

Fáze 0 – Příprava: kontext a konvence

Společný začátek drží ~/.claude/skills/preflight.md – načti si ho a řiď se jím; krok Urči rozsah níž rozvíjí jeho bod 5 o druhý půlkruh. Bod 4 se řídí tím, jestli stav pracovního stromu už někdo ověřil, ne tím, který krok běžel před tímhle: má-li projekt průběžnou kontrolu zapnutou (souhlas vypíše ~/.claude/hooks/verify.sh --list), pustil ji Stop hook nad aktuálním stromem po poslední odpovědi a znovu se nepouští; nemá-li ji, pusť ji podle bodu 4, dřív než se dotkneš prvního souboru.

Nad rámec toho nasbírej konvence projektu, ať má agent proti čemu měřit.

0.1 Urči rozsah

Postupem z ~/.claude/skills/preflight.md, bod 5 – včetně toho, co dělat, když se hlavní větev nenajde nebo je diff prázdný. Neopisuj ho sem; jeden postup, jedno místo.

K souborům z diffu přidej druhý půlkruh: soubory, které na ně odkazují. Bez něj rozsah nedává smysl, protože nekonzistence skoro nikdy nežije v jednom souboru, ale mezi změněným a tím, co o něm mluví. Hledej je takhle:

git diff --name-only <merge-base>...HEAD          # co se změnilo
grep -rl "<basename>" . --exclude-dir=.git        # kdo o tom mluví

U přejmenované sekce, funkce nebo klíče grepuj starý i nový název – zbytek po přejmenování je nejčastější nález celého skillu a najde se právě v tom druhém půlkruhu.

V režimu full tenhle krok přeskoč: rozsahem jsou všechny zdrojové soubory projektu. Vynech node_modules/, dist/, build/, vendor/, generated/, *.gen.* a cokoliv v .gitignore.

0.2 Načti dokumentaci konvencí

Pokud existují, přečti:

• Projektový CLAUDE.md
• README.md, CONTRIBUTING.md, STYLEGUIDE.md
• eslint.config.*, .eslintrc*, prettier.config.*, .prettierrc*, biome.json
• tsconfig.json (zejména strict, target, lib, paths)
• .editorconfig
• package.json (engines, scripts, workspaces)

Vede-li projekt docs/glossary.md (poznáš z ## Struktura a dokumentace v CLAUDE.md), přečti ho jako závaznou konvenci pojmenování. Je to jediné místo, kde stojí, jak se čemu v téhle doméně říká, takže odchylka od něj není kosmetika, ale rozpor s dohodou – hlas ji důsledněji než odchylku, kterou jsi odvodil z kódu. Platí to obousměrně: pojem, který v kódu žije a v glosáři chybí, je taky nález, protože slovník, který se přestal doplňovat, začne lhát.

Z těchto souborů sestav soupis konvencí – co je v projektu explicitně dohodnuto. Co projekt sám aktivně dodržuje, nehlas jako nízkou odchylku; naopak rozpor s dohodnutými konvencemi hlas důsledněji.

0.3 Načti seznam ignorovaných položek

Pokud projektový CLAUDE.md obsahuje kapitolu ## Consistency, přečti ji. Položky tam uvedené (s důvodem) vůbec neuváděj v nálezech – uživatel je dřív označil jako „won't fix“.

0.4 Spusť nástroje, které jiné kroky životního cyklu nedělají

Typecheck ani linter tady před auditem znovu nespouštěj. Stav, se kterým sem přicházíš, ověřila průběžná kontrola podle Fáze 0 – opakovat je nad týmž stromem znamená platit časem i tokeny za tentýž výsledek. Platí to jen pro tenhle soupis: po každé opravě, kterou uděláš ty, se ověřuje znovu (Fáze 4, bod 1). Viz ~/.claude/standards/lifecycle.md, Povolená opakování.

Spusť jen to, co je vlastní téhle otázce, tedy „sedí si projekt sám se sebou?“. Na to se /review neptá. Všechno tohle je měřitelné, takže to nemá hledat agent čtením (~/.claude/standards/delegation.md, Model a effort podle úkolu, pravidlo nula). Prahy a majitele drží ~/Context/Coding/quality.md, Kontroly, které nestojí tokeny:

Běžela-li nad týmž stromem CI, přečti její výsledek místo opakovaného spouštění – podmínky jsou tytéž jako v /review, Deterministická vrstva: headSha sedí s HEAD a git status --porcelain je prázdné. Nesedí-li obojí, pusť nástroje lokálně a řekni, že se CI nepoužila.

Nemá-li projekt, čím to spustit, krok přeskoč a řekni to – i s tím, co se tím nezkontrolovalo, položku po položce. Nespuštěná kontrola se nikdy nevypisuje jako nula nálezů: tři přeskočené kroky vypsané jako tři nuly čte uživatel jako tři čisté výsledky. U obsahového či znalostního projektu je normální, že se přeskočí skoro všechno – kromě kontroly odkazů, která tam funguje nejlépe z celé tabulky: rozejití odkazu na přejmenovanou sekci je nejčastější vada textového repozitáře a zároveň ta, kterou agent nejspolehlivěji přehlédne, protože kotva uhodnutá z nadpisu vypadá správně (~/.claude/standards/rules.md, Při nejistotě se zeptej). Audit v dalších fázích běží stejně, jen bez zbytku téhle vrstvy.

Výstupy si zapamatuj a předej je agentovi. Nálezy z toolchainu se označí tagem [toolchain] a neprocházejí posouzením – nástroj nehalucinuje.

Běží-li /consistency samostatně mimo životní cyklus (tedy bez předchozího /review) a projekt má Kontrakt příkazů, řekni uživateli jednou větou, že průběžná kontrola teď prověřená není a že /review se dělá dřív.

Fáze 1 – Průzkum projektu

Agent je sběr, ne posouzení: typ reader, výchozí model, low (Volba modelu a effortu podle ~/.claude/standards/delegation.md, Model a effort podle úkolu.) Prochází soubory podle vyjmenovaných kritérií a vrací nálezy do JSON – úzké zadání, kde low stačí. Úsudek, co s nálezem, dělá hlavní session ve Fázi 2, kde se rozhoduje o mechanickém versus sporném.

Škálu závažnosti drží ~/.claude/skills/severity.md a je společná se všemi skilly, které hlásí nálezy. Zadání níž si stupně opisuje schválně – je to text pro agenta bez kontextu session, kde je odkaz do nenačteného souboru mrtvý (severity.md, Kdo ji používá, výjimka pro zadání subagentů). Doménové čtení stupňů v zadání obecnou definici zpřesňuje, nenahrazuje.

Nejdřív inventura rozsahu, pak agent

Vyrob si seznam souborů v rozsahu příkazem a zapamatuj si jeho délku – u branch z diffu proti hlavní větvi plus soubory, které na ně odkazují, u full z git ls-files. Ten počet je to, proti čemu se v Přehledu vykazuje pokrytí, takže ho neodhaduj (~/.claude/standards/rules.md, Hodnotu, kterou čte stroj, nepiš – nech ji vyrobit příkazem).

Proč to tady je: prázdné pole nálezů vypadá stejně, ať agent prošel dvě stě souborů, nebo dvanáct – a „prošel jsem to systematicky“ je tvrzení, které nemá čím být doložené. Je to táž vada, kterou u /end vyřešil měřený poměr odškrtnutých promptů; zdůvodnění drží ~/.claude/docs/decisions.md, /end se zúžil na jádro, zrušil čtenáře i subagenta a úplnost začal měřit.

Spusť subagenta typu reader s tímto zadáním (předej mu absolutní cestu k projektu, seznam souborů v rozsahu, konvence z Načti dokumentaci konvencí, seznam ignorovaných z Načti seznam ignorovaných položek a výstupy nástrojů z Spusť nástroje, které jiné kroky životního cyklu nedělají):

Prohledej zadaný rozsah (viz *Rozsah* výš) a najdi všechny případy vnitřní nekonzistence. Procházej systematicky.

Část nekonzistencí už našly nástroje před tebou (mrtvý kód a nepoužité závislosti, env proti `.env.example`, překladové klíče, shoda verzí runtime, zastaralé TODO, **mrtvé odkazy a kotvy v Markdownu**) a jejich nálezy dostáváš v zadání. **Nehledej je znovu** – hledej to, co nástroj změřit neumí. Platí to i o odkazech: nekontroluj, jestli cíl existuje, to je změřené. Tvoje otázka je, jestli text u odkazu **tvrdí o cíli pravdu**.

PŘED HLÁŠENÍM PROBLÉMU vždy zkontroluj, že:
- Není uveden v kapitole `## Consistency` projektového `CLAUDE.md` (předané v zadání) – pokud ano, neuváděj ho
- Není přímo nad řádkem komentář `consistency-ignore: <důvod>` – pokud ano, respektuj ho
- Soubor není v cestě označené jako legacy/vendored/generated (`*.gen.*`, `vendor/`, `legacy/`, `generated/`, `node_modules/`, `dist/`, `build/`) – pokud ano, neuváděj ho
- Pokud konvence projektu (předané v zadání) explicitně dovolují to, co bys hlásil jako odchylku, neuváděj to

KRITICKÉ (mohou rozbít funkčnost):
- Typové nesrovnalosti: stejný koncept/entita definovaná různými typy v různých souborech
- Duplicitní konfigurace s různými hodnotami (tsconfig, package.json, env soubory)
- Interface/schéma deklarované jinak než je skutečně používáno
- Import cest, které nesedí se skutečnou strukturou souborů
- Cross-layer kontrakty: rozdíly mezi DB schématem ↔ ORM modelem ↔ TypeScript typy ↔ validačním schématem (Zod/Yup); API endpoint ↔ klientský volání (request/response, query params); GraphQL/OpenAPI specifikace ↔ implementace; form schéma ↔ submit payload ↔ serverový endpoint
- Bezpečnostní konzistence – **hlas rozdíl uvnitř skupiny, ne chybějící ochranu jako takovou**: stejný typ endpointu nebo tabulky chráněný nestejně (RLS, auth middleware, sanitizace vstupu, CORS, rate-limiting). Vyjmenuj skupinu, která si má být podobná, a v čem se liší. **Neposuzuj, jestli je ta ochrana dostatečná** – to dělá specialista na bezpečnost v `/review` na silném modelu; tady jde jen o to, že se dvě podobná místa chovají různě
- Verzování runtime: různé verze stejné lib v monorepo packages; TS `target` vs browserslist drift

STŘEDNÍ (technický dluh):
- Duplicitní logika na více místech (stejná funkce implementovaná vícekrát)
- Různé patterny k stejnému problému (např. async/await vs. .then())
- Behaviorální konzistence: stejný typ chyby řešený různě (throw vs. Result vs. silent vs. null); různé loggery/úrovně/formáty pro stejný typ události; podobné endpointy validují vstup jen někdy; auth/authz mechanismy se liší napříč podobnými endpointy bez důvodu; data fetching / state management řeší stejný use-case různě (lokální state vs. global store, fetch vs. React Query vs. SWR)
- Špatně zatříděné soubory (utilita v komponentách, komponenta v utils/)
- README nebo dokumentace popisující funkce, které neexistují nebo fungují jinak
- Obsah ve špatném souboru podle cílového čtenáře (tohle je zatřídění, ne soulad s předpisem – proto to sem patří, i když se opírá o `structure.md`): `README.md` je popis projektu **pro člověka**, takže normativní pokyny pro Clauda (pravidla práce v repozitáři, konvence, povinnost něco udržovat) v něm nemají co dělat ani odkazem – patří do `CLAUDE.md`, `docs/rules.md` nebo `docs/decisions.md`. Definice je v `~/.claude/standards/structure.md`
- Zapomenuté zbytky po odstranění: když se v minulosti odstraňoval kód, feature nebo komponenta, mohly na dalších místech zůstat pozapomenuté části – importy smazaného modulu, konfigurace pro zrušenou funkci, typy/interfacy pro odstraněnou entitu, registrace odebrané route nebo pluginu, zmínky v dokumentaci nebo komentářích, testy odstraněné funkcionality, env proměnné pro mrtvou feature, reference v package.json apod.
- i18n a UI texty: stejný UI koncept různě pojmenovaný napříč obrazovkami ("Smazat" vs "Odstranit" vs "Vymazat"); nesystematický mix jazyků v UI textech
- Zastarání: feature flagy s trvale stejnou hodnotou na všech check-pointech (ready to inline/remove); pozastavené migrace (částečná DB migrace bez follow-upu)

NÍZKÉ (konzistence stylu):
- Mixing naming conventions ve stejném kontextu (camelCase vs snake_case u proměnných, kebab-case vs PascalCase u souborů)
- Inconsistent export styly (named vs default export bez zjevného důvodu)
- Komentáře které nepopisují kód pod nimi (zastaralé, mylné)
- Nekonzistentní formátování nebo struktura podobných souborů (např. různá struktura API route handlerů)
- Naming napříč boundaries: stejná entita s různými názvy v různých vrstvách (`User` v DB / `UserAccount` v API / `userObj` v UI); inkonzistentní pluralizace v adresářích a routes (`users/user`, `items/item`); stejný koncept různými slovy v komentářích / UI / kódu (mix čeština/angličtina bez systému)

SKUPINY SOUBORŮ SE SDÍLENOU STRUKTUROU (kontroluj vždy samostatně):
Aktivně hledej adresáře, kde více souborů stejného typu (MD, JSON, YAML, TS...) zřejmě reprezentuje instance stejného konceptu – každý soubor = jeden systém, jedna entita, jeden modul apod. Typické signály: soubory mají podobné názvy, leží v jednom adresáři, obsahují podobné sekce nebo klíče.

Pro každou takovou skupinu:
1. Urči společnou strukturu (průnik sekcí/klíčů přítomných ve většině souborů)
2. Zkontroluj, zda ji mají opravdu VŠECHNY soubory skupiny
3. Odchylky, které jsou zřejmě záměrné (daný soubor má navíc sekci pro specifickou vlastnost té entity), jsou v pořádku a nehlásit je
4. Hlásit pouze: chybějící sekce ze společného průniku, sekce přítomné jen v podmnožině souborů bez zjevného důvodu, strukturální rozdíly (u jednoho je seznam, u jiného volný text pro stejnou informaci)

Závažnost: obvykle STŘEDNÍ – výjimkou je případ, kdy chybějící sekce způsobuje neúplnost dat (pak KRITICKÉ).

GROUPING (povinné):
- Pokud má víc nálezů stejný root cause (jedno přejmenování → desítky souborů, jeden chybný typ → mnoho dotčených míst), seskup je do jedné položky s podproblémy a v poli `related_root` u následků uveď title root položky.
- Pokud má jeden problém >20 výskytů, neuváděj jednotlivé řádky – uveď pattern, počet výskytů, příklad 3 lokací a navrhni hromadnou změnu (codemod / find-replace). Označ tagem `batch`.
- Nálezy, které pocházejí z toolchain výstupů předaných v zadání (tsc/lint/knip), uveď, ale označ tagem `toolchain` – uživatel může chtít řešit přes nástroj, ne ručně.

Pro každý nalezený problém uveď:
- Kategorie (KRITICKÉ / STŘEDNÍ / NÍZKÉ)
- Stručný popis problému (1-2 věty)
- Konkrétní soubory a řádky (file:line); u batch uveď root + počet + 3 příklady
- Navrhované nejlepší řešení (konkrétní akce, ne vágní "refaktoruj to")
- Tagy `toolchain` / `batch`, pokud se hodí
- `related_root` – title jiného problému, jehož je tento následkem (volitelné)

Výstup strukturuj jako JSON objekt se dvěma klíči. `covered` je **povinné a nesmí být prázdné**:

{
  "covered": ["cesty, které jsi OPRAVDU otevřel a prošel – ne seznam ze zadání opsaný zpátky"],
  "findings": [
  {
    "severity": "KRITICKÉ" | "STŘEDNÍ" | "NÍZKÉ",
    "title": "krátký název problému",
    "description": "popis problému",
    "locations": ["file:line", ...],
    "suggested_fix": "konkrétní navrhované řešení",
    "tags": ["toolchain"?, "batch"?],
    "related_root": "title jiného problému, jehož je tento následkem (volitelné)"
  }]
}

Nenašel-li jsi v prošlém rozsahu nic, vrať prázdné `findings` – s vyplněným `covered` je to stejně platný výsledek jako nález. Nestihl-li jsi rozsah projít celý, **vrať `covered` jen s tím, co jsi prošel** – neúplné pokrytí je platný výsledek, zamlčené neúplné pokrytí ne. Prázdné `findings` se bez `covered` nedá odlišit od toho, že jsi spadl.

Pole basis schéma nemá schválně – nález je nesoulad mezi místy a doložením jsou locations, podle kterých se dá rozpor ověřit přečtením (~/.claude/skills/skills.md, Ověřovací vrstva).

Fáze 2 – Zpracování výsledků

O nálezech mluv obsahem, ne značkou z výstupu agenta. Pořadová čísla a zkratky, pod kterými se nálezy vracejí, jsou interní – uživatel je nikdy neviděl, takže „N1 je širší, než agent hlásil“ mu neřekne nic. Napiš, čeho se to týká: „Chybějící sekce Rizika není jen v discovery.md – chybí ve všech třech dokumentech.“ (~/.claude/standards/rules.md, Interní značky ven nepatří.)

Nejdřív zkontroluj pokrytí, teprve pak nálezy. Chybí-li covered, je prázdné, nebo v něm sedí jen opsaný seznam ze zadání bez jediného nálezu, není to čistý výsledek, ale selhání agenta – pusť ho znovu a nepovede-li se to podruhé, řekni nahlas, že audit pokrytí nedoložil, a nálezy předkládej jako neúplné. Prázdné findings samo o sobě čisto neznamená: u /end se přesně takový výsledek bral za úspěch i za selhání podle situace, a stálo to třetí běh čtenářů navíc.

Soubory z rozsahu, které v covered nejsou, si vypiš jmenovitě – jdou do Přehledu jako neprověřené. Tři neprověřené soubory zamlčené v čistém výsledku jsou horší než tři nálezy.

Z JSON výstupu agenta sestav interní seznam problémů. Seřaď: KRITICKÉ první, pak STŘEDNÍ, pak NÍZKÉ. V rámci každé kategorie umísti root položky před jejich následky (přes related_root), aby se opravou rootu mohlo automaticky vyřešit víc následných.

Rozdělení podle toho, kdo o nálezu rozhoduje

Kritérium drží ~/.claude/skills/findings.md – tři skupiny, a osou je „má oprava víc obhajitelných podob?“, ne „je zásah riskantní?“. Doménové čtení pro tuhle sadu jmenuje ~/.claude/skills/review/SKILL.md, Zpracování výsledků. Neopisuj to sem; drž se toho a přidej jen to, co platí navíc tady:

• Většina nálezů tohohle skillu je jednoznačná, a tedy k opravě bez ptaní. Konzistenční nález je rozpor mezi dvěma místy a z nich je obvykle jedno zdroj – katalog přechodů pro guardy, model pro schéma, copy.md pro znění. Pak se nerozhoduje jak, jen se to musí udělat. Sporný je takový rozpor teprve tehdy, když zdroj není poznat, nebo když se srovnáním rozhoduje o návrhu. Zdroj se pozná podle dokladu, ne podle toho, která strana vypadá novější nebo podrobnější (~/.claude/skills/findings.md, Osa není „jak riskantní“, ale „je z čeho vybírat“) – v knowledge base je proto rozpor dvou odborných pravidel bez dokladu sporný, ne jednoznačný.
• Nálezy s tagem toolchain (z knip/depcheck) posuzuj stejně jako ostatní – nástroj ukazuje, že se něco nepoužívá, ne že se to má smazat.
• Mazání kódu, který vypadá mrtvý, je vždy sporné. Může být volaný dynamicky, z konfigurace nebo z jiného repozitáře.
• Práh pro batch je >20 výskytů (shodně s /review). batch nález sporný být nemusí – rozhoduje, jestli je náhrada jedna a dá se ověřit diffem.

Fáze 3 – Přehled

Zobraz uživateli přehled před tím, než začneš procházet problémy:

## Výsledky konzistenčního auditu

**Nalezeno X problémů celkem:**

- 🔴 Kritické: N
- 🟡 Střední: N
- 🔵 Nízké: N

**Z toho:**

- [toolchain] hlášeno již existujícím nástrojem: N
- [batch] hromadné (>20 výskytů): N

- **Pokrytí:** N z M souborů rozsahu prošel agent [· neprověřeno: jmenovitý seznam, nebo „nic“]
- **Deterministická vrstva:** [který nástroj, kolik nálezů; nespuštěné vypiš jako nespuštěné, ne jako nuly]

- **Opravím rovnou:** N – z toho mechanických (nemění chování) X a jednoznačných (mění, ale podoba opravy je jedna) Y. Jen je vypíšu.
- **Zbývá na rozhodnutí:** M – ty projdeme spolu od nejzávažnějších; u každého navrhnu varianty a zeptám se, kterou zvolit.

1. 🔴/🟡/🔵 [název nálezu – jednou větou]
2. …

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

Pokud nebyly nalezeny žádné problémy, řekni to a skonči.

Přehledem odpověď nekonči. Pokračuj v téže odpovědi rovnou první otázkou Fáze 5 – ~/.claude/skills/findings.md, Ohlášená akce patří do téže odpovědi. Opravy bez ptaní z Fáze 4 se dělají až v zapracování prvního kola, ať na ně uživatel před první otázkou nečeká.

Fáze 4 – Opravy bez ptaní

Mechanické i jednoznačné nálezy (viz Fáze 2) oprav bez ptaní – ale až v zapracování prvního kola, za poslední otázkou Fáze 5, spolu s rozhodnutými nálezy (~/.claude/skills/findings.md, Průchod jde po kolech). Kdo zapracovává a po jakých dávkách, drží tamtéž Zapracování; tady je jen to, co jde do zadání opsané:

1. Ověř, že jsi nic nerozbil. Spouštěj jen příkazy z ## Kontrakt příkazů v projektovém CLAUDE.md (Kontrakt příkazů, viz ~/Context/Coding/quality.md): celou průběžnou kontrolu (typecheck, lint, test), build jen když je rychlý a oprava se ho týká. Dávkuj podle rizika stejně jako /review (viz jeho Fáze 7): opravu, která mění chování, ověř zvlášť, sérii úprav textu a značek jednou na konci. A nepouštěj kontrolu znovu těsně před koncem odpovědi – Stop hook ji nad tímtéž stromem spustí hned po něm. Chybí-li řádek, krok přeskoč nahlas a napiš, co se tím neověřilo; nevymýšlej příkazy, které jsi neověřil. Nemá-li projekt kontrakt vůbec (obsahový, znalostní), verifikace odpadá – ale u opravy, která sáhla do odkazů nebo cest, si aspoň ověř čtením, že cíl existuje. Když kontrola selže, nález se nezapracuje a jde do dalšího kola i s chybou a diffem (~/.claude/skills/findings.md, Zapracování).

2. V souhrnu zapracování vypiš, co jsi opravil – jeden řádek na nález:

   ## Opraveno rovnou (N – X mechanických, Y jednoznačných)
   - 🔵 [název] – soubor:řádek – [co konkrétně změněno]

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

3. Commit dle autocommit nastavení projektu. Mechanické opravy commituj jedním commitem dohromady, ne po jedné; jednoznačné, které měnily strukturu, po tematických celcích, ať je v git blame vidět důvod.

Pokud uživatel na některou z těchto oprav zareaguje nesouhlasem, vrať ji a zařaď do dalšího kola mezi sporné.

Pokud nejsou žádné sporné nálezy, ptaní odpadá a zapracuje se rovnou.

Fáze 5 – Interaktivní průchod

Průchod jde po kolech – nejdřív všechny otázky, pak zapracování bez uživatele (~/.claude/skills/findings.md, Průchod jde po kolech). Přerušení při ptaní nabízí ~/.claude/skills/handoff.md, Přerušení dlouhého průchodu; přijme-li ho uživatel, zbytek fronty uloží /end v režimu break tak, aby z něj nová session rozhodla bez tvého kontextu.

Postup je společný s /review – volání AskUserQuestion (jeden nález = jedna otázka, volby jsou konkrétní varianty opravy, za nimi dvě záchytné, u batch navíc Rozbalit), zápis odpovědí i pravidla pro hromadné opravy jsou v ~/.claude/skills/review/SKILL.md, Interaktivní průchod a Zapracování. Tvar výpisu nálezu i pojmenování záchytných voleb drží ~/.claude/skills/findings.md (Jak nález vypadá, Dvě záchytné volby a co znamenají), takže platí i tehdy, kdyby se /review rozešel. Řiď se jimi a lišíš se jen v těchhle bodech:

Kam se zapisuje volba Neopravovat. Do kapitoly ## Consistency v projektovém CLAUDE.md, ne ## Review – jsou to odpovědi na jinou otázku a nemají se míchat. Kapitolu založ, když chybí, a zapisuj na její konec:

## Consistency

Položky vyhodnocené při /consistency auditu jako „neopravovat". Při dalším auditu
se neuvádějí, dokud se nezmění kód, kterého se týkají.

- **YYYY-MM-DD** · `<short HEAD>` · *<title>*: <důvod>
  - Lokace: <soubor:řádek, ...>

Umlčení expiruje změnou kódu, stejně jako u ## Review – mechaniku i důvod drží ~/.claude/skills/review/SKILL.md, Kapitola ## Review, a platí tu beze změny. Před aplikací filtru tedy u každého záznamu ověř git log --oneline <recorded_hash>..HEAD -- <location>; neprázdný výstup znamená, že se položka předloží znovu i s původním odůvodněním. Hash vyrob git rev-parse --short HEAD.

Datum vyrob příkazem date +%F, nepiš ho z kontextu (~/.claude/standards/rules.md, Hodnotu, kterou čte stroj, nepiš – nech ji vyrobit příkazem).

Verifikace v zapracování. U každé odsouhlasené opravy platí bod 1 z Fáze 4 – příkazy z Kontraktu příkazů, chybějící krok přeskočit nahlas, u projektu bez kontraktu ověřit aspoň čtením, že cíl opravovaného odkazu existuje.

Co tu nehrozí. /consistency nemění chování, takže odpadá pravidlo z /review o doplnění testu k opravě – nálezy, které by chování měnily, jsou tu vždy sporné a jdou přes uživatele.

Fáze 6 – Závěrečné shrnutí

Zapiš průchod do docs/done.md, sekce ## Průchody životním cyklem (~/.claude/skills/passes.md). Čtenářem je příští /consistency, který jinak nepozná, co už bylo auditované a s jakým vědomě zúženým rozsahem – a projede totéž znovu.

- **YYYY-MM-DD** · `/consistency` · `<short HEAD>` · <rozsah> · pokrytí N/M · N nálezů (X opraveno mechanicky, Y po odsouhlasení, Z won't fix)

Datum vyrob date +%F a hash git rev-parse --short HEAD. Nemá-li projekt done.md, krok přeskoč nahlas.

Po projití všech problémů zobraz:

## Hotovo

- ⚡ Opraveno rovnou (mechanické i jednoznačné): N problémů
- ✅ Opraveno po odsouhlasení: N problémů
- 🪄 Vyřešeno automaticky (následek root opravy): N problémů
- 📌 Odloženo: N problémů
- ⏭️ Přeskočeno (zapsáno do CLAUDE.md → Consistency): N problémů

[Pokud jsou odložené: seznam odložených s jejich popisy]

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

Byla-li některá oprava rozsáhlá – přibyl nový blok textu, přepsala se celá sekce, změnilo se víc souborů naráz –, řekni uživateli, že se vyplatí pustit audit znovu. Čerstvě napsaný text má vad nejvíc. Opakované průchody nad ~/.claude ukázaly, že většina nálezů každého kola vznikla opravami z kola předchozího: druhý průchod 7 z 8, třetí 8 z 10. Po drobných opravách to naopak smysl nemá – další běh by hledal hlavně sám sebe. Doklad a čísla jsou v ~/Context/decisions.md, Čtyři průchody /consistency za sebou a co z toho plyne.

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

• Projekt je konzistentní, všechny nálezy jsou vypořádané.
• Konzistentní zatím 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 – zápis toho, co se v běhu domluvilo; zbytek mezery a krok osy za ní drží ~/.claude/standards/lifecycle.md, Co smí stát v které mezeře
• /merge – je-li práce na větvi hotová; zápis toho, co se v běhu domluvilo, pustí sám
• byla-li některá oprava rozsáhlá, /end, pak /clear, a audit znovu až v nové session, protože tahle už opravovala a na vlastní opravy je zaujatá