Prüfen und Review

Am Ende einer Aufgabe steht Code, der fertig aussieht. Ob er stimmt, ist eine zweite Frage. Warum ein Agent gerade dann aufhört und was als Prüfung taugt, erklärt Vibe-Coding / Agentic Engineering, Kapitel 07. Dieses Kapitel zeigt, wo Claude Code selbst prüft: welche Befehle und Dienste es dafür gibt, wer sie benutzen kann, was jeder davon sieht und was er kostet.

Warum ein frischer Kontext besser prüft

Die Sitzung, die eine Änderung geschrieben hat, kennt ihren Weg dorthin. Sie hat Dateien gelesen, Annahmen getroffen und Fehlversuche verworfen. Liest sie das Ergebnis noch einmal, liest sie es mit diesem Wissen. Die Empfehlungen von Anthropic (externe Seite, code.claude.com) halten fest, dass ein frischer Kontext den Review verbessert, weil Claude dann nicht zugunsten des Codes voreingenommen ist, den es gerade selbst geschrieben hat.

Ein Prüfer in einem frischen Subagent bekommt den Diff, also die Gegenüberstellung von altem und neuem Code, und die Maßstäbe, die man ihm mitgibt. Die Überlegungen, aus denen die Änderung entstand, fehlen ihm. Er beurteilt das Ergebnis deshalb aus eigener Sicht. Was ein Subagent beim Start sieht und was er zurückgibt, beschreibt Kapitel 20.

Die Doku zum Plugin security-guidance sagt dasselbe für Sicher­heits­prü­fungen. Das Plugin lässt nie dieselbe Claude-Instanz, die den Code geschrieben hat, ihn auch benoten (Doku zu security-guidance (externe Seite, code.claude.com)). Sein Prüfer beginnt beim Diff, hängt an keinem Lösungsweg und hat allein den Auftrag, Probleme zu finden.

Mit dem letzten Halbsatz beginnt auch die Schwäche des Verfahrens. Wer nur Probleme finden soll, meldet meistens welche. Davon handelt der letzte Abschnitt.

Vier Prüfer und wo sie laufen

Claude Code kennt vier Prüfwege. Sie unterscheiden sich darin, wann sie anspringen, wo sie rechnen und wer sie benutzen kann:

Dazu kommen zwei Sicher­heits­prü­fungen auf Abruf, /security-review und das Plugin Claude Security, und der Befehl /diff, mit dem man selbst hinsieht.

Der Review in der eigenen Sitzung

/code-review prüft einen Diff im Terminal und meldet Kor­rekt­heits­fehler, also Stellen, an denen der Code etwas anderes tut, als er soll (Doku zum Review im Terminal (externe Seite, code.claude.com)). Je nach Modell und Effort-Stufe meldet er zusätzlich Stellen zum Aufräumen: Code, der vorhandene Hilfsfunktionen nachbaut, sich einfacher schreiben ließe oder unnötig viel rechnet.

Ohne weitere Angabe prüft er die Commits des Branches, die noch nicht im Upstream liegen, und alle Änderungen, die noch nicht committet sind. Man kann ihm stattdessen eine Datei, eine PR-Nummer, einen Branch oder einen Bereich wie main...my-feature nennen.

Der Review läuft als Subagent im Hintergrund, mit eigenem Kontextfenster. Das Gespräch bleibt deshalb schlank. Seine Befunde kommen als Nachricht zurück, sobald er fertig ist. Mit --fix setzt er die Befunde danach im Arbeits­ver­zeichnis um. Mit --comment schreibt er sie an einen Pull Request auf GitHub oder an einen Merge Request auf GitLab.

Die Gründlichkeit wählt man über die Effort-Stufe, etwa mit /code-review high. Die Stufe tauscht Abdeckung gegen Gewissheit. Auf low meldet der Review nur die Befunde, bei denen er sich am sichersten ist, und damit weniger Fehlalarme. Von medium bis max sucht er breiter. Was die Stufen allgemein bewirken, steht in Kapitel 06.

Claude kann den Review auch selbst starten, wenn man in eigenen Worten um eine Prüfung bittet. Unter diesem Namen gibt es den Befehl seit Version 2.1.147 vom 21.05.2026 (Versionsliste (externe Seite, code.claude.com)). Vorher hieß er /simplify, räumte auf und setzte seine Funde gleich um. Wie die Namen wechselten, zeigt die dritte Ebene.

Ultrareview in der Cloud

Für einen gründlicheren Durchgang gibt es Ultrareview, aufgerufen mit /code-review ultra. Wo Ultrareview für das Konto freigeschaltet ist, gilt /ultrareview als zweiter Name dafür (Doku zu Ultrareview (externe Seite, code.claude.com)). Ultrareview ist eine Research Preview. Funktion, Preis und Verfügbarkeit können sich nach Angabe des Herstellers noch ändern.

Claude Code startet dafür eine Reihe von Prüf-Agenten in einer Sandbox in der Cloud, die im Branch oder im Pull Request nach Fehlern suchen. Jeden gemeldeten Befund stellt Ultrareview dort unabhängig nach und überprüft ihn. Ein Lauf dauert meist 15 bis 25 Minuten, das Terminal bleibt in der Zeit frei.

Ultrareview braucht eine Anmeldung mit einem Konto bei claude.ai, weil es als Sitzung in der Cloud läuft. Über Amazon Bedrock, Googles Agent Platform und Microsoft Foundry gibt es das nicht, in Organisationen mit Zero Data Retention oder HIPAA-Konfiguration ebenso wenig. Fehlt der Zugang, prüft /code-review ultra lokal in der eigenen Sitzung. Organisationen mit eigenen Schlüsseln für die Verschlüsselung (CMEK) können Ultrareview nicht starten. Ihnen bleibt /code-review.

Pro und Max haben drei Läufe frei, einmalig je Konto. Danach kostet ein Review meist 5 bis 25 Dollar, abgerechnet über Usage Credits, also Guthaben außerhalb des Kontingents im Tarif. Vor jedem Lauf zeigt ein Dialog den Umfang, die verbleibenden Freiläufe und die geschätzten Kosten. Ultrareview startet nur auf Aufruf, Claude stößt ihn nie von sich aus an.

Code Review an jedem Pull Request

Code Review ist ein Dienst für Organisationen. Er prüft Pull Requests auf GitHub und schreibt seine Befunde als Kommentare an die Zeilen, an denen er sie gefunden hat (Doku zu Code Review (externe Seite, code.claude.com)). Zu GitHub zählen dabei auch GitHub Enterprise Server und GitHub Enterprise Cloud mit Data Residency. Für Data Residency richtet eine Person mit der Rolle Owner die Anbindung wie bei GitHub Enterprise Server ein. Code Review steht Organisationen in den Tarifen Team und Enterprise offen. Organisationen mit Zero Data Retention oder HIPAA-Konfiguration bekommen ihn nicht. Wer eigene Schlüssel für die Verschlüsselung nutzt (CMEK), bekommt ihn noch nicht. Anthropic stellte den Dienst am 09.03.2026 vor (Vorstellung von Code Review (externe Seite, claude.com)).

Mehrere Agenten untersuchen den Diff und den Code darum herum gleichzeitig. Ein Prüfschritt hält die Kandidaten danach gegen den Code und sortiert Fehlalarme aus. Der Review liest dafür den Code. Gebaut oder ausgeführt wird dabei nichts. Jeder Befund hat eine Schwere: wichtig, Kleinigkeit oder ein Fehler, den es schon vor dem Pull Request gab (Doku zu Reviews am Pull Request (externe Seite, code.claude.com)). Hat der Review seine Überlegung festgehalten, hat der Befund einen zugeklappten Abschnitt mit der Begründung. Darin steht, warum Claude die Stelle meldet und wie es das Problem nachgeprüft hat. Über den Merge entscheidet weiter das Team, denn Code Review kann einen Pull Request weder freigeben noch blockieren.

Wie gründlich ein Review ist, legt eine Person mit der Rolle Owner über eine von drei Stufen fest: Quick, Standard oder Deep. Standard ist voreingestellt, Deep prüft am gründlichsten, dauert am längsten und kostet am meisten. Einen festen Preis je Review gibt es nicht (Doku zu den Kosten (externe Seite, code.claude.com)). Abgerechnet wird nach verbrauchten Token über Usage Credits, getrennt vom Kontingent des Tarifs. Die Kosten steigen mit der Prüfstufe, der Größe der Änderung, der Komplexität des Codes darum herum und der Zahl der Kandidaten, die geprüft werden müssen. Was in einem Projekt als wichtig gilt, regelt eine Datei REVIEW.md im Repository. Wie das geht, steht auf der zweiten Ebene.

Sicherheitsprüfungen beim Schreiben und auf Abruf

Am 06.08.2025 stellte Anthropic den Befehl /security-review vor, zusammen mit einer GitHub Action, die jeden neuen Pull Request auf Schwachstellen untersucht (Ankündigung (externe Seite, claude.com)). Der Befehl war für eine Prüfung im Terminal gedacht, bevor man committet. Heute untersucht er die Änderungen des aktuellen Branches gegenüber dem Standardbranch auf origin, etwa auf eingeschleusten Code, Fehler bei Anmeldung und Rechten und offengelegte Daten (Befehlsreferenz (externe Seite, code.claude.com)). Was die GitHub Action weglässt und wogegen sie ungeschützt ist, steht in Vibe-Coding / Agentic Engineering, Kapitel 11.

Schon während des Schreibens setzt das Plugin security-guidance an. Es lässt Claude die eigenen Änderungen während der Arbeit auf verbreitete Schwachstellen prüfen und das Gefundene in derselben Sitzung beheben (Doku zu security-guidance (externe Seite, code.claude.com)). Es prüft an drei Stellen, jede unterschiedlich gründlich: bei jeder Dateiänderung mit einem Musterabgleich ohne Modell, am Ende jeder Antwort mit einem Review durch das Modell und bei jedem Commit oder Push, den Claude selbst ausführt, mit einem Agenten, der auch den umgebenden Code liest. Das Plugin steht in allen Tarifen zur Verfügung. Aufhalten kann es nichts: Keine der drei Stellen blockiert eine Änderung oder einen Commit.

Für eine gründliche Suche in einem ganzen Repository gibt es das Plugin Claude Security. Ein Team aus Agenten erfasst die Architektur, baut ein Bedrohungsmodell, sucht Schwachstellen und lässt jeden Befund unabhängig prüfen, bevor der Bericht entsteht (Doku zu Claude Security (externe Seite, code.claude.com)). Daraus entstehen Patches, die man selbst anwendet. Automatisch angewendet wird keiner.

Wann Prüfen zu viel wird

Jeder Prüflauf kostet Zeit oder Geld, und die Spanne ist groß. Die Doku zu Ultrareview stellt die beiden Befehle in einer Tabelle nebeneinander.

Quelle: Doku zu Ultrareview (externe Seite, code.claude.com), Stand 15.10.2026. Dazu kommt Code Review, abgerechnet nach Verbrauch über Usage Credits. Wer Code Review bei jedem Push laufen lässt, bekommt die meisten Reviews, die Kosten wachsen mit der Zahl der Pushes. In einem neu hinzugefügten Repository ist genau das voreingestellt (Doku zur Einrichtung (externe Seite, code.claude.com)). Beim Plugin security-guidance kostet der Musterabgleich nichts. Die beiden Reviews durch das Modell zählen zum Verbrauch wie jede andere Anfrage an Claude.

Neben Zeit und Geld kosten Fehlalarme Arbeit. Ein Prüfer, der Lücken finden soll, meldet meistens welche, auch bei solider Arbeit (Empfehlungen (externe Seite, code.claude.com)). Wer jedem Befund nachgeht, baut zu viel: zusätzliche Schichten, Abwehrcode und Tests für Fälle, die nie eintreten können. Wie man den Auftrag an einen Prüfer dagegen eingrenzt, steht in Vibe-Coding / Agentic Engineering, Kapitel 07. Claude Code hat dafür drei Stellschrauben: die Stufe low bei /code-review, die Zahl der gemeldeten Befunde mit --max-findings seit Version 2.1.288 vom 02.10.2026 und bei Code Review eine REVIEW.md mit Regeln für die Menge der Kleinigkeiten. Die Doku schlägt dort zum Beispiel eine Obergrenze von fünf Kleinigkeiten je Review vor (Doku zum Anpassen von Code Review (externe Seite, code.claude.com)). Ein späterer Review, der etwa nach einem Push von selbst startet, konzentriert sich auf das, was sich seit dem letzten geändert hat, und meldet weniger Kleinigkeiten.

Wie oft /code-review oder Ultrareview danebenliegen, beziffert die Doku nicht. Für Code Review nennt Anthropic in der Vorstellung vom 09.03.2026 eine Zahl aus dem eigenen Haus: Weniger als ein Prozent der Befunde markierten die eigenen Entwickler als falsch (Vorstellung von Code Review (externe Seite, claude.com)). Das ist eine Angabe des Herstellers über sein eigenes Produkt, erhoben in mehreren Monaten an Anthropics eigenen Pull Requests. Wie Fehlalarme gezählt wurden, steht dort nicht.

Statt eines Befehls geht auch eine zweite Sitzung, die nur prüft, was die erste geschrieben hat. Dieses Muster beschreibt die dritte Ebene. Wie zwei Sitzungen getrennt nebeneinander laufen, zeigt Kapitel 21. Wie ein Workflow seine Agenten die Befunde der anderen prüfen lässt, zeigt Kapitel 22.

Die erste Ebene hat die vier Prüfwege vorgestellt. Hier geht es um die Bedienung. Welche Schalter kennt /code-review, und wo legt er seine Befunde ab? Was lädt Ultrareview von der eigenen Maschine hoch? Wie stellt eine Organisation Code Review auf ihr Projekt ein, und wie erweitert man die Schichten von security-guidance?

Ziel, Stufe und Schalter von /code-review

Die Befehlsreferenz fasst die Schreibweise in eine Zeile (Befehlsreferenz (externe Seite, code.claude.com)):

/code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [--max-findings n|all|default] [pr#|branch|path]

Der Befehl hat einen zweiten Namen, /review. Vor Version 2.1.223 vom 06.08.2026 war /review ein eigener Befehl, der einen Pull Request auf GitHub in einem Durchgang nur gelesen hat (Doku zum Review im Terminal (externe Seite, code.claude.com)). Von Version 2.1.186 bis 2.1.201 nahm er dafür kurz das Verfahren von /code-review medium, die dritte Ebene ordnet das ein.

Die Stufe merkt er sich. Ohne Angabe nimmt der Review die Stufe von low bis max, die man zuletzt getippt hat, auch in einer früheren Sitzung. Claude Code meldet das mit einem Hinweis. Eine Stufe in einem Lauf mit -p ändert die gemerkte nicht, ultra benutzt sie nicht und überschreibt sie nicht. Hat man nie eine Stufe getippt, gilt der Effort der Sitzung. Vor Version 2.1.223 galt der immer.

Die Zahl der Befunde. Mit --max-findings 20 meldet der Review bis zu zwanzig Befunde, mit --max-findings all jeden. Spätere Reviews übernehmen den Wert, bis man --max-findings default angibt. Das braucht Version 2.1.288 vom 02.10.2026 oder neuer. Die Versionsliste (externe Seite, code.claude.com) beschreibt den Schalter als Weg, mehr oder weniger Befunde zu melden als die übliche Grenze. Wie hoch die übliche Grenze liegt, nennt die Doku für einen Fall: Meldet der Review über das Werkzeug für die Befundliste, etwa in der Desktop-App, sind es 32.

Befunde umsetzen. --fix übernimmt die Befunde nach dem Review ins Arbeits­ver­zeichnis. Läuft der Review im Hintergrund, macht /rewind diese Änderungen nur an Dateien rückgängig, die Claude im Gespräch schon selbst bearbeitet hatte. Die übrigen nimmt man mit Git zurück. Läuft er im Vordergrund, stellt /rewind den Stand wie gewohnt wieder her. Wie /rewind arbeitet, steht in Kapitel 03.

Befunde an Pull Request oder Merge Request. --comment schreibt sie als Kommentare an die Zeilen eines Pull Requests auf GitHub. Bei einem Merge Request auf GitLab werden sie eine einzige Notiz, geschrieben über das Programm glab, ab Version 2.1.257. Fehlt glab, landen die Befunde im Terminal. Den Merge Request gibt man als Adresse oder in der Form !123 an. Eine bloße Nummer oder einen Branchnamen nimmt Claude Code nur als Merge Request, wenn origin auf gitlab.com liegt.

Was der Review liest. Er folgt der CLAUDE.md wie jede Sitzung. Die Datei REVIEW.md, die Code Review am Pull Request steuert, liest er nicht.

Ein Skill im eigenen Subagent. /code-review ist ein mitgelieferter Skill, der in einem eigenen Subagent läuft. Die Doku nennt das einen forked subagent. Der Name führt in die Irre. Ein Skill dieser Art läuft gerade in keinem Fork des Gesprächs, der den bisherigen Verlauf mitnähme (Doku zu Skills (externe Seite, code.claude.com)). Sein Subagent sieht den Verlauf nicht und arbeitet allein mit dem Auftrag des Skills. Das ist der frische Kontext aus der ersten Ebene. Was ein echter Fork mitnimmt, erklärt Kapitel 20.

Vordergrund statt Hintergrund. Seit Version 2.1.218 vom 22.07.2026 läuft der Review im Hintergrund, vorher lief er im Gespräch. Für die Stufen high, xhigh und max gilt das seit Version 2.1.232 vom 13.08.2026. Im Vordergrund läuft er zum Beispiel in diesen Fällen:

• wenn ein früherer Review noch läuft,
• im Lauf ohne Terminal mit -p und über das Agent SDK,
• wenn die Umgebungsvariable CLAUDE_CODE_DISABLE_BACKGROUND_TASKS auf 1 steht.

Wer den Review startet. Claude kann ihn von selbst anstoßen, und eine geplante Aufgabe der laufenden Sitzung mit /code-review als Prompt fährt ihn ebenfalls. Den Review in der Cloud startet eine solche Aufgabe nie. Wer den Befehl nur von Hand haben will, setzt in den Einstellungen skillOverrides für code-review auf user-invocable-only. Dann starten ihn weder Claude noch geplante Aufgaben. Wie Skills generell aufgerufen werden, behandelt Kapitel 17.

In der Desktop-App erscheinen die Befunde ab Version 2.1.218 als Liste mit Fundstelle, einem Satz Zusammenfassung und einer Art wie correctness. Behebt Claude sie später in der Sitzung, markiert die Liste jeden Befund als behoben, übersprungen oder ohne Änderung erledigt.

Der Aufräum-Review

/simplify prüft geänderten Code auf Aufräumarbeit und setzt sie gleich um. Vier Agenten laufen dafür parallel (Befehlsreferenz (externe Seite, code.claude.com)). Sie suchen:

• vorhandene Hilfsfunktionen, die neu geschrieben wurden,
• Stellen, die sich einfacher schreiben lassen,
• unnötigen Rechenaufwand,
• Änderungen auf der falschen Abstraktionsebene.

Kor­rekt­heits­fehler gehören nicht zu seinem Auftrag, für sie verweist die Referenz auf /code-review.

Der Name hat eine Vorgeschichte. Vor Version 2.1.147 hieß /code-review selbst /simplify und setzte seine Befunde in der Voreinstellung um. Wer /simplify in einem Skript zur Fehlersuche benutzt hat, soll laut Doku auf /code-review --fix umstellen. Die Folge der Umbenennungen steht auf der dritten Ebene.

Mit /simplify kam am 28.02.2026 in Version 2.1.63 auch /batch (Versionsliste (externe Seite, code.claude.com)). Er gehört zum parallelen Arbeiten. Er zerlegt eine große Änderung in 5 bis 30 unabhängige Teile und legt einen Plan vor. Nach der Freigabe setzt je Teil ein Subagent im Hintergrund die Arbeit um, jeder in einem eigenen Worktree. Wie Worktrees die Teile auseinanderhalten, steht in Kapitel 21.

Was Ultrareview hochlädt und wann es abbricht

Ohne Argument vergleicht Ultrareview den aktuellen Branch mit dem Standardbranch, samt allen Änderungen, die noch nicht oder schon für den nächsten Commit vorgemerkt sind (Doku zu Ultrareview (externe Seite, code.claude.com)). Für einen Branch packt Claude Code den Stand des Repositorys und lädt ihn in die Sandbox. Dabei gelten die Regeln für Sitzungen in der Cloud, auch für Dateien, die wie Zugangsdaten heißen, etwa .env. Ein anderer Vergleichsstand geht mit einem Namen dahinter, etwa /code-review ultra develop. Ab Version 2.1.218 nimmt der Befehl auch einen Satz in eigenen Worten an, etwa /code-review ultra check my auth changes, und bezieht die Befunde darauf.

Bei einem Pull Request auf github.com lädt Claude Code nichts von der eigenen Maschine hoch. Die Sandbox klont den Pull Request selbst, mit dem GitHub-Konto, das mit dem Claude-Konto verbunden ist. Verbunden wird es mit /web-setup. Für GitHub Enterprise Server gibt es den Weg über die PR-Nummer nicht, dort prüft man den lokalen Branch.

Ultrareview prüft den Diff, bevor ein Agent startet, und lehnt in vier Fällen ab oder fragt nach:

• zu groß: In der Voreinstellung sind es höchstens 500 geänderte Dateien und 8.000 geänderte Zeilen. Die Werte können sich ändern, die Absage nennt die gültigen.
• nichts zu prüfen: Der Diff gegen den Vergleichsstand ist leer.
• erster Commit: Ultrareview prüft dann jede Datei, nach Bestätigung im Dialog, seit Version 2.1.277.
• keine gemeinsame Geschichte: Ultrareview prüft dann jede Datei unter Versionskontrolle, ebenfalls erst nach Bestätigung.

Abgerechnet wird ab dem Start der Sitzung in der Cloud. Ein Lauf, den man abbricht oder der scheitert, verbraucht trotzdem einen Freilauf, ein bezahlter Lauf kostet nur den Teil, der lief. Bezahlte Läufe brauchen eingeschaltete Usage Credits, sonst sperrt Claude Code den Start. Die Bestätigung der Abrechnung kommt einmal je Gespräch, nach /clear also erneut.

Laufende Reviews zeigt /tasks. Dort lässt sich einer auch anhalten, dann archiviert Claude Code die Sitzung in der Cloud und gibt keine Teilergebnisse zurück.

Ab Version 2.1.227 kann Claude die fertigen Befunde an einen Pull Request auf github.com schreiben, als einen einfachen Kommentar vom eigenen GitHub-Konto. Bei GitHub zählt der Kommentar weder als Review noch als Freigabe. Geschrieben wird nur, wenn man es für diesen Lauf wählt, mit --post ist die Wahl im Dialog vorbelegt. Die Sitzung muss offen bleiben, bis der Review fertig ist, sonst schreibt Claude Code nichts.

Ultrareview aus einem Skript

Für CI und Skripte gibt es den Unterbefehl claude ultrareview, eingeführt mit Version 2.1.120 vom 28.04.2026 (Versionsliste (externe Seite, code.claude.com)). Er startet denselben Review, wartet, bis er fertig ist, und schreibt die Befunde auf die Standardausgabe.

# aktueller Branch gegen den Standardbranch
claude ultrareview
# Pull Request 1234 auf github.com
claude ultrareview 1234
claude ultrareview origin/main --json --timeout 60

--json gibt die Befunde roh aus, --timeout setzt die Wartezeit in Minuten, voreingestellt sind 45. Der Rückgabewert lautet:

• 0, wenn der Review fertig wurde, mit oder ohne Befunde,
• 1 bei einem Fehlstart, einem Abbruch oder abgelaufener Zeit,
• 130 nach Ctrl-C.

Ein Aufruf mit claude -p '/code-review ultra' wartet dagegen nicht auf die Befunde. Endet der Unterbefehl vorher, erreichen die Befunde das Terminal nie. Ein zweiter Aufruf startet einen neuen Review und kostet erneut. Wie Claude Code sonst ohne Terminal läuft, behandelt Kapitel 29.

Code Review einrichten

Code Review schaltet eine Person mit der Rolle Owner einmal für die Organisation ein, unter claude.ai/admin-settings/claude-code. Dazu gehört die Claude GitHub App, die das Repository lesen und an Pull Requests schreiben darf (Doku zu Code Review (externe Seite, code.claude.com)). Wie gründlich ein Review ist, legt die Person mit der Rolle Owner über eine von drei Stufen fest: Quick, Standard oder Deep. Standard ist voreingestellt. Die Stufe gilt für die ganze Organisation, ein einzelnes Repository kann eine eigene bekommen. Je Repository wählt man außerdem, wann ein Review läuft (Doku zur Einrichtung (externe Seite, code.claude.com)):

• einmal nach dem Öffnen eines Pull Requests,
• nach jedem Push auf den Branch des Pull Requests, mit den meisten Reviews und den höchsten Kosten,
• von Hand, über einen Kommentar.

In einem neu hinzugefügten Repository läuft der Review in der Voreinstellung nach jedem Push.

Der Kommentar @claude review startet in jedem Modus einen einzelnen Review (Doku zu Reviews am Pull Request (externe Seite, code.claude.com)). @claude review always meldet den Pull Request zusätzlich für alle späteren Pushes an. Bis zu einer Änderung im Juli 2026 hat schon der kurze Befehl den Pull Request angemeldet. Der Kommentar gehört in den Verlauf des Pull Requests, mit dem Befehl am Anfang, und braucht jemanden mit Schreibrecht im Repository. Ein Kommentar an einer einzelnen Codezeile startet keinen Review. Entwürfe und Pull Requests aus einem Fork prüft Code Review nur auf diesen Kommentar hin.

Das Ergebnis erscheint zusätzlich als Prüflauf neben den eigenen CI-Prüfungen. Dieser Lauf endet neutral oder als übersprungen. Eine vorgeschriebene Prüfung scheitert deshalb nie an ihm. Nach manchen Pushes behält Code Review das Ergebnis des früheren Reviews und startet keinen neuen. Dafür muss der Pull Request noch dieselben Zeilen hinzufügen und entfernen, etwa nach einem leeren Commit, einem sauberen Merge des Zielbranchs oder einem sauberen Rebase. Außerdem darf seit dem Review niemand den Faden eines Befunds der Stufe Important aufgelöst haben. Einen neuen Review ohne Änderung am Code holt der Kommentar @claude review oder ein Neustart des Prüflaufs. Verlangt der Branchschutz, dass alle Diskussionen aufgelöst sind, muss man die Fäden der Befunde vor dem Merge allerdings auflösen. Wer Merges von den Befunden abhängig machen will, liest die letzte Zeile des Prüflaufs in der eigenen CI aus. Sie enthält die Zahl der Befunde je Schwere in maschinenlesbarer Form. Vorher gehört der Titel des Prüflaufs gelesen: Beginnt er mit Code review not repeated, hat Code Review ein früheres Ergebnis mit offenen Befunden der Stufe Important behalten, und die Zeile mit den Zahlen fehlt. Eine Übersicht unter claude.ai/analytics/code-review zeigt geprüfte Pull Requests und Kosten, eine Obergrenze für die Ausgaben im Monat setzt man unter claude.ai/admin-settings/usage (Doku zu den Kosten (externe Seite, code.claude.com)). Reicht diese Obergrenze, die der ganzen Organisation oder das Guthaben an Usage Credits nicht mehr für die erwarteten Kosten eines Reviews, lässt Code Review ihn aus und schreibt das in einem Kommentar an den Pull Request.

Was REVIEW.md einstellt

Code Review liest zwei Dateien aus dem Repository (Doku zum Anpassen von Code Review (externe Seite, code.claude.com)). Die CLAUDE.md gilt als Kontext des Projekts. Verstößt eine Änderung gegen eine Regel darin, wird daraus ein Befund mit der Schwere, die zum Problem passt.

REVIEW.md im Wurzelverzeichnis gilt nur für Reviews. Die Agenten, die Befunde suchen und prüfen, bekommen ihren Inhalt als Anweisung. Der Schritt, der den Review am Ende schreibt, schlägt darin nach, bevor er die Schwere festlegt. Eine weitere REVIEW.md in einem Unterordner ergänzt Prüfungen für Änderungen unter diesem Pfad. Die Doku ordnet ihre Anweisungen fünf typischen Problemen zu, darunter diese:

• Schwere: festlegen, was im Projekt als wichtig gilt. Für ein Repository mit Dokumentation oder einen Prototyp ist das enger als für Produktionscode.
• Menge der Kleinigkeiten: eine Obergrenze je Review, etwa fünf.
• Auslassungen: Pfade und Arten von Befunden ohne Meldung, etwa erzeugten Code, Lockfiles und alles, was die CI schon prüft.
• Beweislast: Eine Aussage über das Verhalten des Codes braucht eine Fundstelle mit Datei und Zeile. Ein Schluss aus Namen genügt nicht. Das spart Fehlalarme.

In die REVIEW.md gehören nur Anweisungen, die das Verhalten des Reviews ändern. Allgemeiner Kontext des Projekts gehört in die CLAUDE.md.

Welche Fassung gilt. Code Review liest die REVIEW.md aus dem Basisbranch des Pull Requests oder aus dem Standardbranch. Die Fassung im Pull Request selbst bleibt dabei außen vor. Eine neue Regel wirkt deshalb erst nach dem Merge. Drei Anweisungen befolgt der Review nur aus der Wurzeldatei auf einem geschützten Standardbranch: eine Schwere herabsetzen, etwas auslassen und die Kleinigkeiten deckeln. Kann Code Review den Schutz der Branches nicht bestätigen, liest es gar keine REVIEW.md.

Die drei Schichten von security-guidance

Das Plugin kommt aus dem offiziellen Marktplatz von Anthropic:

/plugin install security-guidance@claude-plugins-official

Ein Team schaltet es für ein Repository über enabledPlugins in .claude/settings.json ein, eine Organisation über die verwalteten Einstellungen. Sitzungen in der Cloud laden es weder aus den eigenen Einstellungen noch aus der .claude/settings.json des Repositorys. Es braucht Python 3.7 oder neuer, der Review mit Agent beim Commit Python 3.10. Gebaut ist es aus Hooks, die an festen Stellen des Ablaufs eigenen Code starten (Doku zu security-guidance (externe Seite, code.claude.com)). Was ein Hook ist und an welchen Stellen er greift, erklärt Kapitel 18.

• Muster, nach jeder Dateiänderung: Abgleich mit riskanten Aufrufen wie eval(, pickle, .innerHTML = und Änderungen unter .github/workflows/, ohne Modell. Grenze: eine Warnung je Muster, Datei und Sitzung.
• Ende jeder Antwort, im Hintergrund: getrennter Review des ganzen Diffs dieser Antwort, auch was Bash und Subagents geändert haben. Grenze: bis 30 Dateien, höchstens dreimal hintereinander.
• Commit und Push, wenn Claude über Bash committet oder pusht: Review mit Agent, der Aufrufer und umgebenden Code liest. Grenze: 20 je Stunde.

Quelle: Doku zu security-guidance (externe Seite, code.claude.com), Stand 12.10.2026. Commits, die man selbst in der Shell absetzt, prüft die dritte Schicht nicht, auch nicht über ! in der Sitzung. Die beiden Reviews mit Modell nehmen in der Voreinstellung Claude Opus 4.7. SECURITY_REVIEW_MODEL und SG_AGENTIC_MODEL wählen ein anderes.

Eigene Regeln kommen über zwei Dateien dazu. .claude/claude-security-guidance.md beschreibt in Worten, wovor sich das Projekt schützen muss, die Reviews mit Modell lesen sie zusätzlich. .claude/security-patterns.yaml ergänzt den Musterabgleich um eigene Zeichenfolgen und reguläre Ausdrücke, bis zu 50 Regeln. Beide Dateien können nur Prüfungen hinzufügen. Eine Regel, die eine Art von Schwachstelle ausnehmen soll, unterdrückt nichts. Wer eine Änderung hart verhindern will, braucht einen Hook, der sie blockiert, oder eine Prüfung in der CI. Abschalten lässt sich jede Schicht einzeln über Umge­bungs­va­ria­blen, etwa ENABLE_STOP_REVIEW=0 für den Review am Ende jeder Antwort, das ganze Plugin über SECURITY_GUIDANCE_DISABLE=1.

Den Diff selbst ansehen

Der Befehl /diff zeigt die Änderungen im Arbeits­ver­zeichnis, die von Claude und alles andere, was noch nicht committet ist (Doku zum interaktiven Modus (externe Seite, code.claude.com)). In der Voll­bild­dar­stel­lung öffnet er ein Panel neben dem Gespräch. Es bleibt offen und erneuert sich, sobald Claude eine Datei ändert oder einen Shell-Befehl ausführt. In der klassischen Darstellung öffnet er einen Dialog über der Eingabe. Version 2.1.260 vom 03.09.2026 brachte das Panel (Versionsliste (externe Seite, code.claude.com)). Heute braucht es Version 2.1.287 oder neuer, ein Git-Repository und ein Terminal mit mindestens 110 Spalten. Wie man die Voll­bild­dar­stel­lung einschaltet, steht in Kapitel 03.

Zwei Griffe machen das Panel zu einem Werkzeug für den Review. Ein Klick auf ask neben einer Datei hängt ihren Diff an den nächsten Prompt, man fragt Claude dann gezielt nach dieser Änderung. Über die Auswahl im Kopf zeigt das Panel die Änderungen einer einzelnen Antwort, beschriftet mit T1, T2 und so weiter. Diese Ansicht stammt aus den Dateiwerkzeugen von Claude. Was Claude über einen Shell-Befehl geändert hat, erscheint nur unter Current, der Ansicht des Arbeits­ver­zeich­nisses.

Die Prüfbefehle von Claude Code haben seit Mai 2026 mehrmals Namen und Verhalten gewechselt. Diese Ebene ordnet die Schritte, klärt die Namen und hält die Zahlen, die es zu den Diensten gibt, gegen ihre Herkunft.

Die Prüfwege in Versionen

Die Daten stammen aus der Versionsliste (externe Seite, code.claude.com). Wo ein Schritt nur in einer Ankündigung oder in einer Wochenübersicht der Doku steht, ist die Quelle in der Zeile genannt.

Zu Claude Code Security steht die Quelle im nächsten Abschnitt, zu Code Review die Vorstellung (externe Seite, claude.com). Das Plugin security-guidance stellt die Wochenübersicht für die Woche 22 (externe Seite, code.claude.com) vor. Ab welcher Fassung das Plugin im Marktplatz stand, sagt sie nicht.

Laut der Ankündigung vom 06.08.2025 standen /security-review und die GitHub Action ab diesem Tag allen Nutzern von Claude Code zur Verfügung. Laut Ankündigung prüft der Befehl mit einem eigenen Prompt, der auf verbreitete Muster von Schwachstellen zielt.

Ein Befehlsname mit drei Bedeutungen

An /simplify lässt sich ablesen, wie Anthropic Prüfen und Aufräumen erst zusammengelegt und dann wieder getrennt hat. Im Februar 2026 kam der Befehl als Aufräumhilfe. Mit Version 2.1.147 vom 21.05.2026 bekam er den Namen /code-review und eine neue Aufgabe: Er meldet Kor­rekt­heits­fehler auf einer gewählten Stufe, das alte Aufräumen entfiel. Sechs Tage später setzte /code-review --fix die Befunde wieder um, samt Vorschlägen zum Aufräumen, und /simplify war nur noch ein zweiter Weg dorthin. Am 28.05.2026 kam /simplify als eigener Aufräum-Review zurück, der nach Wiederverwendung, Vereinfachung, Effizienz und Abstraktionsebene sucht.

Die Wochenübersicht für die Woche 21 (externe Seite, code.claude.com) fasst die Woche bis zum 22.05.2026 anders zusammen. Dort heißt es, /simplify bleibe als eigener Aufräum-Review bestehen. Nach der Versionsliste gab es diesen Aufräum-Review zwischen Version 2.1.147 und 2.1.154 nicht. Eine Anleitung aus dieser Woche kann deshalb mit /simplify etwas anderes meinen als heute.

Auch /review hat dreimal die Aufgabe gewechselt. Bis Juni 2026 las der Befehl einen Pull Request in einem Durchgang. Von Version 2.1.186 bis 2.1.201 nahm er den Review von /code-review medium mit mehreren Agenten, ab 2.1.202 wieder den schnellen Durchgang. Seit Version 2.1.223 vom 06.08.2026 ist er nur noch ein zweiter Name für /code-review (Befehlsreferenz (externe Seite, code.claude.com)).

Von ultrareview zu code-review ultra

Die Doku führt heute /code-review ultra als Befehl und /ultrareview als zweiten Namen. Die Befehlsreferenz nennt /code-review ultra den bevorzugten Aufruf (Befehlsreferenz (externe Seite, code.claude.com)). Einen Eintrag, der diese Umstellung ankündigt, enthält die Versionsliste nicht. Sie zeigt drei Spuren:

• 10.06.2026, Version 2.1.172: /code-review lässt die Option ultra auch ohne Anmeldung bei claude.ai stehen und erklärt, dass der Review in der Cloud ein solches Konto braucht. Das ist die erste Erwähnung von ultra als Option. Wann die Option kam, steht dort nicht.
• 06.08.2026, Version 2.1.223: Der Eintrag, der /review zum zweiten Namen macht, verweist für einen tiefen Review in der Cloud auf /code-review ultra.
• bis 08.10.2026, Version 2.1.295: Die Fehlerbehebungen am Hochladen sprechen weiter von /ultrareview, und auch der Tipp im Terminal wirbt in Version 2.1.296 noch mit dem alten Namen.

Belegen lässt sich damit, dass /code-review ultra spätestens am 10.06.2026 existierte und seit dem 06.08.2026 der empfohlene Weg ist. Den Tag, an dem die Doku die Rollen der beiden Namen tauschte, belegt die Versionsliste nicht.

Ultrareview selbst kam mit Version 2.1.111 am 16.04.2026. Die Versionsliste beschreibt es als Review in der Cloud mit paralleler Analyse durch mehrere Agenten und einer Kritik der Befunde. Die Wochenübersicht für die Woche 16 (externe Seite, code.claude.com) nennt diesen Schritt einen Durchgang, in dem die Befunde gezielt angegriffen werden. Die heutige Doku zu Ultrareview (externe Seite, code.claude.com) spricht vom unabhängigen Nachstellen und Prüfen jedes Befundes.

Mehr Agenten und wieder weniger

Die Versionsliste zeigt zwei Bewegungen, die in entgegengesetzte Richtungen laufen. Ultrareview, Code Review und das Plugin Claude Security setzen auf viele Agenten und eine eigene Prüfung jedes Befundes. Bei /code-review im Terminal ging Anthropic zweimal den umgekehrten Weg:

• 29.06.2026, Version 2.1.196: Fünf Prüfer für Aufräumarbeit wurden einer. Nach Angabe der Versionsliste sank der Verbrauch an Token dadurch um rund 25 Prozent.
• 17.09.2026, Version 2.1.274: Für jedes Modell ohne eigene abgestimmte Einstellungen nimmt /code-review schlankere Prompts im Review, statt viele Review-Subagents zu starten.

Am 05.10.2026 folgte mit Version 2.1.290 eine Ergänzung für genau diese Modelle, darunter Opus 5.5 und Sonnet 5.5: Auf medium meldet der Review dort auch Aufräumarbeit und Verstöße gegen die Regeln der CLAUDE.md. Wie viele Agenten ein Review auf welcher Stufe und mit welchem Modell startet, legt die Doku nicht offen. Zu den Kosten sagt sie für /code-review nur, dass er zum normalen Verbrauch zählt.

Was die Zahlen zu Code Review hergeben

Für Code Review hat Anthropic bei der Vorstellung am 09.03.2026 Zahlen genannt (Vorstellung von Code Review (externe Seite, claude.com)). Alle stammen aus mehreren Monaten Einsatz an Anthropics eigenen Pull Requests vor der Vorstellung. Es sind Angaben des Herstellers über sein eigenes Produkt.

Quelle: Vorstellung von Code Review (externe Seite, claude.com), Stand 09.03.2026.

Die Zahlen messen die Menge der Befunde und die Zustimmung der eigenen Entwickler. Wie viele Fehler Code Review übersieht, bleibt offen, ebenso, wie ein Befund als falsch markiert wird. Die Doku hält dazu fest, dass Code Review Fehler und Sicherheitslücken übersehen kann (Doku zu Code Review (externe Seite, code.claude.com)). Ein Review ohne Befund heißt laut Doku nicht, dass der Code fehlerfrei oder sicher ist. Der Anstieg von 16 auf 54 Prozent, den Anthropic für die eigenen Pull Requests angibt, misst, wie viele Pull Requests überhaupt einen inhaltlichen Kommentar bekommen. Ob das die Fehler im ausgelieferten Code verringert hat, ist damit noch nicht gemessen. Die Vorstellung nennt dazu Einzelfälle, etwa eine einzeilige Änderung an einem Produktionsdienst. Sie hätte die Anmeldung gebrochen und wurde vor dem Merge behoben.

Ein Rückkanal läuft über die Antworten im Pull Request. Der nächste Review liest die Antworten auf seine früheren Befunde und kann den Faden auflösen oder einmal nachfragen (Doku zu Reviews am Pull Request (externe Seite, code.claude.com)). Die Übersicht der Organisation zählt laut Doku zu den Kosten (externe Seite, code.claude.com), wie viele Kommentare sich von selbst erledigt haben, weil jemand die Stelle behoben hat. Eine Quote für Fehlalarme führt die Doku dort nicht auf.

Claude Code Security und das Plugin Claude Security

Am 20.02.2026 stellte Anthropic Claude Code Security vor, eine Funktion von Claude Code im Web. Sie durchsucht ein Repository nach Schwachstellen und schlägt Patches vor, die ein Mensch prüft (Ankündigung (externe Seite, anthropic.com)). Sie startete als begrenzte Research Preview für Kunden mit Enterprise und Team. Betreuer von Open-Source-Projekten konnten sich für einen kostenlosen, schnelleren Zugang bewerben. Jeder Befund durchläuft dort mehrere Prüfstufen, in denen Claude ihn zu belegen oder zu widerlegen versucht.

Die Doku führt heute zwei Dinge unter dem Namen Claude Security. Das eine ist ein Plugin, das in der eigenen Sitzung läuft. Das andere ist ein verwaltetes Produkt im Tarif Enterprise, das verbundene Repositorys überwacht (Doku zu Claude Security (externe Seite, code.claude.com)). Ob das verwaltete Produkt die Funktion vom Februar fortführt, sagt die Doku nicht. Das Plugin braucht einen bezahlten Tarif, Zugang zur API oder einen Cloud-Anbieter, weil es seine Agenten über Workflows steuert. Im Tarif Pro schaltet man die Workflows dafür in /config ein. Die Agenten laufen auf dem Modell der Sitzung, und jeder Lauf zählt zum Verbrauch.

Zwei Läufe über denselben Code können verschiedene Befunde liefern. Die Doku rät deshalb zu regelmäßigen Läufen. Jeder Bericht hält fest, welchen Commit er geprüft hat. Die Doku zu /code-review, Ultrareview und Code Review enthält keinen solchen Hinweis.

Zwei Sitzungen, eine schreibt, eine prüft

Ein frischer Kontext entsteht auch ohne Befehl. Die Empfehlungen (externe Seite, code.claude.com) schlagen zwei Sitzungen vor, eine schreibt, die andere prüft, und die Befunde gehen zurück an die erste. Mehrere Sitzungen erlauben damit Arbeitsweisen, die auf Qualität zielen. Dasselbe geht mit Tests: Eine Sitzung schreibt sie, eine andere den Code, der sie bestehen soll. Der Nachteil ist Handarbeit: Die Befunde muss jemand von einem Fenster ins andere kopieren.

Einfacher ist ein Subagent, dem man den Auftrag selbst schreibt. Die Empfehlungen raten dazu, wenn der Diff gegen einen Plan geprüft werden soll. Für die reine Fehlersuche nennen sie /code-review. Der eigene Auftrag nennt die Arbeit, den Plan und das, was als Befund zählt. Weil der Prüfer ein Subagent ist, bekommt die schreibende Sitzung die Lücken direkt zurück und kann sie beheben und erneut prüfen lassen. Wer das oft braucht, legt einen eigenen Subagent für Reviews an, wie in Kapitel 20 beschrieben. Wie eine Prüfung zum Maßstab wird, an dem Claude sich vorher schon misst, behandelt Kapitel 24.

Was offen bleibt

• Die übliche Grenze der Befunde. --max-findings verschiebt sie. Ihren Wert nennt die Doku nur für die Befundliste in einer Anwendung wie der Desktop-App, dort sind es 32.
• Fehlalarme bei /code-review und Ultrareview. Für beide nennt die Doku keine Zahl. Die Zahl für Code Review stammt aus Anthropics eigenem Einsatz.
• Was ein Review auf welcher Stufe kostet. Für Ultrareview nennt die Doku eine Spanne in Dollar. Für Code Review nennt sie die Größen, von denen die Kosten abhängen. Einen festen Preis je Review gibt es dort nicht. Für /code-review sagt sie, dass er zum normalen Verbrauch zählt.
• Claude Code Security. Wie die Funktion vom Februar 2026 mit dem heutigen Produkt Claude Security zusammenhängt, bleibt offen.