Code-Review, die jeden Fund beweist – benchmarked

Bitte eine KI um ein PR-Review, und du bekommst ein sauberes Checklisten-Ergebnis: Injection geprüft, Secrets geprüft, Auth geprüft, sieht gut aus. Das liest sich nach Sorgfalt. Ob dabei wirklich etwas gefunden wurde, ist eine andere Frage – und genau die Checkliste ist es, die den blinden Fleck verdeckt. Wir betreiben ein Verzeichnis, das Claude-Skills beruflich benchmarkt, und als wir unseren eigenen Test auf ein Review-Skill losgelassen haben, das wir bereits mit bestanden bewertet hatten, lief es an einem hartcodierten Secret vorbei, das die ungeführte Baseline fand. Für diese Stelle gab es keine Checklisten-Zeile, also hat der Reviewer nie hingeschaut.

Genau dieser Fehltritt ist der Grund, warum es review-discipline gibt – und warum es sie bereits in der zweiten Version gibt. Kostenlos und MIT-lizenziert: github.com/Skillproofdev/review-discipline. Jeder gemeldete Fund muss einen konkreten Input benennen, der den Code erreicht und ein falsches Ergebnis erzeugt – sonst geht er nur abgestuft als [suspicion] raus, nie als Tatsache behauptet. In unserem Bench mit eingeschleusten Bugs findet es 18,5 von 21 platzierten Bugs bei null False Positives und einem nachgewiesenen Fehlerpfad für ~100% der Funde.

Die Lücke: jedes Review-Skill ist eine Checkliste, und Checklisten erzeugen Tunnelblick

Bevor wir eine Zeile geschrieben haben, haben wir 321 gecrawlte Review-Skills plus das freie Feld gesichtet – inklusive Anthropics eigenem Code-Review-Plugin. Drei Mechanismen tauchten in keinem davon als durchsetzbare Regel für einen Einzel-Agenten auf. Alle drei führen auf denselben Fehler zurück, den wir in unserem Bench live beobachtet haben.

Eine Checkliste sagt dem Reviewer, wonach er suchen soll. Das ist gleichzeitig eine Liste dessen, woran er vorbeischaut. Fehlt eine Kategorie, überlebt der Bug – und schlimmer noch: Die Review kommt trotzdem grün zurück, weil jedes vorhandene Kästchen abgehakt wurde. Ein Review scheitert auf zwei Arten: unbewiesene Vermutungen als Tatsache melden (Rauschen) und einen echten Bug stillschweigend übergehen, weil er klein ist oder ein spektakulärerer die ganze Aufmerksamkeit gebunden hat (verpasste Abdeckung). Eine Checkliste ist strukturell gut darin, beides zu produzieren.

Anthropics Plugin bekämpft die Rauschen-Hälfte mit parallelen Scorer-Agenten, die per Abstimmung einen Konfidenzwert vergeben. Das ist ein echter Mechanismus, braucht aber mehrere Agenten und adressiert die Abdeckungs-Hälfte überhaupt nicht. Niemand liefert das Gegenstück, das die Checkliste umdreht: erst alles jagen, bevor man zu einer Kategorienliste greift, dann jeden Fund beweisen oder markieren, und nur verwerfen, was man tatsächlich widerlegen kann – in einem Agenten, in einer installierbaren Datei.

Acht Regeln, drei davon erzwingt sonst niemand

Das Skill ist ein Satz durchsetzbarer Regeln (vollständige SKILL.md). Die bekannten Teile sind vorhanden: P0–P3-Schweregrade mit echten Definitionen statt Bauchgefühl, Diff-Scope-Disziplin (die Änderung reviewen, nicht die ganze Codebase), fehlende Tests, die an das geänderte Verhalten geknüpft sind, und null Lob-Füllwörter. Die Teile, die sonst niemand durchsetzt:

1. Kein nachgewiesener Fehlerpfad, kein Fund. Jeder Fund muss einen konkreten Input oder Zustand benennen, der den markierten Code erreicht und ein falsches Ergebnis erzeugt. Lässt sich keiner konstruieren, geht der Fund nur als [suspicion] raus, eingestuft unterhalb jedes bewiesenen Funds – nie als Tatsache. Eine unbewiesene Behauptung, die als Bug ausgegeben wird, ist die einzige verbotene Ausgabe des Skills.
2. Zwei Durchgänge, erst die offene Jagd. Die Änderung wird gelesen wie ein Angreifer ohne Kategorienliste in der Hand – jede Auffälligkeit wird notiert, ohne Schweregrad-Untergrenze; selbst etwas, das nur leicht komisch riecht, wird festgehalten. Erst danach folgt die Standard-Checkliste (Secrets, Injection, Grenzfälle, Arithmetik, Nebenläufigkeit …) für alles, was die offene Jagd übersehen hat. Bei jedem Konkurrenten ist die Checkliste der Anfang – hier läuft sie bewusst als Zweites.
3. Den eigenen Fund killen, bevor er gemeldet wird. Ein ehrlicher Widerlegungsversuch pro Fund – vorgelagerte Guards, beabsichtigtes Verhalten, bestehende Testabdeckung, Erreichbarkeit – und der Bericht sagt, was geprüft wurde. Widerlegung ist das einzige Tor, das einen Fund fallen lassen darf; „ich konnte es mir nicht beweisen“ wird zu [suspicion], nicht zum stillen Verwerfen. Funde, die wirklich sterben, sterben lautlos.

Die tragende Regel ist die Reihenfolge: erst Breite, dann Tiefe. Erst jede Auffälligkeit ohne Schweregrad-Untergrenze sammeln, bevor auch nur eine einzige verifiziert wird – so kann die Tiefenbohrung bei einem Bug die Jagd nach den restlichen nie abschneiden. Klingt selbstverständlich. Ist aber genau die Regel, die unserer ersten Version gefehlt hat – und der Grund, warum sie verloren hat.

Der ehrliche Benchmark (negative Ergebnisse inklusive)

Protokoll mit eingeschleusten Bugs: echte Code-Beispiele (~200–400 Zeilen, TypeScript / Python / JS) mit dokumentierten Bugs bekannten Schweregrads – Logik, Sicherheit, Edge Case, Nebenläufigkeit –, die Ground Truth wurde vor jedem Lauf festgelegt. Echter, unversehrter Code bleibt in jeder Probe, um False Positives zu messen. Gleiche Prompts, gleiches Modell; die einzige Variable ist, ob der Agent zuerst die SKILL.md liest. Volle Methodik: skillproof.dev/methodology.

4 Proben, 21 eingeschleuste Bugs, 12 absichtlich gesunde False-Positive-Fallen. Die interessante Spalte ist nicht Base-gegen-Skill – sondern v1 gegen v2, denn unser eigener Bench war es, der den Neubau erzwungen hat.

Metrik	Base (ohne Skill)	Skill v1	Skill v2
Gefundene eingeschleuste Bugs (von 21)	17,0 (81%)	16,5 (79%)	18,5 (88%)
P0-Trefferquote (ausnutzbar / Datenverlust)	3/3	3/3	3/3
P1-Trefferquote (falsches Verhalten, realistischer Pfad)	7/7	7/7	7/7
P2-Trefferquote (Edge-Cases / Arithmetik-Pfade)	6/7	4/7	7/7
Test auf hartcodiertes Secret	gefunden	gefunden	gefunden
False-Positive-Rate	5,6% (1 FP)	0%	0%
Funde mit nachgewiesenem Fehlerpfad	~63%	~100%	~100%
[suspicion]-Abstufungen (ehrliche Vorbehalte)	0	3	5
Lob-/Füllzeilen	vorhanden	keine	keine

Sieh dir die mittlere Spalte an, und du erkennst den Fehltritt, der diesem Skill den Namen gegeben hat. v1 kam auf 16,5 – unter der ungeführten Baseline von 17. Die Fehlerpfad-Disziplin war da (False Positives auf null gedrückt, ~100% der Funde nachgewiesen), aber v1 war schlechter darin, Bugs zu finden, weil sie sich in einer Probe an den spektakulären P0s festbiss und nie über die unauffälligen Rundungsfehler-Zeilen ging. Es hatte einen Tunnelblick. Unser öffentlicher Bench eines Skills, das wir mit bestanden bewertet hatten, hat genau das aufgedeckt: v1 verpasste zwei echte P2-Bugs – einen Logikfehler bei prorate /30 und eine Trunkierung bei int(amount × 100) –, die die Baseline allein durch lineares Lesen fand.

Die Lösung war die Regel „erst Breite, dann Tiefe“. v2 sammelt jede Auffälligkeit ohne Schweregrad-Untergrenze, bevor auch nur eine verifiziert wird. Ergebnis: P2 stieg von 4/7 auf saubere 7/7 (es fand sogar einen leeren StopIteration-Bug bei leerem CSV, den sowohl Base als auch v1 übersahen), die Gesamt-Trefferquote kletterte auf 18,5 – über Bases 17 – und die Disziplin hielt: weiterhin null False Positives, weiterhin ~100% nachgewiesene Pfade, und mehr ehrliche [suspicion]-Vorbehalte (5 statt 3) statt weniger. Die vollständige 3-Wege-Bewertung steht in bench/results/verdict.md.

Ein Mythos, den der Bench nebenbei entlarvt hat: Die Checklisten-Tunnelblick-bei-Secrets-Hypothese, die das ganze Projekt motiviert hat, hat sich im eingeschleusten Lauf nicht reproduziert – alle drei Arme fanden den Test auf das hartcodierte Secret (S4-B1). Der ursprüngliche Fehltritt war real und hat uns die Form des Problems gezeigt; der eingeschleuste Bench zeigte nur, dass das Secret selbst nicht die Stelle ist, an der sich Breite auszahlt. Die Rundungsfehler-Edge-Cases sind es. Wir berichten den Mechanismus, der die Zahlen tatsächlich bewegt hat – nicht den, der die bessere Entstehungsgeschichte ergeben hätte.

Wo v2 verloren hat – trotzdem veröffentlicht

Unsere Methodik verlangt, dass die Verluste neben den Gewinnen stehen. v2 ist der beste Arm bei allem, was einen Merge blockiert, aber es ist keine strikte Obermenge von v1, und das verschweigen wir nicht.

Auf der Jagd nach erschöpfender Breite hat v2 aufgehört, in eine einzelne Funktion (_parse_tags) tief zu bohren, und ist an einem subtilen literal_eval-Verdacht auf tiefe Verschachtelung (S2-B5) vorbeigelaufen, den v1s tiefenorientierter Durchgang als einziger gefunden hatte. Auf der P3-/außerhalb-der-Checkliste-Achse ist v2 also tatsächlich zurückgefallen – von v1s 2,5/4 auf 1,5/4. Unterm Strich ist das ein guter Tausch (+2 mittlere Funde für −1 subtilen P3), aber es ist ein echter Rückschritt auf dieser einen Achse, keine saubere Dominanz. Der ideale Reviewer wäre v2s Breite plus v1s Bereitschaft, bei unauffällig aussehendem Code noch eine Ebene tiefer zu bohren – und das sagen wir dir lieber, statt es zu glätten.

Es gibt außerdem einen Bug, den kein Arm gefunden hat: ein Gutschein-Ablauf mit strikter <-Grenze (S1-B6), verpasst von Base, v1 und v2 gleichermaßen. Das Skill reduziert verpasste Funde; es macht Claude nicht unfehlbar.

Installation

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

Claude Code neu starten. Ein Befehl – das Repo ist das Skill. Es greift bei „review this PR/diff“, „check this before merge“, „find bugs in“ und Pre-Merge-Checks – und hält sich raus bei Feature-Entwicklung, reinem Style-Linting und Prosa-Reviews. Es reiht sich in unsere Discipline-Serie ein: token-discipline senkt, was ein Agent kostet, research-discipline senkt, was er bei Fakten falsch macht, und dieses hier senkt, was eine Review übersieht.

FAQ

Wie unterscheidet sich das von Anthropics Code-Review-Plugin? Das Plugin filtert False Positives, indem parallele Scorer-Agenten per Abstimmung einen Konfidenzwert vergeben – wirksam, braucht aber mehrere Agenten und löst nur das Rauschen-Problem. review-discipline filtert mit einem nachgewiesenen Fehlerpfad in einem einzigen Agenten, in einer installierbaren Datei, und greift zusätzlich das Abdeckungsproblem an, das das Plugin nicht anfasst: die Regel „erst offene Jagd, dann Checkliste“, die unsere eigene P2-Trefferquote von 4/7 auf 7/7 gehoben hat.

Führt „jeden Fund beweisen“ nicht dazu, dass es Dinge übersieht, die es nicht belegen kann? Nein – dafür gibt es den [suspicion]-Mechanismus. Ein echter Bug, für den sich kein Fehlerpfad konstruieren lässt (weil Laufzeitzustand fehlt oder ein externes System betroffen ist), wird trotzdem gemeldet, markiert als [suspicion] und unterhalb der bestätigten Funde eingestuft, mit einer Zeile dazu, was fehlt. Die Konfidenz herabstufen ist erlaubt; fallen lassen nicht. Im Bench hat v2 fünf solcher ehrlichen Vorbehalte gemeldet, statt sie zu verschlucken.

Reviewt es die ganze Codebase oder nur meinen Diff? Nur die Änderung. Funde müssen von diesem Diff verursacht oder aktiviert sein; bestehende Probleme landen in einer kurzen Out-of-Scope-Notiz, nicht in der Rangliste. Die eine Ausnahme ist ein bereits bestehender P0 – ein aktives Secret oder eine aktive Schwachstelle –, der immer prominent gemeldet wird. Diese Ausnahme gibt es genau wegen des Fehltritts aus der Entstehungsgeschichte.

Reicht 18,5/21, um auf menschliches Review zu verzichten? Nein. Es findet jeden P0- und P1-Merge-Blocker in unserem Bench und schlägt eine ungeführte Baseline bei der Gesamt-Trefferquote bei null False Positives – das macht es zu einem starken ersten Reviewer, der nie durchwinkt und immer benennt, was er geprüft hat. Aber es hat einen eingeschleusten Bug komplett verpasst und einen subtilen P3 gegen Breite eingetauscht, beides oben dokumentiert. Nutze es, damit die offensichtlichen und die leisen Arithmetik-Bugs erst gar nicht bei einem Menschen landen – behalte den Menschen für die letzte Tiefenebene.