Kodegjennomgang som beviser hver feil den finner

Be en KI om å reviewe PR-en din, og du får et ryddig sjekkliste-resultat tilbake: injection sjekket, secrets sjekket, auth sjekket, ser bra ut. Det leser som grundighet. Om den faktisk fant noe, er en helt annen sak — og sjekklisten er nettopp det som skjuler bommen. Vi driver en katalog som benchmarker Claude-skills til daglig, og da vi rettet vår egen benchmark mot en review-skill vi allerede hadde vurdert som bestått, gikk den rett forbi en hardkodet hemmelighet som den ustyrte baseline-kjøringen fanget opp. Listen hadde ingen linje for akkurat det stedet, så revieweren så aldri dit.

Den bommen er grunnen til at review-discipline finnes — og grunnen til at den nå er i sin andre versjon. Den er gratis og MIT-lisensiert: github.com/Skillproofdev/review-discipline. Hvert funn den rapporterer må navngi et konkret input som når koden og gir et galt resultat — ellers sendes det nedgradert som [suspicion], aldri hevdet som fakta. På vår seedede feil-benchmark fanger den 18.5 av 21 plantede feil med null falske positive og en påvist feilvei på ~100 % av funnene.

Gapet: alle review-skills er en sjekkliste, og sjekklister gir tunnelsyn

Før vi skrev en eneste linje kartla vi 321 crawlede review-skills pluss det frittstående feltet — inkludert Anthropics eget code-review-plugin. Tre mekanismer fantes i ingen av dem som håndhevbare enkeltagent-regler. Alle tre spores tilbake til den samme bommen vi så skje i vår egen benchmark.

En sjekkliste forteller revieweren hva den skal se etter. Det er også en liste over hva den skal se forbi. Når kategoriene ikke inkluderer feilen, overlever feilen — og verre: reviewen kommer likevel tilbake grønn, fordi hver boks som finnes ble krysset av. De to måtene en review feiler på er å rapportere ubeviste gjetninger som fakta (støy) og stillferdig å hoppe over en ekte feil fordi den er liten eller fordi en skumlere en stjal all oppmerksomheten (mistet dekning). En sjekkliste er strukturelt god på å produsere begge deler.

Anthropics plugin bekjemper støy-halvparten med parallelle scorer-agenter som stemmer på et konfidenstall. Det er en reell mekanisme, men den krever flere agenter og løser ikke dekningshalvparten i det hele tatt. Ingen leverer det som snur sjekklisten på hodet: jakt på alt før du griper til en kategoriliste, bevis eller merk hvert funn i andre omgang, og forkast bare det du faktisk kan tilbakevise — i én agent, i én installerbar fil.

Åtte regler, tre av dem håndhever ingen andre

Skillen er et sett med håndhevbare regler (hele SKILL.md). De kjente delene er der: P0–P3-alvorlighetsgrad med ekte definisjoner i stedet for magefølelse, diff-scope-disiplin (review endringen, ikke hele kodebasen), manglende-test-varsler koblet til den endrede oppførselen, og null ros-fyll. Delene ingen andre håndhever:

1. Ingen påvist feilvei, ingen funn. Hvert funn må navngi et konkret input eller en tilstand som når frem til den flaggede koden og gir et galt resultat. Klarer du ikke å konstruere en? Da sendes det som [suspicion], rangert under hvert bevist funn — aldri som fakta. En ubevist påstand hevdet som en feil er skillens ene forbudte utdata.
2. To gjennomganger, åpen jakt først. Les endringen som en angriper med ingen kategoriliste i hånden og noter hvert avvik — ingen alvorlighetsgrense, noe som bare lukter litt rart skrives fortsatt ned. Først da feies den vanlige sjekklisten (hemmeligheter, injection, grenser, aritmetikk, samtidighet …) for alt den åpne jakten bommet på. Alle konkurrenter er sjekklisten; her kjører den som nummer to, med vilje.
3. Drep ditt eget funn før du rapporterer det. Ett ærlig tilbakevisningsforsøk per funn — sjekker lenger opp i koden, tilsiktet oppførsel, eksisterende testdekning, nåbarhet — og rapporten sier hva som ble sjekket. Tilbakevisning er den eneste porten som får lov til å droppe et funn; «jeg gadd ikke bevise det» blir en [suspicion], ikke en stille forkastelse. Funn som faktisk dør, dør stille.

Den bærende regelen er rekkefølgen: bredde før dybde. Samle hvert avvik uten alvorlighetsgrense før du verifiserer et eneste et av dem, slik at dypdykket i én feil aldri kan avkutte jakten på resten. Det høres opplagt ut. Det er også nøyaktig regelen vår første versjon ikke hadde — og grunnen til at den tapte.

Den ærlige benchmarken (negative resultater inkludert)

Seedet-feil-protokoll: ekte kodeeksempler (~200–400 linjer hver, TypeScript / Python / JS) tilsatt dokumenterte feil med kjent alvorlighetsgrad — logikk, sikkerhet, kantstilfeller, samtidighet — med fasit fastlåst før noen kjøring. Ekte, uskadd kode blir stående i hvert eksempel for å måle falske positive. Samme prompter, samme modell; den eneste variabelen er om agenten leser SKILL.md først. Hele metodikken: skillproof.dev/methodology.

4 eksempler, 21 seedede feil, 12 bevisst friske falske-positiv-feller. Den interessante kolonnen er ikke base-mot-skill — det er v1 mot v2, fordi det var vår egen benchmark som tvang frem ombyggingen.

Metrikk	Base (uten skill)	Skill v1	Skill v2
Seedede feil funnet (av 21)	17.0 (81 %)	16.5 (79 %)	18.5 (88 %)
P0-fangst (utnyttbar / datatap)	3/3	3/3	3/3
P1-fangst (feil oppførsel, realistisk vei)	7/7	7/7	7/7
P2-fangst (kant-/aritmetikkveier)	6/7	4/7	7/7
Test på hardkodet hemmelighet	fanget	fanget	fanget
Falske-positiv-rate	5.6 % (1 FP)	0 %	0 %
Funn med påvist feilvei	~63 %	~100 %	~100 %
[suspicion]-nedgraderinger (ærlige forbehold)	0	3	5
Ros-/fyll-linjer	til stede	ingen	ingen

Les den midterste kolonnen, så ser du feilen som ga skillen navnet sitt. v1 scoret 16.5 — under den ustyrte baseline-ens 17. Den hadde feilvei-disiplinen (den kuttet falske positive til null og påviste ~100 % av funnene sine), men den var dårligere til å finne feil, fordi den låste seg på de skumle P0-ene i ett eksempel og aldri feide gjennom de stille avrundingslinjene for pengebeløp. Den fikk tunnelsyn. Vår offentlige benchmark av en skill vi hadde vurdert som bestått, er det som avslørte det: v1 bommet på to reelle P2-er — en prorate /30-logikkfeil og en int(amount × 100)-avkutting — som baseline-en plukket opp bare ved å lese lineært.

Fiksen var bredde-før-dybde-regelen. v2 samler hvert avvik uten alvorlighetsgrense før den verifiserer noen av dem. Resultat: P2 gikk fra 4/7 til et rent 7/7 (den fanget til og med opp igjen en tom-CSV StopIteration som begge base og v1 bommet på), total gjenfinning klatret til 18.5 — forbi base sine 17 — og disiplinen holdt: fortsatt null falske positive, fortsatt ~100 % påviste feilveier, og flere ærlige [suspicion]-forbehold (5 mot 3) i stedet for færre. Full 3-veis vurdering finner du i bench/results/verdict.md.

Én myte benchmarken også avlivet, rett ut: hypotesen om sjekkliste-tunnelsyn-på-hemmeligheter som satte i gang hele prosjektet, reproduserte seg ikke i den seedede kjøringen — alle tre armene fanget testen på hardkodet hemmelighet (S4-B1). Den opprinnelige bommen var reell, og den lærte oss formen på problemet — den seedede benchmarken viste bare at hemmeligheten i seg selv ikke er der bredde lønner seg. Kantstilfellene med pengeavrunding er det. Vi rapporterer mekanismen som faktisk flyttet tallene, ikke den som ga den bedre opprinnelseshistorien.

Der v2 tapte — publisert likevel

Vår metodikk krever at tapene vises ved siden av seirene. v2 er den beste armen på alt som stopper en merge, men den er ikke en streng overmengde av v1, og vi later ikke som noe annet.

I jakten på uttømmende bredde sluttet v2 å bore i én funksjon (_parse_tags) og gikk forbi en subtil literal_eval-dyp-nøsting-mistanke (S2-B5) som v1s dybde-først-gjennomgang unikt hadde fanget. Så på P3-/utenfor-sjekklisten-aksen gikk v2 faktisk tilbake — fra v1s 2.5/4 ned til 1.5/4. Netto er det en god handel (+2 middels mot −1 subtil P3), men det er en reell tilbakegang på den ene aksen, ikke en ren dominans. Den ideelle revieweren er v2s bredde pluss v1s vilje til å bore ett nivå til på kode som ser stille ut — og vi vil heller si det enn å runde det bort.

Det finnes også en feil ingen arm fanget: en kupong-utløp streng-<-uavgjort (S1-B6), bommet på av base, v1 og v2 likt. Skillen kutter bommer; den gjør ikke Claude ufeilbarlig.

Installasjon

git clone https://github.com/Skillproofdev/review-discipline ~/.claude/skills/review-discipline

Start Claude Code på nytt. Én kommando — repoet er skillen. Den trigger på «review denne PR-en/diffen», «sjekk dette før merge», «finn feil i», og pre-merge-sjekker — og holder seg unna funksjonsskriving, ren stil-linting og prosa-review. Den inngår i vår disiplin-serie: token-discipline kutter hva en agent koster, research-discipline kutter hva den bommer på av fakta, og denne kutter hva en review overser.

Ofte stilte spørsmål

Hvordan skiller dette seg fra Anthropics code-review-plugin? Pluginen filtrerer falske positive ved å la parallelle scorer-agenter stemme på et konfidenstall — effektivt, men det krever flere agenter og løser bare støyproblemet. review-discipline filtrerer med en påvist feilvei i én enkelt agent, i én installerbar fil, og angriper også dekningsproblemet som pluginen ikke rører: regelen om åpen jakt før sjekkliste, som løftet vår egen P2-gjenfinning fra 4/7 til 7/7.

Vil ikke «bevis hvert funn» gjøre at den overser ting den ikke kan påvise? Nei — det er [suspicion]-mekanismen. En ekte feil du ikke kan bygge en feilvei for (krever kjøretidstilstand du ikke kan se, eller et eksternt system) blir fortsatt rapportert, merket [suspicion] og rangert under de bekreftede funnene, med én linje om hva som mangler. Å nedgradere sikkerheten er verktøyet; å droppe er det ikke. I benchmarken sendte v2 5 slike ærlige forbehold i stedet for å svelge dem.

Reviewer den hele kodebasen eller bare diffen min? Bare endringen. Funn må være forårsaket eller aktivert av denne diffen; eksisterende problemer går i en kort notis utenfor omfanget, ikke i den rangerte listen. Det ene unntaket er en eksisterende P0 — en aktiv hemmelighet eller en aktiv sårbarhet — som alltid flagges tydelig. Det unntaket finnes nettopp på grunn av opprinnelses-bommen.

Er 18.5/21 godt nok til å droppe menneskelig review? Nei. Den fanger hver P0- og P1-merge-stopper i vår benchmark og slår en ustyrt baseline på total gjenfinning med null falske positive — det gjør den til en sterk første reviewer som aldri stempler blindt og alltid navngir hva den angrep. Men den bommet på én seedet feil helt og byttet bort en subtil P3 mot bredde, begge dokumentert over. Bruk den til å sørge for at de opplagte og de stille aritmetikk-feilene ikke når et menneske; behold mennesket til det siste dybdenivået.