Pull Request Reviews mit Claude Code, 10 Schritte für den PR-Workflow den keiner mehr blockiert
Pull Requests sind der Ort wo AI-Code entweder still durchrutscht oder den Build sprengt. Hier sind 10 Schritte wie Du Claude Code als zweite Augenpaar für Reviews nutzt, ohne dass Dein Reviewer-Kollege seine Arbeit verliert oder die Pipeline lahmlegt.
Du oeffnest morgens GitHub, drei Pull Requests warten. Einer ist Deiner, zwei von Kollegen. Der Reviewer-Job kostet Dich jedes Mal eine Stunde, weil Du den Code lesen, die Tests prüfen, das CI-Log durchgehen und am Ende noch die Branch lokal auschecken willst. Genau diesen Loop kann Claude Code abkuerzen, wenn Du ihn richtig einsetzt.
Wichtig vorab. Claude Code ersetzt den menschlichen Reviewer nicht. Was er gut kann, ist das Vorab-Lesen, das Strukturieren der Findings und das Formulieren konkreter Kommentare. Was er schlecht kann, ist Architektur-Beurteilung und Business-Kontext einschaetzen. Wir nutzen ihn als ersten Pass, nicht als finale Instanz.
Ich gehe davon aus dass Du Claude Code lokal installiert hast und dass Du das Mini-Modul L1-08 bis L1-10 plus das Playbook git-für-ki-quickstart durch hast. Wer mit Branches und Pull Requests noch unsicher ist, schaut da vorher rein.
Schritt 1, den richtigen Branch lokal auschecken
Erste Regel. Nie ein Review aus dem GitHub-Diff alleine. Du brauchst den Branch lokal, weil Claude Code mit dem Working-Tree arbeitet, nicht mit Web-Diffs.
git fetch origin
git checkout -b review/pr-142 origin/feature/auth-flow
Mach Dir einen Review-Branch mit klarem Praefix. So kannst Du später alle offenen Reviews mit git branch | grep review/ auflisten und nichts liegt im falschen Branch herum.
Wenn der PR auf einen anderen Base-Branch zielt als Du gerade hast, erst die Base ziehen. Sonst liest Du Diffs gegen einen alten Stand.
Schritt 2, den Diff im Working-Tree sichtbar machen
Claude Code sieht nur was im Working-Tree liegt. Damit er den PR-Diff lesen kann, gibst Du ihm den Befehl wie er ihn selbst auslesen würde.
Im Claude Code Chat:
git diff origin/main...HEAD > .review-diff.txt
Das schreibt den vollstaendigen Diff in eine Datei die Du dann referenzieren kannst. Vorsicht, die Datei nicht committen. Pack .review-diff.txt ins .gitignore oder loesch sie nach dem Review.
Alternativ kannst Du Claude Code direkt bitten den Diff zu generieren. Er führt den git diff aus und liest das Ergebnis selbst. Funktioniert genauso, ist aber bei großen Diffs schlechter, weil das Ergebnis im Context bleibt.
Schritt 3, mit einem strukturierten Prompt starten
Der Unterschied zwischen brauchbarem und unbrauchbarem AI-Review ist der Prompt. Generisch "review this PR" gibt Dir generisches Geschwafel. Du brauchst eine Liste an konkreten Fragen.
Mein Standard-Prompt für einen Review-Pass:
Du bist Reviewer für den Diff in .review-diff.txt.
Prüfe in dieser Reihenfolge:
1. Gibt es offensichtliche Bugs (Off-by-One, Null-Refs, falsche Type-Casts)
2. Wird User-Input ohne Validierung verarbeitet
3. Sind die neuen Tests sinnvoll (testen sie was sie testen sollen)
4. Gibt es Code-Duplikation gegenueber existierendem Code im Repo
5. Werden Konventionen aus CLAUDE.md verletzt
Ausgabe als nummerierte Liste mit File-Pfad, Zeilennummer und konkretem Vorschlag.
Keine Lobeshymnen, nur Findings.
Den Prompt hab ich in ~/.claude/commands/review-pr.md als Slash-Command. Dann reicht /review-pr und der Loop läuft.
Schritt 4, Findings in eine Liste pressen
Was Claude Code zurueckgibt ist meistens zu lang. Lange Prosa, zwei Sätze pro Finding, ein Wall of Text. Bring das in eine knappe Liste.
Folge-Prompt:
Mach aus den Findings eine Markdown-Tabelle:
| Datei | Zeile | Severity | Finding | Vorschlag |
Severity ist hoch, mittel, niedrig.
Hoch sind Bugs und Security-Probleme.
Mittel sind Konventions-Verletzungen.
Niedrig sind Style-Sachen und Geschmacksdinge.
Diese Tabelle kannst Du dann in den GitHub-PR-Kommentar pasten. Der Kollege sieht in einem Blick was wichtig ist und was Geschmack.
Schritt 5, jedes Finding selbst prüfen bevor Du es postest
Hier ist der wichtigste Schritt. Du postest nichts ungeprueft.
Claude Code halluziniert in Reviews regelmäßig. Er behauptet eine Funktion existiert nicht obwohl sie zwei Files weiter steht. Er reklamiert eine Validierung obwohl sie schon im Middleware-Layer passiert. Er sieht "doppelten Code" der gar nicht doppelt ist.
Ich gehe jede Tabellen-Zeile manuell durch. Bei Severity hoch immer das File öffnen und nachgucken. Bei Severity mittel reicht meistens die Zeile im Diff zu lesen. Bei Severity niedrig kann ich auch mal vertrauen aber nicht blind.
Was sich nicht hält fliegt raus. Lieber drei gute Findings als zehn mit zwei halluzinierten dazwischen.
Schritt 6, Tests lokal laufen lassen
Bevor Du den Review-Kommentar postet, fuehrst Du die Test-Suite des Repos einmal durch. Manchmal sieht der Diff sauber aus, aber der Branch ist trotzdem broken weil eine Migration fehlt oder eine Env-Var nicht gesetzt ist.
npm test
# oder
pnpm test
# oder was auch immer das Repo nutzt
Wenn Tests fehlschlagen, gehört das in Deinen Review-Kommentar. Ein PR der lokal die Tests bricht ist kein PR der gemerged werden sollte.
Tipp, wenn Du das Repo zum ersten Mal lokal hast und die Tests rot sind, frag erst ob das schon vorher so war. Du willst nicht den Kollegen für kaputte Tests blamen die seit zwei Wochen kaputt sind.
Schritt 7, Performance-Auffaelligkeiten visuell prüfen
AI-Code hat eine Eigenart. Er baut gerne unnoetige Loops, Redundanzen und O(n^2) Patterns weil das auf den ersten Blick funktioniert. Prüf das gezielt.
Im Diff in .review-diff.txt suche nach:
- verschachtelten for-Loops oder map-in-map
- await innerhalb einer for-Schleife (statt Promise.all)
- N+1 Queries gegen die DB
- sync File-Operations in async Funktionen
Wenn Du was findest, gib mir File und Zeile und schreib einen besseren Vorschlag.
Das findet 80 Prozent der Performance-Issues die der Reviewer sonst uebersieht. Die restlichen 20 Prozent erfordern Profile-Daten und gehören nicht in den ersten Pass.
Schritt 8, den Kommentar mit menschlicher Stimme schreiben
Was Du am Ende auf GitHub postest darf nicht wie AI-Output klingen. Erstens stört das Kollegen, zweitens ist es ehrlicher wenn Du Deine eigene Stimme nutzt.
Ich nehme die Tabelle aus Schritt 4, kuerze sie auf die Findings die nach Schritt 5 ueberlebt haben, und schreibe einen einleitenden Absatz selber. Sowas wie:
Hab den Diff durch. Drei Findings die ich blocken würde, zwei zur Diskussion. Tests laufen lokal grün. Die Migration in 003 würde ich nochmal anschauen, da ist ein Index der nie genutzt wird.
Diesen Einleitungs-Absatz schreibst Du selbst. Den Rest der Tabelle kannst Du aus dem Claude-Output kopieren, aber Du verantwortest jeden Eintrag.
Schritt 9, kontroverse Findings zur Diskussion stellen, nicht als Block
Manchmal ist nicht klar ob ein Finding wirklich ein Block ist oder Geschmack. Hier macht ein gutes Review den Unterschied.
Statt "das ist falsch" schreib "das würde ich anders machen, weil...". Statt "blockt Merge" schreib "kein Block, aber wäre mir einen Refactor wert". Der Kollege fühlt sich nicht angegriffen und Du behältst die Tür offen für eine echte Diskussion.
Claude Code formuliert oft direktiv. Das ist im Review-Setting zu hart. Bei der Uebernahme in Deinen Kommentar, weichst Du den Tone bewusst auf wo es passt. Faktisch hart bleiben bei Bugs und Security, weicher werden bei Style und Konvention.
Schritt 10, das Review-Setup aufraeumen
Letzter Schritt der oft vergessen wird. Du raeumst auf bevor Du den nächsten PR machst.
git checkout main
git branch -D review/pr-142
rm .review-diff.txt
Wenn Du das nicht machst, hast Du nach zwei Wochen 30 Review-Branches in Deinem lokalen Repo, ein paar .review-diff.txt Files herumliegen und Claude Code findet bei der nächsten Session eine alte .review-diff.txt die ihn verwirrt.
Ich hab für das Aufraeumen einen Slash-Command in ~/.claude/commands/review-cleanup.md der den Branch loescht und das Diff-File entfernt. Macht aus drei Befehlen einen.
Was als nächstes
Wenn Du diesen Loop drei, vier Mal durch hast, merkst Du wo Claude Code in Deinem Repo gut ist und wo nicht. Bei einigen Repos sind seine Architektur-Findings brauchbar, bei anderen nicht. Bei Tests ist er meistens zuverlaessig, bei Migrations und Infra-Code oft nicht.
Wenn Du den Loop ins Team bringen willst, schau Dir das Playbook Claude Code im Team, CLAUDE.md gemeinsam pflegen an. Da steht wie Du den Slash-Command /review-pr so verteilst dass alle den gleichen Output bekommen.
Wer einen Schritt weiter gehen will und Reviews automatisiert in der Pipeline laufen lassen mag, für den ist Claude Code Headless in CI/CD das richtige nächste Playbook. Achtung, Headless-Reviews haben andere Stolperfallen als interaktive, das ist eine eigene Disziplin.