--- 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. Mechanické opravy provede rovnou, sporné řeší interaktivně jeden po druhém. 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/RULES.md`) je to druhý krok uzavírání: navazuje na `/review` a předává na `/cleanup`. ## 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 standardy.** Na odchylky od předpisů v `~/Dev/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 standard. - **Neposuzuje, jestli je návrh dobrý.** Na to je `/oponent`. - **Nevytěžuje session.** Zápis dohod do souborů dělá `/cleanup`, 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. ## 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 ...HEAD # co se změnilo grep -rl "" . --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/skills/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/RULES.md`, *Model a effort podle úkolu*, pravidlo nula). Prahy a majitele drží `~/Dev/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 | **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; audit v dalších fázích běží stejně, jen bez 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/RULES.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**. Spusť subagenta typu `reader` s tímto zadáním (předej mu absolutní cestu k projektu, 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) a jejich nálezy dostáváš v zadání. **Nehledej je znovu** – hledej to, co nástroj změřit neumí. 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: ` – 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/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 pole objektů: [ { "severity": "KRITICKÉ" | "STŘEDNÍ" | "NÍZKÉ", "title": "krátký název problému", "description": "popis problému", "locations": ["soubor:řádek", ...], "suggested_fix": "konkrétní navrhované řešení", "tags": ["toolchain"?, "batch"?], "related_root": "title jiného problému, jehož je tento následkem (volitelné)" } ] ``` ## 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/RULES.md`, *Interní značky ven nepatří*.) 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í na mechanické a sporné **Kritérium je společné s `/review`** – plná definice obou skupin i s výčtem typických případů je v `~/.claude/skills/review/SKILL.md`, *Zpracování výsledků*. Neopisuj ji sem; drž se jí a přidej jen to, co platí navíc tady: - 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`), a `batch` nález je vždy sporný. ## 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 - **Mechanických** (jednoznačná bezriziková oprava): N – ty opravím rovnou a jen je vypíšu. - **Sporných:** M – ty projdeme spolu od nejzávažnějších, u každého navrhnu řešení a zeptám se. ``` Vypisuj to jako **Markdown, ne jako blok kódu**, a řádky nezalamuj natvrdo – `~/.claude/RULES.md`, *Styl odpovědí*. Pokud nebyly nalezeny žádné problémy, řekni to a skonči. ## Fáze 4 – Mechanické opravy Mechanické 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 `~/Dev/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 mechanický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/RULES.md`, *Styl odpovědí*. 3. Commit dle autocommit nastavení projektu. Mechanické opravy commituj **jedním commitem** dohromady, ne po jedné. 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 **Postup je společný s `/review`** – tvar výpisu nálezu, volání `AskUserQuestion` (jeden nález = jedna otázka, volby *Opravit / Odložit / Přeskočit*, u `batch` navíc *Rozbalit*), zpracování odpovědí i pravidla pro hromadné opravy jsou v `~/.claude/skills/review/SKILL.md`, *Interaktivní průchod*. Řiď se jím a lišíš se jen v těchhle bodech: **Kam se zapisuje „won't fix“.** 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** · `` · **: <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 <zapsaný hash>..HEAD -- <lokace>`; 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/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/STRUCTURE.md`, *`done.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> · 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é): 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] **Další krok:** /cleanup ``` Vypisuj to jako **Markdown, ne jako blok kódu**, a řádky nezalamuj natvrdo – `~/.claude/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 `~/Dev/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>.`