Ako zveriť review subagentovi a skontrolovať správu

Požiadavka "Skontroluj stránku" necháva na recenzentovi veľa rozhodnutí: hľadať chyby v správaní, hodnotiť vzhľad alebo navrhovať iný spôsob, ako napísať kód. V odpovedi môžete dostať úhľadný zoznam pripomienok, ktorý vám s vašou úlohou takmer nepomôže. Pozrime sa, ako dať subagentovi Claude Code zrozumiteľné zadanie a potom skontrolovať, či ho splnil.

Ak reviewer ešte nie je nastavený, najskôr vytvorte rolu a prvýkrát ju spustite. Tu sa sústredíme na samotné zadanie a úplnosť odpovede.

1. Čo poslať recenzentovi

Recenzent kontroluje cudziu prácu a vracia pripomienky so zdôvodnením. V našich príkladoch je to nastavený vlastný subagent s menom reviewer, ktorý smie súbory iba čítať a vyhľadávať v nich: Read, Grep, Glob. Kód študuje, ale neopravuje ho a stránku v prehliadači nespúšťa. Samotné meno reviewer takúto rolu automaticky nevytvorí: predpokladá sa, že vo vašom projekte už je nastavená.

Pri novom bežnom spustení takýto subagent automaticky nedostane celú históriu vášho rozhovoru. Hlavný agent, s ktorým komunikujete, mu zostaví samostatnú úlohu. Preto dôležitá požiadavka typu "dva nákupy s rovnakým názvom sú rôzne záznamy" musí byť v zadaní alebo v dokumente, ktorý má recenzent za úlohu prečítať. Tento postup opisuje dokumentácia o kontexte subagentov; tu ide o spustenie vlastnej roly, nie o fork s kópiou rozhovoru.

Porovnajte "Pozri sa na projekt" a "Skontroluj mazanie záznamov a aktualizáciu počítadla; kód nemeň". V druhom prípade je už jasné, kam sa pozerať a akú akciu nečakáte. Zostáva upresniť, čo považovať za správny výsledok.

Na krátku jednorazovú kontrolu stačí správa. Ak je kritérií veľa alebo sa kontrola bude po opravách opakovať, oplatí sa uložiť brief: krátky opis úlohy vedľa projektu. Nie samostatnú špecifikáciu na desať strán. Pár podmienok, bez ktorých by recenzent hádal.

Predvídať všetky otázky sa nedá, a ani to netreba. Keď vstupné údaje nestačia, recenzent má medzeru uviesť v správe. Hlavný agent si ju potom môže upresniť u vás. Dobré zadanie znižuje nejasnosti, ale dobrú odpoveď nezaručí: model sa môže pomýliť aj pri jasnej úlohe.

2. Štyri časti zadania

Cieľ odpovedá na otázku, aké správanie treba skontrolovať. Pri stránke zoznamu nákupov je to pridávanie, mazanie a počítadlo záznamov. "Urob projekt lepším" je príliš široké: nie je jasné, aké zlepšenie je teraz dôležité.

Vstup určuje súbory a očakávané správanie. Samotná cesta k app.js nestačí, ak sa z kódu nedá zistiť, či sú rovnaké názvy povolené. Toto produktové rozhodnutie treba odovzdať výslovne. Zároveň uveďte, čím kontrolovať: u nás je to iba čítanie kódu, bez prehliadača.

Hranice oddeľujú túto kontrolu od susedných úloh. Napríklad štýly, mobilné zobrazenie a ukladanie zoznamu medzi reláciami teraz neriešime. súbory nemeníme. Ak potrebný súbor chýba, zastavíme časť kontroly, ktorá od neho závisí, a oznámime to, namiesto toho, aby sme si jeho obsah vymýšľali.

Výsledok opisuje, čo chcete dostať: skontrolovaný rozsah, podložené nálezy a obmedzenia. Nežiadajte, aby recenzent za každú cenu našiel päť chýb. Odporúčania Claude Code pre review osobitne upozorňujú na riziko takéhoto zadania: úloha hľadať nedostatky tlačí k pripomienkam aj tam, kde je práca urobená správne.

Každá vetva pridáva niečo, čo ostatné nedajú: cesta k súboru neurčuje očakávané správanie a cieľ nestanovuje zákaz úprav. Dajte tieto podmienky dokopy, aby ich recenzent mohol pri kontrole porovnať.

Takže namiesto "Skontroluj stránku zoznamu nákupov" odovzdáme takéto zadanie. Môžete ho poslať správou alebo uložiť do REVIEW_BRIEF.md v koreňovom priečinku projektu:

# Kontrola zoznamu nákupov
Cieľ: skontrolovať v kóde pridávanie, mazanie a počítadlo.
Vstup: index.html a app.js v koreňovom priečinku projektu.
Očakáva sa: pridaná položka sa objaví v zozname;
počítadlo sa rovná počtu položiek; zmazanie jedného záznamu
nezmaže iný záznam s rovnakým názvom.
Hranice: súbory nemeniť; štýly, mobilné zobrazenie a ukladanie
zoznamu medzi reláciami do tejto kontroly nepatria.
Ak potrebný súbor alebo požiadavka chýba, uveď medzeru,
nedomýšľaj si ju a vráť výsledok za dostupnú časť.
Výsledok: drž sa formátu roly reviewer; uveď, čo je skontrolované
a čo zostalo neoverené. Žiadne nálezy sú prípustný výsledok.

Formát roly reviewer rozoberieme hneď nižšie. Ak vaša rola ešte nemá trvalý formát, môžete ho zahrnúť do tej istej jednorazovej správy. Názvy polí nie sú povinné: dôležité sú informácie, na ktoré vďaka nim nezabudnete.

Požiadavka "v správe najprv ukáž tri najpodstatnejšie nálezy" obmedzuje rozsah odpovede, nie hĺbku kontroly. Ak takýto limit potrebujete, požiadajte, aby recenzent zvlášť uviedol, či sú aj ďalšie nálezy. Zastaviť sa po tretej pripomienke a vyhlásiť úlohu za skontrolovanú nemožno.

3. Čo uložiť do súborov

Podmienky konkrétnej úlohy sa menia: dnes kontrolujeme počítadlo, zajtra ukladanie zoznamu. Tie patria do briefu. Požiadavka ukázať miesto chyby a zdôvodnenie je však potrebná takmer pri každom review. Pohodlnejšie je zapísať ju raz do inštrukcií roly.

Output contract, čiže kontrakt výsledku, tu znamená dohodnutý formát odpovede. Znie to vážnejšie, než to v skutočnosti je: sú to bežné inštrukcie pre recenzenta, nie špeciálne nastavenie Claude Code a nie automatická kontrola kvality. Formát pomáha nájsť v správe potrebné údaje, ale ich správnosť nezaručí.

Dve horné vetvy zodpovedajú za rôzne veci: brief určuje obsah kontroly, inštrukcie roly určujú okrem iného aj podobu správy. Aby recenzent uložený brief použil, zadajte mu, nech súbor prečíta. Sám sa doň nepozrie. Dole vznikne správa, ktorej zdôvodnenia a úplnosť ešte treba posúdiť.

Tu je sekcia, ktorú môžete pridať do textovej časti už existujúceho súboru roly .claude/agents/reviewer.md, za jeho nastavenia:

## Formát výsledku
Uveď skontrolované súbory a kritériá.
Pre každý nález: miesto, očakávané správanie, zdôvodnenie,
podmienky kontroly a dopad; prioritu vysvetli.
Oddeľuj to, čo potvrdzuje kód, od neoverených predpokladov.
Zvlášť uveď obmedzenia a chýbajúce údaje.
Ak si podľa kritérií problémy nenašiel, napíš to tak.

Toto je úryvok inštrukcií, nie celý súbor subagenta. Naša rola smie iba čítať a vyhľadávať, preto trvalé pole "zmenené súbory" nepotrebuje. V širšej správe musia údaje o zmenách zodpovedať skutočnosti: nemožno vopred predpísať riadok "zmenené súbory: žiadne" bez ohľadu na to, čo sa stalo.

Keď je brief uložený, pošlite hlavnému agentovi takúto požiadavku:

Zadaj role reviewer prečítať REVIEW_BRIEF.md v koreňovom priečinku projektu
a skontrolovať uvedené súbory podľa jeho kritérií.
Vráť výslednú správu celú.

Výslovne sme zadali dokument prečítať, nielen sme spomenuli jeho názov. Samotný súbor však nič nezaručuje: recenzent môže podmienku aj tak vynechať. Uložený brief je praktický tým, že s ním môžete porovnať výsledok a kontrolu zopakovať. Keď sa požiadavky zmenia, najprv aktualizujte dokument, inak ďalší prechod bude hodnotiť starú úlohu.

4. Ako skontrolovať správu

Najprv sa pozrite, čo sa naozaj skontrolovalo. V briefe bolo pridávanie, mazanie, počítadlo a nezávislosť záznamov s rovnakým názvom. Ak správa hovorí iba o počítadle, ešte to nie je výsledok za celú úlohu. Aj keď je jediný nález úplne správny.

Pomôže porovnať každé kritérium briefu s odpoveďou. Napríklad v cvičnej neúplnej správe to vyzeralo takto:

To, že chýba riadok o rovnakých názvoch, neznamená, že chyby nie sú. Zároveň jeden podložený nález o počítadle nenahradí vynechanú časť zadania. Vráťte správu s konkrétnym upresnením:

V briefe je zmazanie jedného z dvoch záznamov s rovnakým názvom.
Správa toto kritérium nepokrýva. Skontroluj ho dostupnými prostriedkami
a uveď zdôvodnenie výsledku alebo dôvod, prečo si ho skontrolovať nemohol.
Ostatné závery netreba opakovať bez zmien. Kód nemeň.

Zvlášť posúďte vierohodnosť podstatných nálezov: porovnajte uvedené miesto, požiadavku a zdôvodnenie záveru. Podrobný príklad nájdete v článku o čítaní správy z review. Tu sú potrebné obe kontroly: pokrytie zadania a podloženosť výsledku. Navrhnutý scenár spustenia sa nerovná už vykonanému testu.

Na prvom rázcestí rozhodujeme, či je pre našu úlohu skontrolované dosť. Ak nie, vyžiadame si chýbajúcu časť alebo prijmeme iba skontrolovanú časť, no aj pri nej posúdime zdôvodnenia. Na druhom rázcestí odlišujeme podložené závery od sporných a nesprávnych. Nejasné zdôvodnenie sa oplatí upresniť; preukázateľne nesprávnu pripomienku alebo radu mimo úlohy možno odmietnuť.

Touto kontrolou môže prejsť aj správa bez nálezov. Napríklad: "Skontrolované sú cesty pridávania a mazania, nezávislosť rovnakých záznamov a aktualizácia počítadla v index.html a app.js. Podľa týchto kritérií som problémy nenašiel; v prehliadači som nespúšťal". Takýto záver nesľubuje, že v projekte nie sú žiadne chyby. Oznamuje výsledok v uvedených medziach a kľúčové cesty si v prípade potreby overíte sami.

Zato "Nenašiel som app.js na uvedenej ceste, správanie mazania som nemohol skontrolovať" znamená nedostatok údajov, nie neprítomnosť chýb. Tu treba odovzdať správnu cestu a v kontrole pokračovať. Krátka poctivá odpoveď je užitočnejšia ako dlhá správa, v ktorej je medzera schovaná.

Prijať správu neznamená zadať opravu všetkého, čo je v nej uvedené. Uznali ste výsledok kontroly za podložený; ktoré zmeny urobiť teraz, rozhodujete zvlášť.

5. Kedy je potrebný ďalší prechod

Ak v správe chýba zdôvodnenie, review netreba začínať odznova. Vráťte konkrétnu medzeru. Napríklad skrátená verzia nálezu o počítadle obsahuje iba názov chyby, bez rozboru volaní. Požiadavka hlavnému agentovi potom môže vyzerať takto:

Vráť role reviewer správu na upresnenie: v náleze o počítadle
nie je uvedená cesta jeho aktualizácie po zmazaní.
Nech túto cestu skontroluje a doplní zdôvodnenie záveru.
Kód nemeniť.

Ak sa ukáže, že aktualizácia už prebieha v inej funkcii, pripomienku treba stiahnuť. Nehľadať za ňu náhradu kvôli pôvodnému počtu bodov. Ak sa chyba potvrdí, opravu môžete zadať hlavnému agentovi samostatnou požiadavkou, v ktorej uvediete konkrétny nález a prípustný rozsah zmien.

Po oprave sa oplatí ďalší prechod podľa toho istého briefu:

Zadaj role reviewer znova prečítať REVIEW_BRIEF.md a skontrolovať
aktuálny kód mazania a počítadla. Predchádzajúci nález:
po zmazaní sa počítadlo neaktualizovalo.
Nech uvedie, či je problém odstránený a na čom sa záver zakladá,
a tiež skontroluje, či nie je narušená nezávislosť záznamov
s rovnakým názvom. Kód nemeniť.

Teraz hľadáme odpoveď na konkrétnu otázku: je problém uzavretý a nie je narušené susedné správanie, ktoré mohla úprava zasiahnuť? Ak chcete správanie na stránke potvrdiť, zopakujte ten istý scenár v prehliadači. Ak bolo opakované review iba podľa kódu, toto obmedzenie platí aj pre novú správu.

Správa môže byť kratšia, dlhšia alebo nemusí obsahovať nové nálezy. V tom úspech nie je. Dôležité je, aby predchádzajúca chyba bola odstránená, záver sa opieral o aktuálny kód a neoverené časti zostali viditeľné. Rozhodli ste sa opravu odložiť? Potom si uložte potvrdený nález a dôvod odkladu; opakovať review nezmeneného kódu len kvôli novej odpovedi nemá zmysel.

6. Od zadania k overenému výsledku

Pri práci s Claude Code pomáha brief udržať vaše očakávania, kým hlavný agent odovzdáva úlohu recenzentovi. Trvalý formát uľahčuje čítanie odpovede. Zapojiť sa však musíte aj tak, a to takto:

• hlavný agent zostaví zadanie a odovzdá ho vhodnej role; vy určujete očakávané správanie a hranice;
• recenzent študuje súbory a vracia zdôvodnenia záverov; pokrytie a podstatné nálezy už kontrolujete vy;
• hlavný agent môže správu upresniť alebo opraviť potvrdenú chybu na základe samostatného zadania; vy rozhodujete, čo meniť a ako výsledok potvrdiť.

Pri zozname nákupov nebude výsledkom len rada "pridaj volanie funkcie", ale overené vysvetlenie: pri akej akcii sa číslo prestalo aktualizovať, kde sa aktualizácia prerušila a čo sa po oprave zmenilo. S takýmto výsledkom sa už dá pracovať.