Code-Review-Prompt schreiben: sechs Regeln und eine Vorlage

Warum die meisten Code-Review-Prompts Rauschen erzeugen

Die meisten Code-Review-Prompts sind eine Themenliste: „Prüfe diesen Code; achte auf Fehler, Sicherheitslücken, Performance und Lesbarkeit.“ Das Modell nimmt die Liste beim Wort und schreibt zu jedem Punkt etwas. Heraus kommt ein langer, höflicher Kommentar, der zum größten Teil nichts nützt. Wer den Pull Request geschrieben hat, liest ihn entweder ganz und verwirft das meiste, oder liest ihn gar nicht.

Was die Ausgabe wirklich verändert, ist eine Nachweispflicht: Das Modell schreibt, was es zeigen kann, und lässt weg, was es nicht zeigen kann. Bei diffox verteilen wir einen Pull Request auf 17 spezialisierte Agenten, und die Anweisung jedes Agenten beginnt mit genau dieser Bedingung (wie das funktioniert, steht in einem eigenen Beitrag). Die sechs Regeln unten stammen aus dieser Erfahrung und aus der Dokumentation der Tools selbst.

Die sechs Regeln

1. Verlangen Sie einen Nachweis. Zu jeder Feststellung gehört eine konkrete Eingabe oder ein Zustand, der das falsche Ergebnis erzeugt: „Ist die Liste leer, wird beim Durchschnitt durch null geteilt.“ Kann das Modell kein solches Szenario bauen, soll es schweigen. Dieser eine Satz beseitigt die meisten Kommentare der Art „darauf könnte man auch achten“.
2. Verlangen Sie ein wörtliches Zitat statt einer Zeilennummer. Modelle zählen Zeilen unzuverlässig; ein Zitat dagegen lässt sich in der Datei suchen und finden. Die Dokumentation von Anthropic empfiehlt dieselbe Technik: Findet das Modell kein Zitat, das seine Behauptung stützt, soll es die Behauptung zurückziehen (Quelle).
3. Beschränken Sie den Umfang auf diese Änderung. Ein Review gilt den Problemen, die die neuen oder geänderten Zeilen des Pull Requests verursachen. Wer dem heutigen Autor jeden Mangel im alten Code anlastet, schreibt einen Kommentar, den niemand liest.
4. Lassen Sie Geschmacksfragen weg und alles, was Ihre Tools schon prüfen. Formatierung, Vorlieben bei der Benennung oder ein fehlender Kommentar sind keine Review-Feststellungen; lassen Sie das Modell nicht noch einmal schreiben, was Linter und Typprüfer schon melden. Die Dokumentation von Codex sagt dasselbe: Formatierungs- und Lint-Prüfungen gehören in die CI.
5. Definieren Sie den Schweregrad. Was „blockierend“ und was „geringfügig“ heißt, schreiben Sie selbst: Ein falsches Ergebnis, Datenverlust oder eine Sicherheitslücke ist blockierend; was nur auf einem seltenen Pfad auftritt oder bloß ein irreführender Name ist, ist geringfügig. Ohne Definition ist jede Feststellung „wichtig“.
6. Legen Sie das Format der Ausgabe fest. Jede Feststellung hat dieselben Felder: Datei, Zitat, Szenario, falsches Ergebnis, Schweregrad, Korrektur in einer Zeile. Gibt es keine Feststellung, sagt das Modell das in einer Zeile und hört auf; ein leeres Review füllt es nicht auf.

Gemeinsam ist den sechs Regeln, dass jede eine Prüfung beschreibt, die das Modell ausführen kann. „Sei sorgfältig“ lässt sich nicht prüfen; „Steht das Zitat in der Datei?“ schon.

Kopieren Sie diese Vorlage und passen Sie sie an Ihr Repository an

Der folgende Prompt fasst die sechs Regeln in einem Text zusammen. Er ist auf Englisch geschrieben, weil alle vier Tools englische Anweisungen problemlos befolgen; die Sprache der Kommentare legt die letzte Zeile fest, hier Deutsch. Anpassen sollten Sie zwei Stellen: die Definition des Schweregrads und die Liste unter „Do not report“.

You are reviewing a pull request. Report only defects that this
change introduces or exposes.

A finding is valid only if you can state all three:
1. the code, quoted word for word from the changed lines;
2. a concrete input or state that reaches that code;
3. the wrong result that follows, and what the right one would be.
If you cannot state all three, do not report it.

Do not report: style, formatting, naming taste, missing comments,
anything a linter or a type checker already reports, or code this
change did not touch.

Severity:
- blocking: wrong result, data loss, security hole, or a crash on
  an ordinary path
- minor: wrong only on a rare path, or a name, comment or test that
  says something the code does not do

For each finding give: file, the quoted code, the scenario, the
wrong result, severity, and a one-line fix.
If you find nothing, write "No findings" and stop.
Write the findings in German.

Die Vorlage ist bewusst kurz. Die Dokumentation von Claude Code sagt, dass Länge ihren Preis hat: Eine lange Anweisungsdatei verwässert die Regeln, auf die es am meisten ankommt. Wenn Sie eigene Regeln hinzufügen, prüfen Sie bei jeder neuen Zeile, ob sie eine Feststellung verändert.

Welches Tool liest welche Datei?

Wohin Sie den Prompt schreiben, hängt vom Tool ab. Die Tabelle unten haben wir am 15. Oktober 2026 aus der eigenen Dokumentation der vier Tools zusammengestellt.

Quelle: die eigene Dokumentation jedes Tools, 15. Oktober 2026.

Zwei Details werden oft übersehen. In Claude Code liest nur das Code Review auf GitHub die Datei REVIEW.md; /code-review im Terminal liest sie nicht. Copilot wiederum liest die Anweisungen aus dem Head-Branch des Pull Requests, also aus dem Branch mit den Änderungen: Ein Pull Request, der die Anweisungsdatei ändert, ändert damit auch die Regeln seines eigenen Reviews.

Um Ihren eigenen Prompt in Claude Code zu einem Befehl zu machen, schreiben Sie einen Skill: Legen Sie die Vorlage in die Datei .claude/skills/pruefen/SKILL.md und setzen Sie die Zeile !`git diff main...HEAD` an den Anfang. Diese Zeile führt den Befehl aus und setzt seine Ausgabe in den Prompt ein; wenn Sie /pruefen eingeben, findet das Modell den Diff schon vor (Dokumentation zu Skills).

Regeln für Ihr eigenes Repository

Die Vorlage deckt das Allgemeine ab; der eigentliche Wert liegt in den Regeln Ihres eigenen Repositorys. Das sind die Dinge, die Sie in jedem Review aufs Neue sagen: welche Daten welche Schicht nicht passieren dürfen, welcher Nebeneffekt gefährlich ist, welcher Vertrag nicht gebrochen werden darf.

Eine gute Regel hat drei Teile, und die Dokumentation von Codex zählt alle drei auf: das Verhalten, das markiert werden soll, warum es wichtig ist, und den sicheren Weg oder die Ausnahme. Der dritte wird am häufigsten vergessen: Nennen Sie dem Modell den richtigen Weg nicht, markiert es auch das erwartete Verhalten als Fehler.

• Schwach: „Achte auf Datenbankabfragen.“
• Stark: „Jede Abfrage muss auf den Mandanten des Aufrufers beschränkt sein. Sicherer Weg: die Hilfsfunktion scoped(). Ausnahme: Admin-Berichte.“

Die Nachweispflicht können Sie auch auf Ebene des Repositorys festlegen. Das Beispiel aus der Dokumentation von Claude Code: Eine Behauptung über Verhalten muss Datei und Zeile im Quellcode nennen, statt aus der Benennung zu schließen. Diese eine Regel verringert die Fehlalarme, die den Autor eine vergebliche Runde kosten.

Wenn ein Prompt nicht reicht

Wenn Sie einen einzigen Prompt nach Sicherheit, Nebenläufigkeit, Tests und Regeltreue zugleich fragen, teilt das Modell seine Aufmerksamkeit und findet von allem ein bisschen. Bei großen Änderungen hilft es, die Arbeit aufzuteilen: Jeder Prompt sucht nur eine Sache und hält sich an dieselbe Nachweispflicht.

Im zweiten Schritt prüfen Sie, was das Modell behauptet. Ein Modell kann überzeugend klingen und trotzdem falsch liegen: Es zitiert eine Zeile, die nicht in der Datei steht, oder beanstandet Code, den die Änderung gar nicht berührt. Weil Sie ein Zitat verlangen, können Sie das mit einem Programm prüfen: Steht das Zitat wirklich in dieser Datei, und gehört es zu den geänderten Zeilen? Die Dokumentation zum Code Review von Claude Code beschreibt dasselbe Muster: Jeder Agent sucht nach einer anderen Klasse von Problemen, danach sortiert ein Prüfschritt die Fehlalarme aus.

Bei diffox übernimmt das Produkt selbst diese beiden Schritte: Jeder der 17 spezialisierten Agenten im Team sucht nur eine Sache und belegt seinen Fund mit einem wörtlichen Zitat aus dem Code; das Zitat prüft Code, kein Modell. Außerdem bekommen die Agenten jeden Satz aus der Regeldatei im Stammverzeichnis Ihres Repositorys (AGENTS.md oder CLAUDE.md), der eine Pflicht ausdrückt, als Review-Regel.

Testen Sie die Regel an einem echten Pull Request

Ob ein Prompt gut ist, erkennt man nicht beim Lesen. Der praktischste Rat steht in der Dokumentation von Codex: Öffnen Sie einen repräsentativen Pull Request, fordern Sie ein Review an, korrigieren Sie die Regeln anhand der Feststellungen, die zurückkommen, und schränken Sie Anweisungen, die Rauschen erzeugen, ein oder streichen Sie sie.

• Testen Sie an einer Änderung, die gegen die Regel verstößt: Wird der Verstoß gefunden?
• Testen Sie an einer Änderung, die den sicheren Weg nimmt: Bleibt das Review still?
• Testen Sie an einer Änderung, die mit dem Thema nichts zu tun hat: Bleibt es auch dann still?

Lassen Sie denselben Pull Request zweimal prüfen, können Sie zwei verschiedene Ergebnisse bekommen; werten Sie einen einzelnen Versuch nicht als Ergebnis. Vergleichen Sie die Ergebnisse vor und nach einer neuen Regel an denselben wenigen Pull Requests.