--- name: oponent description: Skill se použije, když uživatel zadá "/oponent", nebo chce nezávislý oponentský posudek na dokument, který spolu psali – strategii, pozicování, PRD, koncepci, cenotvorbu, datový model, analytickou dokumentaci. Pohled čerstvýma očima z několika hledisek: co nedává smysl, co si odporuje, co nebude fungovat, co chybí. argument-hint: [dokument] allowed-tools: [Read, Write, Edit, Glob, Grep, Bash, Agent, AskUserQuestion, WebSearch, WebFetch] --- # Oponent ## Co skill dělá Uživatel má hotový nebo rozpracovaný dokument, na kterém jste spolu dlouho pracovali. Právě proto na něj **nemáš nezávislý pohled** – spoluautor nevidí, co v dokumentu chybí, protože to má v hlavě, a nevidí, co je slabé, protože si to sám odsouhlasil. Skill proto pošle na dokument **subagenty bez kontextu téhle session**, každého z jiného hlediska, a jejich nálezy s uživatelem probere jeden po druhém. V *Životním cyklu projektu* (`~/.claude/standards/rules.md`) je to kontrolní krok, ne bod na ose: **stojí ve třech mezerách** – za `/discovery`, za `/specify` a za `/architect`. Do životního cyklu patří proto, že jinak návrh neměří nikdo – `/review` ověřuje kód proti specifikaci, ale samotnou specifikaci nikdo proti ničemu, takže vada v ní projde celým životním cyklem jako korektní. Přeskakuje se stejným pravidlem jako každý jiný krok: drobná změna uvnitř navrženého systému posudek nepotřebuje, nový systém nebo nový podsystém ano – a přeskočení se řekne nahlas i s důvodem. ## Co skill nedělá - **Není to kontrola kódu.** Na kód je `/review`. - **Není to kontrola proti předpisu.** Žádné měřítko v souboru nemá a nález obhajuje argumentem; soulad se specifikací a s doménovými znalostmi v `~/Context/*` měří `/review`, jehož nález se vyvrací ukázáním na pravidlo. Proto oponentura funguje i tam, kde `/review` nemá proti čemu měřit (`~/.claude/standards/lifecycle.md`, *Co smí stát v které mezeře*). - **Není to audit vnitřní konzistence projektu.** Na to je `/consistency`. Oponent se ptá „je to dobře vymyšlené?“, ne „sedí to na sebe?“. - **Nic sám nemění.** Výchozí režim je diskuze. Změny až po schválení jednotlivých nálezů. - **Nepíše zadání, návrh ani plán.** Sám nenavrhuje – jen posuzuje hotový dokument, ať ho napsal `/discovery`, `/specify`, nebo `/architect` –, a rozpad na úkoly nechává `/breakdown`. - **Nevytěžuje session.** Že je všechno dohodnuté zapsané v souborech, hlídá `/end`. - **Nechválí.** Věci, které jsou v pořádku, se nevypisují. ## Fáze 0 – Co se oponuje **Tenhle skill neběží nad kódem projektu, takže body 1 až 3 z `~/.claude/skills/preflight.md` nahrazuje vlastními předpoklady níž** – posuzuje dokument, který může ležet i mimo projekt. Body 4 a 5 odpadají ze stejného důvodu: nic nespouští a nesahá na diff větve. Načti si ho přesto; platí z něj závěr o shrnutí zjištěného, než se cokoliv stane. **Předmět posudku.** Uživatel ho může zadat jako argument (`/oponent docs/requirements.md`, `/oponent 01 až 04`, `/oponent pozicování`). Když ho nezadá, **nabídni mu, co jsi našel** – projdi projekt, vypiš kandidáty (dokumenty, na kterých se v poslední době pracovalo) a nech ho vybrat přes `AskUserQuestion`. **Nejdřív se podívej, jestli neexistuje `.claude/run/oponent.json`** – přerušený běh. Vzniká na konci Fáze 4; nabídni navázání dřív, než začneš cokoliv počítat znovu – podle zápisu z `/break`, nese-li soubor klíč `interrupted`, jinak z něj (`~/.claude/skills/skills.md`, *Běhový stav*). **Pak zjisti, jestli nad tímhle předmětem oponentura už neběžela** – `docs/done.md`, sekce `## Průchody životním cyklem`. Najdeš-li záznam, přečti z něj panel hledisek a počty nálezů: Fáze 1 z toho vyjde při volbě hledisek a Fáze 6 podle toho pozná, jestli smí srovnávat počty. Porovnej i hash s aktuálním – `git log --oneline ..HEAD` ukáže, co se od té doby změnilo. **Zkontroluj, že to má smysl oponovat:** - **Je to kód?** → přesměruj na `/review` a zastav se. - **Je to rozpracované torzo?** → zeptej se, jestli má smysl oponovat teď, nebo počkat. Posudek na kostru vygeneruje hlavně nálezy „chybí obsah“, což uživatel ví. - **Je toho moc?** Nad zhruba 5 dokumentů nebo řádově stovky kB se posudek rozmělní. Zeptej se, co je jádro, a oponuj to. **Načti kontext, který posudek potřebuje:** projektový `CLAUDE.md`, `docs/rules.md` (principy, proti kterým se v projektu rozhoduje) a `docs/decisions.md` (co už bylo rozhodnuto a proč). Bez toho subagenti navrhnou znovu to, co už bylo vědomě zamítnuto – a to je nejotravnější druh oponentury. **Na soubory ale nespoléhej.** Oponentura se často pouští hned po `/specify` nebo `/architect`, tedy v téže mezeře, ve které se o věci teprve rozhodlo – kdežto rozhodnutí z rozhovoru zapisuje `/end` až na konci session. `decisions.md` je v tu chvíli skoro prázdný, ačkoliv se v téhle session vědomě zamítla spousta věcí. **Projdi proto session a to, co jste zavrhli, vypiš do zadání oponentů** jako samostatný blok *Vědomě zamítnuté* – i s důvodem, ne jen výčtem. Bez toho první běh předloží nálezy, které umíš vyvrátit z hlavy, a druhý už nespustíš. **Nemá-li projekt `docs/`** (konfigurační repozitář, samostatný dokument mimo projekt, text v knowledge base), řekni to nahlas a veď posudek bez nich: kontextem je pak projektový `CLAUDE.md` a příslušná doména v `~/Context/`, a přijatá i zamítnutá rozhodnutí jdou tam, kam patří v tom projektu – ne do založeného `docs/`. ------ ## Fáze 1 – Volba hledisek **Nepouštěj stejné kritiky.** Redundantní subagenti najdou tolikrát totéž, kolik jich pustíš. Diverzita hledisek chytá selhání, která opakování nechytí. Vyber **čtyři až pět hledisek** z katalogu níž podle sloupce *Spouštěč*. Je to **vlastnost dokumentu, ne jeho typ** – „PRD“ nebo „cenotvorba“ by propustily skoro celý katalog a filtr by nefiltroval; „slibuje výsledek“ nebo „sbírají se údaje o lidech“ se dá ověřit v textu, který máš před sebou. Výběr **předlož uživateli přes `AskUserQuestion`** předtím, než kohokoliv pustíš – volby *Pustit tak, jak je* / *Vyměnit jedno hledisko* / *Vybrat panel znovu*. **Na odpověď se čeká**, do té doby žádný subagent neběží. Prostý výpis nestačí: další odstavec velí pustit panel jedním voláním, takže by se uživatel k výměně dostal až ve chvíli, kdy 4 agenti na `xhigh` už pracují (`~/.claude/standards/rules.md`, *Ptej se postupně*). **Vlastní hledisko** si vymysli, jen když **žádný z katalogu nepokrývá** to, co je na dokumentu specifické. Pak ale: napiš, které katalogové hledisko bylo nejbližší a čím se od něj tvoje liší; napiš mu **otázky ve stejném tvaru jako v katalogu** (bez nich dorazí k subagentovi holý název a ten pak najde cokoliv); zařaď ho mezi metody, nebo domény. Osvědčí-li se, **navrhni ho doplnit do katalogu** – jinak se poznatek ztratí a příště se vymýšlí znovu a jinak. Před přidáním ale **porovnej jeho otázky se sloupcem *Ptá se* u všech stávajících hledisek**: sdílí-li s některým víc než jednu otázku, do katalogu nepatří jako nový řádek, ale jako zúžení nebo doplněk toho stávajícího (`~/.claude/standards/rules.md`, *Detekce konfliktů před přidáním*). Katalog roste snadno a nic ho samo nezmenšuje. Hledisko, které jde formulovat jako zúžení existujícího na doménu (*Právo → GDPR a consent*), vlastní hledisko není. Sloupec *Web* říká, které hledisko dostane ve Fázi 2 svolení hledat zvenku; ostatním se to zakazuje, ať neutíkají od dokumentu. **Metody – jak se dívat.** Dají se přiložit na jakýkoliv dokument; samy o sobě ale nemají věcnou oporu, proto se metodickému hledisku v zadání vždy určí doména, na kterou se má obořit (*Hraniční případy cenového modelu*, *Pre-mortem uvedení kurzu*). | Hledisko | Ptá se | Spouštěč | Web | Typ | |---|---|---|---|---| | **Vnitřní rozpor** | Tvrdí dokument někde něco, co jinde popírá? Sedí čísla, výčty a souhrny s obsahem? Nezůstal tam zbytek po zrušeném konceptu? | dokument vznikal po částech nebo prošel revizemi – je kde nechat zbytek po zrušeném konceptu | | `reader` | | **Co chybí** | Ne co je špatně, ale co v dokumentu vůbec není a co na jeho okrajích nemá odpověď. **(1)** Vypiš hlavní entity, kroky a pravidla dokumentu a u každého se zeptej, co když nenastane vůbec, nastane víckrát, jen zčásti, spolu s něčím dalším, obráceně, nebo místo něj něco jiného – souběh dvou slev, přechod na vyšší tarif v půlce období, dvojí nárok téhož zákazníka, zrušení uprostřed. Platí to pro pravidlo obchodní a procesní stejně jako pro vstup programu. **(2)** Hlaš jen to, bez čeho podle dokumentu nejde jednat ani rozhodnout: nepojmenovaný vlastník, chybějící kritérium, scénář bez odpovědi. Neptej se na chování kódu, ale na to, jestli dokument na ten případ dává odpověď – a jestli dává jen jednu. Nevypisuj chybějící kapitoly a sekce. | vždy – povinný | | `reader` | | **Předpoklady a argumentace** | Plyne závěr z toho, co mu předchází? Vypiš předpoklady, na kterých dokument mlčky stojí a nikde je nepojmenovává – co musí platit, aby závěr platil? U každého: jak se pozná, že neplatí, a co z dokumentu padá s ním. Je tvrzení podané jako fakt doopravdy fakt? Nesahej na čísla, právo, data ani technologii – ty mají vlastní hlediska. | dokument něco tvrdí o světě, o lidech nebo o budoucnosti a opírá o to závěr; a jako záložní volba, když nesedí žádná doména | | `reader` | | **Pre-mortem** | Je za osmnáct měsíců a tohle prokazatelně selhalo. Napiš, co se stalo – konkrétní sled událostí, ne obavu. Který předpoklad padl první? Jako jediné hledisko smíš skládat příběh napříč doménami: nález, který leží na rozhraní dvou jiných hledisek, jinak nemá majitele. | z dokumentu se bude něco realizovat a stojí to na jednom hlavním scénáři | | `reader` | | **Alternativy a řez** | Splnil by týž cíl jednodušší nebo úplně jiný postup? Které varianty autor zvažoval a proč je zamítl – je to zdůvodnění v dokumentu, nebo jen v jeho hlavě? Co se stane, když se nezmění nic? Která část jde vyškrtnout, aniž zbytek přestane dávat smysl? | dokument navrhuje řešení a nejmenuje varianty, které autor zvažoval a zavrhl | | `reader` | | **Cíl a měřitelnost** | Je napsané, čeho to má dosáhnout? Podle čeho se za rok pozná, že to vyšlo, a podle čeho, že ne? Má cíl číslo, práh a termín, nebo je to jen obecné tvrzení? Co je vědomě mimo rozsah – a je to napsané, nebo se to jen předpokládá? | dokument si klade cíl nebo slibuje výsledek | | `reader` | | **Zneužití** | Kdo má motiv to obejít – uživatel, konkurent, robot, insider? Co se dá vytěžit z mezery mezi tím, co dokument slibuje, a tím, co vymáhá? Co jde přečíst, změnit nebo získat zadarmo, aniž na to má někdo nárok? Kde dokument předpokládá, že se aktér chová slušně? | jsou ve hře peníze, osobní údaje, přihlašování nebo cizí vstup | | `reader` | | **Reverzibilita** | Které rozhodnutí jde vzít zpátky a které ne? Co stojí návrat – v penězích, v datech, v důvěře? Ví dokument sám o sobě, že je někde jednosměrný? Existuje varianta, která tutéž věc otestuje vratně? | zakládá schéma, jméno, závazek nebo veřejný slib – něco, co se pak těžko bere zpět | | `reader` | | **Čtenář bez kontextu** | Přečti dokument jako člověk, který u jeho vzniku nebyl. Který termín není nikde definovaný nebo mění význam? Které rozhodnutí je zapsané bez důvodu, takže ho nikdo netroufne změnit? Kde by dva čtenáři odešli s jiným zadáním? Na co dokument odkazuje, aniž to jmenuje? | dokument bude někdo vykonávat bez autorů – člověk i agent | | `reader` | **Domény – na co se dívat.** Nesou znalost oboru, ale bez metody sbírají povrch. | Hledisko | Ptá se | Spouštěč | Web | Typ | |---|---|---|---|---| | **Ekonomika provozu** | Sedí čísla? Break-even, cena, marže, kapacita, náklady na provoz. Kdo to bude reálně dělat, jak často a co se stane, když to neudělá? Co vyžaduje ruční zásah? Co se rozbije při desetinásobku a co při desetině? | jsou v něm čísla, ceny, kapacity nebo opakovaná ruční práce | ✔ | `Explore` | | **Osobní údaje a souhlas** | Co se sbírá, na jakém právním základu a jak dlouho se to drží? Co dokument slibuje uživateli a co ve skutečnosti dělá? Jde výmaz provést, aniž se rozpadne zbytek? | sbírají se údaje o lidech | ✔ | `researcher` | | **Závazky vůči druhé straně** | Spotřebitelské právo, smluvní závazky, daně, autorská práva. Co je napsané tak, že to nejde dodržet? Co slibuje víc, než na co má autor nárok nebo kapacitu? | dokument něco slibuje protistraně – zákazníkovi, klientovi, dodavateli | ✔ | `researcher` | | **Data a proveditelnost** | Dá se to postavit tak, jak je to popsané? Co je klíč záznamu a co se stane, když se změní? Kde je pro každý údaj zdroj pravdy a kdo ho smí přepsat? Co se děje s duplicitou, s historií a se smazáním? Jak se do nového modelu dostanou stará data a jak se z něj dá vycouvat? Kde je v tom skryté technické riziko – co dokument popisuje jako samozřejmé, a přitom to nikdo nepostavil? | popisuje záznamy a jejich klíče, nebo něco, co se má postavit | ✔ | `researcher` | | **Nepřítomní dotčení** | Koho ještě se to dotkne, i když v dokumentu není? Kdo to musí odsouhlasit a byl u zadání? Komu to přidá práci a kdo se tomu bude bránit – a proč právem? Kdo si po zavedení pohorší oproti dnešku? Kolik lidí to umí a co když ten jeden vypadne? | provedení závisí na někom, kdo u zadání nebyl, nebo se tím někomu mění zaběhnutý postup či cena | | `reader` | | **Závislosti a datum spotřeby** | Na čem cizím to stojí – služba, sazba, právní úprava, nástroj, jeden člověk? Co se stane, když to zdraží, změní podmínky nebo zmizí? Co v dokumentu má datum spotřeby a ví se o tom? Jak vypadá druhý rok provozu? | stojí to na cizí službě, ceníku, sazbě nebo předpisu | ✔ | `researcher` | | **Konkurence a trh** | Existuje to už? Čím se to liší? Proč by si zákazník vybral tohle, a ne cizí nabídku nebo to, co používá dneska? Obstojí ta odlišnost, když si ji ověří? (Jestli to má vůbec smysl dělat, řeší *Alternativy a řez* – tebe zajímá volba zákazníka, ne náklad příležitosti autora.) | něco se má prodávat nebo vymezovat vůči alternativám | ✔ | `researcher` | | **Cílová skupina** | Čte to očima persony, které se to týká – a ta nezná alternativy, zná jen tenhle text. Rozumí tomu? Věří tomu? Co ji odradí, co v tom nenajde, kde přestane číst? (Srovnání s tím, co nabízí někdo jiný, nech *Konkurenci a trhu* – ten na to má rešerši, ty ne.) | text má někoho oslovit, přesvědčit nebo mu něco vysvětlit | | `reader` | **Pravidla výběru:** - Hledisko *Co chybí* ber jako **povinný**, ať je dokument jakýkoliv. Druhé povinné hledisko schválně nemáme: dva pevné sloty ze čtyř by z volby podle povahy dokumentu udělaly ozdobu. - Vyber **aspoň jednu položku z každého bloku**. Samé domény dají audit a nula oponentur; samé metody obecné kritiky bez věcné opory. - **Hlediska nerozšiřuj, aby jich stačilo pustit míň.** Vypadá to lákavě – širší hledisko přece pokryje víc –, jenže kapacitu neurčuje šířka zadání, ale výstup agenta: ten vrátí 5 až 10 nálezů, ať má zadání úzké nebo široké. Rozšířením se počet nálezů nezvedne, jen se rozptýlí jejich původ, a přibude riziko hlediska, které „najde cokoliv“. Chybí-li ti pokrytí, přidej hledisko, nebo rozšiř jeho *Spouštěč* – nerozmazávej hledisko, které máš. - Metodické hledisko pouštěj **vždy s určenou doménou** – vypiš ji do jeho zadání. Metoda bez domény je slepá. - **Kolik jich pustit podle rozsahu předmětu:** čtyři u jednoho dokumentu zhruba do 15 kB, pět nad tím nebo když je dokumentů víc. Je-li předmět velký (blíží se hranici z Fáze 0), dělí se **hledisko × podmnožina dokumentů**, ne jen hledisko – jinak čte každý agent celý objem a dělba škáluje jen jedním směrem. - **Běžela-li už oponentura nad tímhle předmětem** (Fáze 0 to zjistila z `docs/done.md`), **začni jejím panelem**. Nález, který se vrátí ve stejném hlediska, znamená, že se neopravil; nález, který zmizel s vyměněným hlediskem, neznamená nic. Vyměnit hledisko smíš, ale řekni, který a proč – Fáze 6 pak počty nesrovnává. - **Sedí-li spouštěč na víc hledisek, než máš slotů**, ber ty, kde by chyba stála nejvíc – ne ty, kde se nález hledá nejsnáz. - **Volbu dolož.** U každého zvoleného hlediska napiš jednou větou, co konkrétně v dokumentu tě k němu vedlo, a jmenuj **jedno hledisko, které jsi vědomě nevzal, a proč**. Nevybrané hledisko totiž nevrátí nula nálezů, ale neexistenci – a ta neprojde žádným počítadlem ve Fázi 4 ani ve verdiktu. Volbu přitom dělá ten, kdo dokument spoluautorsky psal, takže je to jediné místo, kde má jeho slepota volnou ruku (`~/.claude/standards/rules.md`, *Zapiš i to, co vědomě nemáš*). ------ ## Fáze 2 – Nezávislé posudky **Nejdřív si vyrob inventuru předmětu, pak pouštěj oponenty.** Vypiš nadpisy posuzovaných dokumentů příkazem (`grep -n '^#' `) a **zapamatuj si jejich počet** – proti němu se v *Konsolidaci* vykazuje, kolik z předmětu který oponent doopravdy prošel. Neodhaduj to (`~/.claude/standards/rules.md`, *Hodnotu, kterou čte stroj, nepiš – nech ji vyrobit příkazem*). **Proč to tady je:** zadání oponentovi říká „přečti dokument celý“, ale nic to neměří – a posudek, který pokryl třetinu předmětu, vypadá stejně věrohodně jako úplný, protože nálezy v něm jsou pravé; chybí jen ty ostatní. Pusť subagenty **paralelně, jedním voláním s víc tool calls**. Každý dostane vlastní hledisko a **žádný kontext z téhle session** – to je celý smysl. **Typ agenta podle sloupce *Web*:** hledisko bez ✔ jede na `reader`, hledisko s ✔ na `researcher`. Oba posuzují hotový text a **nemají shell**, takže do dokumentu nemůžou zapsat; `researcher` má navíc `WebSearch` a `WebFetch`. Viz `~/.claude/skills/skills.md`, *Model, effort a delegace*. **Nejsilnější model, `xhigh`** (Volba modelu a effortu podle `~/.claude/standards/delegation.md`, *Model a effort podle úkolu*.) Oponentura je verifikace, ne sběr: slabý model námitku nevymyslí ani neobhájí, jen zdvořile přizvukuje tomu, co má před sebou – a posudek, který všechno schválí, je horší než žádný, protože dodá falešnou jistotu. Zadání pro každého (doplň hledisko, cesty a projektový kontext): ``` Jsi nezávislý oponent. Nemáš žádný kontext z předchozích rozhovorů – máš jen ty soubory, které si přečteš. Autor dokumentu tě neslyší, takže nemá smysl být ohleduplný. DOKUMENT: KONTEXT PROJEKTU (přečti, ale neoponuj to): VĚDOMĚ ZAMÍTNUTÉ V TÉHLE PRÁCI (nenavrhuj znovu bez nového argumentu): OBJEM, NA KTERÝ SE STAVÍ: TVOJE HLEDISKO: Přečti dokument celý a hledej výhradně ze svého hlediska. Ostatní hlediska pokrývají jiní oponenti – nepřebíhej k nim. ZAČNI ŘÁDKEM: `PROŠEL JSEM: ` – jmenovitě, ne „vše“. Nestihl-li jsi předmět celý, napiš jen to, co jsi přečetl. Neúplný posudek je platný výsledek, zamlčeně neúplný ne. Nenašel-li jsi nic, je to stejně platný výsledek jako nález – ten řádek ale napiš i tak: bez něj se prázdný posudek nedá odlišit od toho, že jsi spadl. U KAŽDÉHO NÁLEZU UVEĎ: - **Kde** – soubor a sekce, ideálně citace věty, které se to týká - **Co** – jednou větou, co je špatně - **Proč to vadí** – konkrétní důsledek, ne obecná obava. „Nebude to škálovat“ je nic; „při 20 000 účastnících vyjde ruční párování na 300 hodin práce“ je nález. - **Návrh** – dvě až tři konkrétní varianty řešení, ne jedna. Nemáš-li řešení, řekni to a označ nález jako otázku k rozhodnutí. - **Závažnost** – škálu drží `~/.claude/skills/severity.md` a je společná se všemi skilly, které hlásí nálezy, ať jdou porovnat napříč běhy. U oponentury se čte jako síla námitky: **KRITICKÉ** boří předpoklad, na kterém dokument stojí; **STŘEDNÍ** mění závěr nebo rozsah; **NÍZKÉ** zpřesňuje. PRAVIDLA: - Co je v pořádku, nepiš. Žádné shrnutí kladů, žádné „jinak je to dobře promyšlené“. - Nenavrhuj to, co je v docs/decisions.md nebo v bloku VĚDOMĚ ZAMÍTNUTÉ výš už zavržené. Přečti si obojí nejdřív. Výjimka: myslíš-li si, že to rozhodnutí bylo chybné, řekni to výslovně jako revizi rozhodnutí a zdůvodni, který jeho předpoklad neplatí. - Neopírej nález o neověřené tvrzení. Stojí-li na faktu, ověř ho. - Obrana i pojistka se staví úměrně pravděpodobnosti a škodě při objemu výš. Nenavrhuj strop, guard, hlídač, poplach ani kontrolu proti riziku, které je při tom objemu pod hranou rozlišitelnosti, a nehlídej stav, jehož následek se ukáže sám a viditelně. Proti zlovůli smluvní strany, kterou provozovatel osobně schvaluje, technickou obranu nenavrhuj (převzatý účet té strany je jiná hrozba). Co jedním selháním zasáhne všechny tenanty, peníze třetí strany, data nebo zákonnou lhůtu, hlas vždy. - Nešetři kritikou. Ale kritizuj dokument, ne autora. - Nenavrhuj přeformulování textu kvůli stylu – od toho tu nejsi. Do žádného souboru nezapisuj. ``` **Volitelně rešerše.** Hledisku, které má v katalogu ve sloupci *Web* ✔, dej výslovné svolení hledat na webu. U ostatních to zakaž, ať neutíkají od dokumentu. **Sloupec *Typ* nekopíruje sloupec *Web*.** *Ekonomika provozu* má web i `Explore`, protože po ní zadání chce **přepočítat** break-even, marži a kapacitu – a agent, který má počítat a nemá čím, si číslo domyslí (`~/.claude/skills/skills.md`, *Model, effort a delegace*, pravidlo o hraničním případu). U zbylých hledisek s ✔ je web zdroj faktu, ne kalkulačka, takže jim stačí `researcher`. ------ ## Fáze 3 – Ověření nálezů **Nálezy z panelu nejsou závěry, ale tvrzení.** Oponent bez kontextu vyrobí i nález, který stojí na tom, co nemohl vědět – a nález, který nevyrobí nic, vypadá jako selhání běhu, takže tlak na produkci je vestavěný. Kdyby se falešné vyřazovaly až v konsolidaci, dělal by to spoluautor, tedy ten jediný aktér, jehož slepotu má celý skill obcházet. To je přesně ten tichý filtr, který si Fáze 4 zakazuje – jenže bez téhle fáze nemá čím ho nahradit. **Deduplikuj ještě před ověřením**, ne až po něm: tři ověřovatelé na jednu věc jsou trojnásobná cena za tutéž odpověď. **Dva nálezy jsou tentýž**, když míří na totéž místo dokumentu a navrhují změnit touž věc – formulace i závažnost se lišit můžou. Sloučený nález si ponech v obou zněních a poznamenej, které hlediska ho našly; Fáze 4 s tím dál pracuje jako se signálem závažnosti. Na každý nález se závažností **KRITICKÉ a STŘEDNÍ** pošli **samostatného ověřovatele** – paralelně, v čerstvém kontextu, který nevidí ani panel, ani tvou konverzaci. Jeho doklad je citace, ne výstup příkazu, takže shell nepotřebuje a nemá ho mít. **Typ ověřovatele podle toho, na čem nález stojí:** přišel-li z hlediska s ✔ ve sloupci *Web*, nebo opírá-li se o vnější zdroj (URL, dokumentace dodavatele, ceník, předpis), jede na `researcher`; jinak na `reader`. Nález o cizí platformě by `reader` bez webu vrátil jako NEOVĚŘITELNÉ, a ověření by tak mlčky odpadlo právě u tvrzení, která autor dokumentu sám ověřit nejde. Oba typy nemají shell a nezapisují, takže záruka, že ověřovatel do dokumentu nesáhne, platí u obou. **Nejsilnější model, `xhigh`**, i u nálezu z levného hlediska: slabý ověřovatel nález nepotvrdí ani nevyvrátí, jen přizvukuje tomu, co má před sebou, a z ověření se stane razítko. **Strop na počet ověřovatelů: nejvýš 12 na běh.** Bez něj roste nejdražší část běhu lineárně s počtem nálezů a panel pěti hledisek vrátí klidně 30 nálezů, tedy třicet agentů na nejsilnějším modelu. Přes strop se ověřují **nejdřív všechny KRITICKÉ**, teprve pak STŘEDNÍ; co se nevejde, jde do Fáze 5 označené jako **`neověřeno`** a spočítá se v souhrnu. Tiché vynechání ne – neověřený nález se od ověřeného musí poznat. **Ověřovatel má tentýž kontext jako oponenti** – to není jeho výhoda a nedělej z toho výhodu. Rozdíl je jinde: ověřovatel **nemá zadané hledisko**, a tím pádem ani tlak vrátit nález. Oponent, který ze svého hlediska nic nenajde, vypadá jako selhání běhu; ověřovatel, který nález vyvrátí, odvedl práci. Ta asymetrie je celý mechanismus, ne přístup k souborům. ``` Ověřuješ jedno tvrzení nezávislého oponenta. Nemáš kontext z předchozích rozhovorů. DOKUMENT: KONTEXT PROJEKTU: VĚDOMĚ ZAMÍTNUTÉ V TÉHLE PRÁCI: NÁLEZ K OVĚŘENÍ: Tvůj úkol není nález potvrdit, ale pokusit se ho vyvrátit. Ptej se: - Stojí na tom, co v dokumentu doopravdy je? Ověř citaci. - Opírá-li se o vnější zdroj, říká ten zdroj opravdu, co nález tvrdí? Otevři ho, nehádej. - Neřeší to dokument někde jinde, kde se oponent nedíval? - Neplyne z kontextu projektu, že to tak je schválně? - Je důsledek doložený, nebo je to obecná obava? („Nebude to škálovat“ je nic.) - Sedí navržená závažnost, nebo je nafouknutá? Vrať: POTVRZENO / VYVRÁCENO / PŘEKVALIFIKOVÁNO NA / NEOVĚŘITELNÉ, jednou větou proč, a u vyvráceného doklad – citaci z dokumentu nebo kontextu, která ho boří. NEOVĚŘITELNÉ vrať, stojí-li nález na faktu, který v dokumentu ani kontextu není, a napiš, co chybí – je to stejně platná odpověď jako vyvrácení. Do žádného souboru nezapisuj. ``` **NEOVĚŘITELNÉ jde do Fáze 5 jako `neověřeno`**, stejně jako nález nad stropem – nezahazuje se ani nepotvrzuje. **Výsledky ověření hlas obsahem, ne značkou.** Identifikátory, pod kterými se nálezy vracejí od oponentů a ověřovatelů, jsou interní – uživatel je nikdy neviděl a „N1 je širší, než oponent hlásil“ mu neřekne nic. Pojmenuj, čeho se to týká (`~/.claude/standards/rules.md`, *Interní značky ven nepatří*). Čísla z přehledu v kroku 5 níž jsou naopak v pořádku – ta uživatel viděl i s obsahem. **NÍZKÉ nálezy se neověřují** – ne proto, že by ověření bylo drahé (stojí strojový čas), ale proto, že se ani nevypořádávají jednotlivě: jdou ve Fázi 5 jedním blokem, takže na nich nestojí žádné rozhodnutí, které by ověření chránilo. **Vyvrácené zahoď a spočítej je do souhrnu**; kolik jich bylo, se říká nahlas, ne potichu. ------ ## Fáze 4 – Konsolidace Než cokoliv předložíš, nálezy **zpracuj**: **Nejdřív pokrytí, teprve pak nálezy.** U každého oponenta si z jeho úvodního řádku vezmi, které sekce prošel, a porovnej s inventurou. **Posudek bez toho řádku není čistý výsledek, ale selhání běhu** – pusť ho znovu, a nepovede-li se to podruhé, řekni nahlas, že jeho pokrytí není doložené. Hledisko, které prošlo výrazně méně než ostatní, **uveď v přehledu jmenovitě**: jeho mlčení nic netvrdí. Pak nálezy: 1. **Duplicity už jsou sloučené** – dedup proběhl před ověřením (Fáze 3). Zůstává jen poznamenat u nálezu, že ho našli dva oponenti z různých hledisek; je to signál závažnosti. 2. **Vyvrácené nálezy vyřadil ověřovatel**, ne ty. Sám nefiltruj: nález, u kterého máš pochybnost, ale ověřením prošel, předlož s poznámkou. Tichý filtr je přesně to, co má tenhle skill obcházet, a spoluautor je ten poslední, kdo ho má dělat. 3. **Vyřaď už rozhodnuté.** Nález, který navrhuje zamítnutou variantu bez nového argumentu, zahoď a **řekni, kolik jsi jich zahodil a proč** – ne potichu. 4. **Seřaď podle závažnosti**, ne podle pořadí v dokumentu. 5. **Vypiš přehled** – všechny nálezy jednou větou, očíslované, se závažností. Uživatel musí vidět, co ho čeká, než se ho začneš ptát. **Přehledem ale odpověď nekonči** – první otázka Fáze 5 jde v téže odpovědi (`~/.claude/skills/findings.md`, *Ohlášená akce patří do téže odpovědi*). ### Ověřený seznam zapiš na disk, než půjdeš dál Hotovou frontu ulož do **`.claude/run/oponent.json`** (`~/.claude/skills/skills.md`, *Běhový stav*; adresář patří do `.gitignore`). Formát: `{"created": "", "subject": [...], "perspectives": [...], "findings": [{...nález..., "verified": true/false, "status": "open"}]}`. **Proč to není zdržení:** tenhle seznam je nejdražší artefakt celého běhu – stojí panel i ověřovatele na nejsilnějším modelu. Fáze 5 s ním pak dlouze interaguje **v hlavní session**, tedy přesně tam, kde kontext dochází nejrychleji, protože do něj předtím natekly výstupy všech agentů. Bez zápisu znamená kompaktace uprostřed průchodu, že se celý běh platí znovu. **Na startu skillu** (Fáze 0) se proto podívej, jestli `.claude/run/oponent.json` už neexistuje. Existuje-li, **nabídni navázání** místo nového běhu – a řekni, kolik nálezů v něm zbývá nevypořádaných. Odkud se navazuje, rozhoduje klíč `interrupted` (`~/.claude/skills/skills.md`, *Běhový stav*). Změnil-li se od té doby oponovaný dokument, řekni to a zeptej se: část nálezů může být neaktuální. **Průběžně do něj zapisuj stav** každého nálezu (`accepted`, `rejected`, `deferred`, `open`), jak jimi procházíš. Po dokončení Fáze 6 soubor smaž. Panel je v tom souboru jen po dobu běhu; **trvale přežije v řádku, který Fáze 6 zapisuje do `docs/done.md`** – z něj vychází příští oponentura při volbě hledisek. ------ ## Fáze 5 – Průchod nálezy **Průchod jde po kolech** – nejdřív všechny otázky, odpovědi do `## Rozhodnuto k zapracování`, pak zapracování bez uživatele, a co se při něm ukáže sporné, otevře další kolo (`~/.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ží `/break` tak, aby z něj nová session rozhodla bez tvého kontextu. Podle `~/.claude/standards/rules.md` (*Ptej se postupně, ne všechno najednou*) projdi nálezy **jeden po druhém**, od nejzávažnějšího. **Jednotlivě jen KRITICKÉ a STŘEDNÍ** – nízké jdou nakonec jedním blokem (viz níž). **NÍZKÉ nálezy neprocházej po jednom.** Na konci ptaní je schval hromadně podle doporučení z přehledu – otázku a co do ní nepatří drží `~/.claude/skills/findings.md`, *Průchod jde po kolech*. Dialog na každý z nich zvlášť stojí to nejdražší v celém běhu – tvoje rozhodnutí – a kupuje za něj zpřesnění. Neprošly navíc ověřením (Fáze 3), takže by se za ně platilo rozhodování bez protistrany. (Bez ověření jdou dál i nálezy nad stropem – ty se ale procházejí jednotlivě, protože jsou závažné; jen se u nich řekne, že ověřené nejsou.) U každého nejdřív vypiš: **Tvar výpisu drží `~/.claude/skills/findings.md`, *Jak nález vypadá*** – tučný název na samostatném řádku a pod ním souvislý text, žádná mřížka popisků. Ve větě řekni, **v čem je problém a jaký má důsledek**, a odkud to je (soubor, sekce, citace). Za titulní název připoj `· `, případně „2 oponenti nezávisle“ – čtenář tím pozná, odkud námitka přišla. Pak se zeptej **přes `AskUserQuestion`** – jedno volání na jeden nález. Volby jsou **konkrétní varianty řešení**, ne „Opravit / Odložit / Přeskočit“: u oponentského nálezu existuje víc věcných cest a „opravit“ neříká kterou. Jejich počet, `header`, pojmenování obou záchytných voleb i to, který stav která znamená, drží `~/.claude/skills/findings.md`, *Dvě záchytné volby a co znamenají* – **tvar otázky platí pro celou rodinu kontrolních skillů**. **Kontext piš do odpovědi, ne do myšlení:** text, který má uživatel číst – titulní řádek, kontext, varianty, doporučení –, v myšlení neformuluj; tam jen rozhodni, co řekneš, a větu napiš až v odpovědi. Hotový odstavec v myšlení uživatel nevidí – dostane místo něj jednořádkový souhrn a otázku bez kontextu (`~/.claude/standards/rules.md`, *Ptej se postupně*). **Věcná varianta znamená stav Přijato**; oba záchytné stavy překládá tabulka v `findings.md`. **Zpracování odpovědi:** - **Přijato** → zapiš do `## Rozhodnuto k zapracování`; v zapracování ho zapracuj do dokumentu a zapiš rozhodnutí do `docs/decisions.md`. - **Zamítnuto** → zapiš do `docs/decisions.md` i s důvodem, a dotýká-li se důvod návrhu, i do dokumentu, kterého se týká. **Do `## Review` v `CLAUDE.md` ne** – zamítnutý oponentský nález je produktové rozhodnutí, ne umlčená vada kódu (`~/.claude/skills/findings.md`, *Dvě záchytné volby a co znamenají*). Zamítnutý nález je cenný záznam – brání tomu, aby ho příští oponentura našla znovu jako nový. - **Odloženo** → do `docs/todo.md`, ve tvaru podle `~/.claude/standards/rules.md`, *Odložené věci pojmenuj a zaparkuj*. **Odbočky.** Uživatel u nálezu často rozvine úvahu, která zasáhne jinam. Tu úvahu zapiš celou – bývá cennější než původní nález. Pak se vrať k seznamu a pokračuj; sám si hlídej, které nálezy zbývají. ------ ## Fáze 6 – Závěr **Opakované spuštění.** Skill je určený k opakování nad revidovanou verzí. Když ho uživatel spustí znovu: - **Nález, který se vrátil**, znamená, že se neopravil, jen přeformuloval. Řekni to výslovně. - **Míň nálezů** znamená, že se to lepší, a **víc**, že revize otevřela nové problémy – ale jen tehdy, **běžel-li stejný panel hledisek**. Zjistíš to ze záznamu předchozího běhu (viz níž); nenajdeš-li ho, počty nesrovnávej a řekni místo toho, které hlediska běžely teď. Ve verdiktu: ``` ## Oponentura hotová - **Předmět:** - **Hlediska:** - **Panel:** A oponentů → B nálezů hrubě → C po dedupu → D ověřeno, E neověřeno - **Pokrytí předmětu:** N z M sekcí [· hledisko s nejmenším pokrytím a kolik prošlo] - **Spotřeba:** [N agentů: X oponentů, Y ověřovatelů · na jakém modelu a effortu] **Nálezy:** N celkem – 🔴 X kritických, 🟡 Y středních, 🔵 Z nízkých - Zapracováno: N - Zamítnuto: N (zapsáno do decisions.md i s důvodem) - Odloženo: N (todo.md) - Vyvráceno při ověření: N (nezobrazeno) - Neověřeno kvůli stropu: N - Vyřazeno před předložením: N () **Nejzávažnější, co z toho vzešlo** - ``` Vypisuj to jako **Markdown, ne jako blok kódu**, a řádky nezalamuj natvrdo – `~/.claude/standards/rules.md`, *Styl odpovědí*. Nakonec **zapiš průchod do `docs/done.md`, sekce `## Průchody životním cyklem`** (`~/.claude/skills/passes.md`) a **smaž `.claude/run/oponent.json`**: ``` - **YYYY-MM-DD** · `/oponent` · `` · · hlediska: · N nálezů (X zapracováno, Y zamítnuto, Z odloženo) ``` Datum vyrob `date +%F`, hash `git rev-parse --short HEAD` – obojí příkazem (`~/.claude/standards/rules.md`, *Hodnotu, kterou čte stroj, nepiš – nech ji vyrobit příkazem*). **Ten řádek je jediné, co z běhu přežije**: bez seznamu hledisek neví příští oponentura, s čím se má srovnávat, a bez hashe nepozná, jestli se předmět od té doby vůbec změnil. Nemá-li projekt `done.md` (viz Fáze 0, režim bez `docs/`), řekni nahlas, že se záznam nezapsal a srovnání s příštím během nebude možné. Zakonči jednou z těchto vět: - `Všechny nálezy jsou vypořádané, dokument je po oponentuře.` - `Vypořádané nejsou: .` Nikdy nekonči tím, že je dokument „v dobrém stavu“ – to není verdikt oponenta, ale autora. **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: - krok, který posuzovaný dokument vyrobil, zbyla-li v něm práce – oprava patří jemu, ne oponentuře - je-li vypořádáno, krok osy, který na ten dokument čeká