Ein Claude, der den anderen prüft

Was es ist und warum es zählt

Wenn eine Claude-Code-Sitzung eine Aufgabe beendet und dir „fertig“ sagt, liegt es nahe, sie noch einmal prüfen zu lassen. Das bringt wenig. Sie hat diesen Code gerade geschrieben, sie weiß, warum sie es so gemacht hat, und wenn sie ihn noch einmal liest, sieht sie, was sie machen wollte, nicht, was sie wirklich gemacht hat.

Das ist derselbe blinde Fleck, den wir haben, wenn wir einen eigenen Text noch einmal lesen. Durch rutschen genau die Fehler, an die du beim Schreiben nicht gedacht hast: das leer gelassene Feld, der Doppelklick, der Nutzer, der die Daten eines anderen öffnet.

Deshalb lasse ich die Prüfung eine andere Sitzung machen, die ohne das Gespräch der ersten startet. Sie sieht nur die Änderungen und eine Aufgabe: herausfinden, wie man sie kaputt macht. Das sagt auch der offizielle Leitfaden von Claude Code: Eine Sitzung mit sauberem Kontext prüft Code besser, weil sie nicht an dem hängt, was sie gerade geschrieben hat.

Warum es zählt: Wenn du eine App baust, ohne Entwickler zu sein, hast du den Blick für diese Lücken noch nicht. Ein Reviewer, dessen Aufgabe es ist, den Code anzugreifen, sucht sie für dich, bevor deine Nutzer sie finden.

1. Der Prompt für den Reviewer

Das ist der Prompt, den ich in die zweite Sitzung einfüge, Wort für Wort. So wie er ist, funktioniert er vor dem Commit. Wenn du schon committet hast, schreib am Ende dazu, welche Dateien sie sich ansehen soll.

Du bist ein externer Reviewer. Du hast diesen Code nicht geschrieben und weißt nicht, warum er so gebaut ist: Frag nicht danach und such keine Rechtfertigungen. Schau dir nur die gerade gemachten Änderungen an: Führ git status und git diff aus und lies die neuen Dateien, die git status auflistet, vollständig (der Diff zeigt sie nicht). Deine einzige Aufgabe ist herauszufinden, wie man sie kaputt macht. Such nach:
- Eingaben: leere Felder, extrem lange Texte, seltsame Zeichen, negative Zahlen, Doppelklick, doppelte Anfragen;
- Berechtigungen: wer Daten sehen oder ändern kann, die nicht seine sind, was ohne Login oder mit dem Login eines anderen passiert;
- Grenzfälle: leere Listen, langsames oder fehlendes Netz, zwei Nutzer im selben Moment;
- Sicherheit: Schlüssel oder Passwörter im Code, Nutzerdaten ohne Prüfung verwendet, Fehler, die zu viel zeigen.
Schreib zu jedem Problem: wo (Datei und Zeile), wie ich es kaputt mache (die genauen Schritte), was passiert, Schweregrad (hoch, mittel, niedrig). Sortier vom schwersten an. Korrigier nichts und ändere keine Dateien: Ich will nur den Bericht.

Jedes Stück hat einen Grund.

• „Du hast diesen Code nicht geschrieben“: Ich nehme ihr die Rolle der Autorin. Wer etwas geschrieben hat, verteidigt es, ein externer Reviewer sucht die Fehler.
• „Führ git status und git diff aus und lies die neuen Dateien vollständig“: git diff zeigt nur Änderungen an Dateien, die git schon kennt. Neu angelegte Dateien findet sie mit git status, ohne diese Zeile blieben sie außen vor.
• „Deine einzige Aufgabe ist herauszufinden, wie man sie kaputt macht“: Ich frage nicht, ob der Code in Ordnung ist. Ich bitte sie, ihn anzugreifen, und das ist eine andere Frage.
• Die vier Bereiche, also Eingaben, Berechtigungen, Grenzfälle und Sicherheit, sind die Stellen, an denen schnell gebaute Apps am häufigsten kaputtgehen. Wenn deine App einen heiklen Teil hat, etwa Zahlungen, füg ihn als fünfte Zeile hinzu.
• „Wie ich es kaputt mache (die genauen Schritte)“: Ein Problem mit Schritten kannst du selbst in zwei Minuten prüfen. Ein „da könnte ein Problem sein“ nicht.
• „Korrigier nichts und ändere keine Dateien“: Der Reviewer meldet, er fasst nichts an. Würde er selbst korrigieren, hättest du zwei Sitzungen, die dieselben Dateien ändern, und wüsstest nicht mehr, wer was gemacht hat.

2. Wie ich ihn nutze

1. Wenn die erste Sitzung „fertig“ sagt, bitte ich sie nicht, sich selbst zu prüfen.
2. Ich öffne ein neues Terminal im selben Ordner und starte claude. Oder im selben Fenster: /clear startet ein neues Gespräch mit leerem Kontext. Das alte bleibt gespeichert, und du holst es mit /resume zurück.
3. Ich füge den Prompt ein. Vor dem Commit zeigen git status und git diff die gerade erledigte Arbeit. Nach dem Commit nenne ich ihr die Dateien.
4. Ich bringe den Bericht zur ersten Sitzung und lasse sie korrigieren, angefangen beim hohen Schweregrad.
5. Bei Login, Zahlungen und Nutzerdaten prüfe ich auch die Korrektur, in einer weiteren neuen Sitzung.

Ein Detail zu git diff: Es zeigt Änderungen an Dateien, die git schon kennt, neue Dateien sind also nicht dabei. Deshalb steht im Prompt git status, das sie auflistet, und der Reviewer liest sie vollständig. Wenn du sie lieber auch im Diff sehen willst, führ vor dem Öffnen des Reviewers git add -N . im Terminal aus: git merkt sie als hinzuzufügende Dateien vor, und ab dann tauchen sie in git diff auf.

Der Reviewer soll nicht schreiben können

Im Prompt steht, dass sie keine Dateien ändern soll, aber das ist eine Bitte, keine Sperre. Wenn ich sicher sein will, öffne ich die zweite Sitzung im plan mode:

claude --permission-mode plan

Im plan mode liest Claude Dateien und kann Befehle zum Erkunden ausführen, etwa git diff, ändert aber den Code nicht, bis du einen Plan genehmigst. Wenn sie dir am Ende einen Plan mit Korrekturen vorschlägt, genehmige ihn nicht: Der Bericht reicht dir. Ist die Sitzung schon offen, kommst du hinein, indem du Shift+Tab drückst, bis unten „plan mode on“ erscheint.

Den Bericht zurückbringen

In der ersten Sitzung füge ich den Bericht mit einem Prompt wie diesem ein:

Hier ist der Bericht eines externen Reviewers: [Bericht einfügen]. Korrigier zuerst die Probleme mit hohem Schweregrad, eins nach dem anderen. Sag mir bei jedem, was du geändert und wie du es geprüft hast. Die mit niedrigem Schweregrad fass nicht an: Über die entscheide ich.

Wenn ich /clear benutzt hatte, gehe ich zuerst mit /resume zum ursprünglichen Gespräch zurück, damit die Sitzung, die korrigiert, wieder den ganzen Kontext der Arbeit hat.

Die niedrigen behalte ich aus einem bestimmten Grund für mich. Ein Reviewer, den du bittest, Probleme zu finden, findet fast immer welche, auch wenn die Arbeit gut gemacht ist, weil du genau das verlangt hast. Wenn du alles korrigierst, hast du am Ende zusätzlichen Code für Fälle, die nie eintreten.

3. Mit einem Subagent, im selben Fenster

Wenn du kein weiteres Fenster öffnen willst, kann der Reviewer ein Subagent sein: ein Helfer, der in deiner Sitzung arbeitet, mit eigenem Kontext, und das Gespräch nicht sieht. Im Leitfaden zu den Subagents erkläre ich, wie du einen festen code-reviewer anlegst, der nur Werkzeuge zum Lesen hat.

Der Vorteil: Der Bericht geht direkt an die Sitzung zurück, die den Code geschrieben hat, ohne Kopieren und Einfügen. Das Risiko: Die Aufgabe für den Subagent schreibt Claude, und Claude weiß, warum es so gemacht wurde. Wenn Claude das erklärt, startet der Reviewer schon überzeugt. Deshalb bitte ich Claude, den Prompt unverändert weiterzugeben:

Lass die letzten Änderungen vom Subagent code-reviewer prüfen. Gib ihm diesen Prompt Wort für Wort weiter, ohne Erklärungen hinzuzufügen, wie oder warum du den Code geschrieben hast: [Prompt für den Reviewer einfügen]

Für die heiklen Teile nehme ich aber lieber die neue Sitzung: Dort füge ich den Prompt selbst ein und weiß genau, was der Reviewer bekommen hat.

Die goldene Regel

Nichts aus dem Gespräch davor: Wenn du ihr erklärst, warum du es so gemacht hast, gibt sie dir am Ende recht.

Das gilt auch für dich. Wenn du den Prompt einfügst, schreib nicht dazu „ich habe es so gemacht, weil …“. Gib ihr die Änderungen und die Aufgabe, mehr nicht. Erklärungen brauchst du später, wenn du entscheidest, welche Probleme du korrigierst.

Eine neue Sitzung liest trotzdem die Projektanweisungen (CLAUDE.md) und die automatische Erinnerung, wenn du sie nutzt. Das passt: Das sind Regeln, nicht die Geschichte, wie dieser Code entstanden ist.

Häufige Fehler

• Dieselbe Sitzung bitten, sich selbst zu prüfen: Öffne eine neue Sitzung oder nutze /clear, damit die prüfende Sitzung den Code nicht geschrieben hat.
• Dem Reviewer erklären, warum der Code so gebaut ist: Gib ihm nur die Änderungen und die Aufgabe, sonst gibt er dir am Ende recht.
• Den Reviewer korrigieren lassen: Verlang von ihm nur den Bericht und lass die Sitzung korrigieren, die den Code geschrieben hat.
• Jedes gemeldete Problem korrigieren: Fang beim hohen Schweregrad an und entscheide über die niedrigen selbst, sonst füllst du den Code mit unnötigen Absicherungen.
• Sich nur auf git diff verlassen, wenn es neue Dateien gibt: Im Diff tauchen sie nicht auf, also lass auch git status ausführen, wie im Prompt.
• Die Korrektur an heiklen Stellen nicht prüfen: Bei Login, Zahlungen und Nutzerdaten wiederhol die Prüfung in einer neuen Sitzung.

Checkliste

• Der Reviewer ist in einer neuen Sitzung
• Der Prompt ist ohne Erklärungen eingefügt
• Vor dem Commit: git status und git diff. Danach: die genannten Dateien
• Jedes Problem hat Ort, Schritte, Folge und Schweregrad
• Die Probleme mit hohem Schweregrad sind korrigiert und geprüft
• Die heiklen Teile hatten eine zweite Prüfung

Häufige Fragen