consistency git:20261013.62e898bA

Immutable. This exact content never changes and is served at /api/v1/blob/7522616d41b253a2.

---
name: consistency
description: Skill se použije, když uživatel zadá "/consistency", "/consistency branch" nebo "/consistency full", nebo chce audit projektu – konzistence pojmenování, patternů, typů, konfigurace a dokumentace. Co má jedinou zjevnou opravu, opraví rovnou; ptá se jen tam, kde je z čeho vybírat.
argument-hint: [branch|full]
allowed-tools: [Read, Write, Edit, Glob, Grep, Bash, Agent, AskUserQuestion]
---

# 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`, který běží až po tomhle.
- **Nemění chování.** Nálezy, které by ho změnily, jsou vždy sporné a jdou přes uživatele.
- **Neopakuje, co udělal `/review`.** Typecheck, linter, testy, audit závislostí ani scan tajemství se **před auditem nespouští** – proběhly o krok dřív a od té doby se nic nezměnilo. **Po každé vlastní opravě ano** (Fáze 4 a 5): tou se stav změnil, takže doklad od `/review` už neplatí. Tenhle skill dorovnává jen ten konzistenční zbytek, který předchozí 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é předchozí 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 je krok uzavírání, tedy běží **po každé feature**, 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 uzavření 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 po každé feature. 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 odpadá, průběžnou kontrolu pustil `/review` o krok dřív a tenhle skill na kód nesahá, dokud neprojde nález s uživatelem.

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é předchozí kroky životního cyklu nedělají

**Typecheck ani linter tady před auditem nespouštěj.** Pustil je `/review` o krok dřív a po každé své opravě je pustil znovu, takže stav, se kterým sem přicházíš, byl naposledy ověřený jím – opakovat je 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*:

| Co | Čím | Kdy má smysl |
|---|---|---|
| mrtvý kód, nepoužité exporty, soubory a závislosti | `knip`, jinak `ts-prune` + `depcheck` | projekt má `package.json` |
| env proměnné proti `.env.example`, oběma směry | grep na `process.env` / `getenv` proti ukázce | projekt má `.env.example` |
| překladové klíče proti slovníku, oběma směry | `i18next-parser`, jinak grep | projekt má překlady |
| shoda verze runtime napříč `engines`, `.nvmrc`, `.tool-versions`, CI a hostingem | porovnání hodnot | projekt některé z nich má |
| `TODO`/`FIXME` starší než půl roku a prošlé deadliny v komentářích | `git blame` nad nalezenými řádky | vždy, kde je git |
| mrtvé odkazy na soubory a kotvy na neexistující nadpisy v Markdownu | `python3 ~/.claude/skills/links.py <soubory v rozsahu>` | projekt má Markdown, tedy skoro vždy |

**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é předchozí 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.
- 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.
```

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 Fází 4 a za ní první otázkou Fáze 5 – `~/.claude/skills/findings.md`, *Ohlášená akce patří do téže odpovědi*. Věta „pouštím se do oprav bez ptaní“ místo oprav samotných je přesně ta chyba, kterou to pravidlo zakazuje.

## Fáze 4 – Opravy bez ptaní

Mechanické **i jednoznačné** nálezy (viz Fáze 2) oprav **rovnou, bez ptaní**. Pak:

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, **zastav se**, ukaž chybu a diff a zeptej se, jak pokračovat.
2. 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ď mezi sporné.

Pokud nejsou žádné sporné nálezy, přeskoč Fázi 5 rovnou na závěrečné shrnutí.

## Fáze 5 – Interaktivní průchod

**Přeruš včas, nabyl-li kontext.** Průchod dlouhou frontou je nejčastější místo, kde session narazí na strop okna a vynutí si kompaktaci v nejhorší možný okamžik – uprostřed nevypořádaného nálezu. Práh a tvar nabídky drží `~/.claude/skills/handoff.md`, *Přerušení dlouhého průchodu*; přijme-li uživatel přerušení, zbytek fronty uloží `/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*), zpracování odpovědí i pravidla pro hromadné opravy jsou v `~/.claude/skills/review/SKILL.md`, *Interaktivní průchod*. **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 po opravě.** Po každé odsouhlasené opravě 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; a byla-li práce na větvi, za ním `/merge`; zbytek mezery a krok osy za ní drží `~/.claude/standards/lifecycle.md`, *Co smí stát v které mezeře*
- 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á