Was ist /code-review in Claude Code? Anwendung, Wahl der Stufe, ultra-Preise, Nachteile und Ergebnisse aus dem Praxistest

/code-review in Claude Code ist ein Befehl, der Ihren aktuellen Diff liest (nicht committete Änderungen und Commits, die dem Upstream voraus sind), darin nach Korrektheitsfehlern sucht und sie meldet. Es handelt sich um einen mitgelieferten Skill, der direkt mit Claude Code kommt – Sie können ihn also ohne GitHub-App sofort im Terminal ausführen. Wer /review eintippt, startet genau dasselbe.

Dieser Artikel stützt sich auf den Originaltext der offiziellen Claude-Code-Dokumentation (den Abschnitt „Review a diff locally“ der Seite Code Review, Find bugs with ultrareview und Commands) sowie auf das CHANGELOG und erklärt, was der Befehl tut, wie Sie zwischen den Stufen (low bis max) und ultra wählen und wie Sie --fix und --comment einsetzen. Alle hier beschriebenen Spezifikationen wurden am 2. Oktober 2026 am Originaltext geprüft. In den Abschnitten 9 und 10 geht es außerdem darum, was passiert ist, als ich /code-review high tatsächlich auf den Code dieser Website angewendet habe, und welche Nachteile mir dabei aufgefallen sind.

1. Was ist /code-review? Ein mitgelieferter Skill, der Fehler im Diff findet

Laut der Befehlsreferenz (Commands) prüft der Befehl den aktuellen Diff – oder eine PR-Nummer, einen Branch oder einen Pfad, den Sie übergeben – auf Korrektheitsfehler. Weiter heißt es dort, dass die Prüfung je nach Modell und Effort-Stufe auch Möglichkeiten zum Aufräumen abdeckt, und die Seite Code Review nennt neben Korrektheitsfehlern auch Vorschläge zu Wiederverwendung, Vereinfachung und Effizienz. Die Fehlersuche ist also die Hauptaufgabe; Aufräumvorschläge kommen je nach Bedingungen hinzu.

Die Syntax sieht so aus:

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

Vier Eigenschaften sollten Sie vorab kennen:

• Er läuft im Hintergrund. Die Prüfung läuft als Subagent mit eigenem Kontextfenster und füllt Ihr Gespräch daher nicht. Die Befunde erscheinen in Ihrem Gespräch, sobald sie fertig ist.
• Er liest CLAUDE.md, aber nicht REVIEW.md. REVIEW.md ist die Anweisungsdatei für die GitHub-App-Version von Code Review, die weiter unten behandelt wird.
• /review ist ein Alias. Laut Dokumentation war /review vor v2.1.223 ein eigener Befehl, der einen GitHub-PR in einem einzigen Durchgang las. Heute ist er identisch mit /code-review.
• Der frühere Name war /simplify. Laut CHANGELOG wurde /simplify in v2.1.147 in /code-review umbenannt; später kam /simplify als eigener Befehl zurück, der nur aufräumt und nicht nach Fehlern sucht.

Im Terminal und bei -p-Aufrufen kommen die Befunde als Text in der Antwort zurück. In Apps, die eine Befundliste anfordern, etwa in der Desktop-App, erscheinen sie als Liste, in der jeder Eintrag die Fundstelle in der Datei, eine Zusammenfassung in einem Satz und eine Kategorie wie correctness enthält. Wenn Claude sie später behebt, wird jeder Eintrag als behoben, übersprungen oder nicht nötig markiert.

2. Grundlagen: Was geprüft werden soll

Die einfachste Form: Tippen Sie den Befehl ohne Argumente in der Session ein, in der Sie gerade arbeiten.

# Review commits ahead of upstream + uncommitted changes
/code-review

# Review at a specific level
/code-review high

# Pass a PR number to review a colleague's pull request
/code-review high 1234

# Pass a branch range
/code-review main...my-feature

Ohne Argumente prüft er laut Dokumentation die Commits Ihres Branches, die seinem Upstream voraus sind, plus alle nicht committeten Änderungen. Gibt es weder auf dem Branch noch im Arbeitsverzeichnis etwas Neues, hat er nichts zu melden. Um etwas anderes zu prüfen, übergeben Sie ein Ziel:

Sofern Sie nicht ultra angeben, wird alles, was nach Stufe und Flags übrig bleibt, als Prüfziel behandelt. So lädt /code-review /fix-issue 123 nicht /fix-issue als zweiten Skill, sondern liest den Text /fix-issue 123 als Ziel.

In folgenden Fällen läuft er nicht im Hintergrund, sondern im Vordergrund innerhalb Ihres Gesprächs: wenn Sie ihn erneut starten, während eine frühere Prüfung noch läuft, im nicht interaktiven Modus mit -p oder dem Agent SDK und wenn Sie die Umgebungsvariable CLAUDE_CODE_DISABLE_BACKGROUND_TASKS auf 1 setzen (was auch alle anderen Hintergrundfunktionen abschaltet).

3. Die Stufe wählen: low bis max

Die Stufe ist ein Kompromiss zwischen der Breite der Prüfung und der Sicherheit, die ein Befund haben muss. Die Dokumentation erklärt, dass bei low und medium nur die Befunde gemeldet werden, bei denen sich die Prüfung am sichersten ist, sodass Sie weniger Fehlalarme sehen, während high bis max breiter suchen und auch Befunde enthalten können, bei denen sich die Prüfung weniger sicher ist.

Als Faustregel gilt: Wie viel Aufwand können Sie in das Lesen der Befunde stecken? Für einen schnellen Check zwischendurch nehmen Sie low oder medium; wenn Sie vor dem Merge mehr finden wollen und es sich leisten können, Fehlalarme selbst auszusortieren, nehmen Sie high oder höher. Diese Aufteilung folgt der Beschreibung in der Dokumentation. Dass höhere Stufen mehr Tokens verbrauchen, entspricht dem allgemeinen Prinzip von Effort, doch die offizielle Dokumentation nennt keine Zahlen zu Dauer oder Verbrauch pro Stufe. Was Effort selbst bedeutet, erklärt unser Artikel zur Effort-Einstellung von Claude Code.

Ohne Stufe gilt „die zuletzt eingetippte Stufe“

Wenn Sie keine Stufe angeben, verwendet die Prüfung die letzte Stufe von low bis max, die Sie selbst eingetippt haben. Das schließt eine in einer früheren Session eingetippte Stufe ein; in diesem Fall sehen Sie einen Hinweis wie Reusing high effort, the level you typed last time. Die Einzelheiten:

• Die gemerkte Stufe wird aktualisiert, wenn Sie in einer interaktiven Session etwa /code-review high eintippen.
• Eine Stufe, die in einem nicht interaktiven -p-Aufruf übergeben wird, wird nicht gemerkt.
• ultra verwendet die gemerkte Stufe weder, noch aktualisiert es sie.
• Haben Sie noch nie eine Stufe eingetippt, gilt der aktuelle Effort der Session.

Die Dokumentation merkt außerdem an, dass /code-review ohne Stufe vor v2.1.223 immer den aktuellen Effort der Session verwendete. Wer die Stufe in Erwartung des alten Verhaltens weglässt, bekommt womöglich eine höhere (oder niedrigere) Stufe als gedacht. Wenn es darauf ankommt, tippen Sie die Stufe also jedes Mal ein.

4. --fix und --comment einsetzen

--fix lässt sich womöglich nicht mit /rewind rückgängig machen

Hier ist die größte Vorsicht geboten. Laut Dokumentation finden Änderungen, die --fix in einer Hintergrundprüfung vornimmt, außerhalb der Checkpoints Ihrer Session statt, sodass /rewind sie nicht rückgängig macht. Nutzen Sie stattdessen git, um sie zurückzunehmen. Läuft die Prüfung im Vordergrund (eine frühere Prüfung läuft noch, -p usw.), ändert sie während Ihres eigenen Zuges, und /rewind stellt wie gewohnt wieder her.

# Commit your current state before --fix so it's easy to go back
git add -A && git commit -m "wip: before code-review --fix"
/code-review medium --fix

# If you don't like the result, undo it with git
git diff
git restore .

Sie können die Prüfung auch ohne --fix laufen lassen, die Ergebnisse lesen und dann etwa „behebe nur Nr. 1 und Nr. 3“ verlangen. Wenn Sie nicht sicher sind, ob jeder Befund übernommen werden soll, ist das der sicherere Weg. Checkpoints behandelt unser Artikel zu Checkpoints und /rewind ausführlich.

Wohin --comment postet

• GitHub-Pull-Requests: Die Befunde werden als Inline-Kommentare an den betreffenden Zeilen gepostet.
• GitLab-Merge-Requests: Sie werden über glab, die CLI von GitLab, als einzelne Notiz gepostet (ab v2.1.257). Ist glab nicht installiert, erscheinen die Befunde nur im Terminal.

Bei GitLab übergeben Sie den MR als URL oder in der Form !123. Eine bloße Nummer oder ein Branch-Name wird nur dann als MR behandelt, wenn der Origin auf gitlab.com liegt; bei einer selbst betriebenen GitLab-Instanz sollen Sie laut Dokumentation die URL oder !123 verwenden. Ob das Posten auf GitHub eine Authentifizierung wie gh voraussetzt, geht aus der offiziellen Dokumentation mit Stand 2. Oktober 2026 nicht hervor.

5. ultra: Prüfung mit mehreren Agenten in der Cloud und Preise

/code-review ultra ist eine gründliche Prüfung, bei der mehrere Prüf-Agenten parallel in einer Sandbox in der Cloud von Anthropic laufen statt auf Ihrem Rechner. Es handelt sich um eine Research Preview namens ultrareview; bei Konten, auf denen sie verfügbar ist, ist /ultrareview ein Alias. Die offizielle Dokumentation nennt drei Vorteile gegenüber einem lokalen /code-review:

• Höhere Aussagekraft: Jeder gemeldete Befund wird unabhängig reproduziert und verifiziert, sodass sich die Ergebnisse auf echte Fehler statt auf Stilvorschläge konzentrieren.
• Breitere Abdeckung: Mehr Agenten untersuchen die Änderung parallel und stoßen so auf Probleme, die eine lokale Prüfung übersehen kann.
• Keine lokalen Ressourcen: Die Prüfung läuft in der Cloud, Sie können währenddessen im Terminal weiterarbeiten.

Preise und kostenlose Durchläufe

ultra wird aus dem Nutzungsguthaben (Extra Usage) abgerechnet, nicht aus der in Ihrem Plan enthaltenen Nutzung.

• Kostenlose Durchläufe: Die drei Durchläufe bei Pro und Max sind ein einmaliges Kontingent pro Konto und werden nicht aufgefüllt.
• Kosten pro Durchlauf: Sind die kostenlosen Durchläufe aufgebraucht, kostet ein Durchlauf typischerweise $5 bis $25 aus dem Nutzungsguthaben, je nach Umfang der Änderung. Der Startdialog zeigt vor jedem Durchlauf eine Schätzung.
• Wie gezählt wird: Ein Durchlauf zählt, sobald die Cloud-Session startet. Auch ein Abbruch mittendrin oder ein Fehlschlag verbraucht einen kostenlosen Durchlauf. Bezahlte Prüfungen werden nach dem tatsächlich Gelaufenen abgerechnet.
• Voraussetzung: Bezahlte Prüfungen starten nur, wenn das Nutzungsguthaben aktiviert ist. Das können Sie mit /usage-credits prüfen. Die Bestätigung für die Abrechnung über das Nutzungsguthaben erscheint einmal pro Gespräch.

Ob „$5–25“ teuer oder günstig ist, hängt vom Vergleich ab. Gegenüber /code-review mit low bis max, das ohne eigene Gebühr innerhalb der Limits Ihres Plans bleibt, ist ultra eine zusätzliche Ausgabe. Gegenüber der weiter unten beschriebenen GitHub-App-Version von Code Review (durchschnittlich $15–25 pro Prüfung) überschneiden sich die Preisspannen dagegen. Code Review ist aber ein anderes System, das automatisch bei jedem PR läuft, und die Zahlen sind unterschiedlich angegeben („Durchschnitt“ gegenüber „typische Spanne“), sodass sie sich nicht direkt vergleichen lassen.

Dauer, Umfang und wo ultra nicht verfügbar ist

• Dauer: typischerweise 5 bis 10 Minuten. Die Prüfung läuft im Hintergrund, mit /tasks können Sie den Stand ansehen oder sie abbrechen. Ein Abbruch liefert keine Teilergebnisse.
• Umfang: Ohne Argumente prüft sie Ihren aktuellen Branch gegenüber dem Standard-Branch des Repositorys sowie nicht committete und gestagte Änderungen. Das ist eine andere Basis als das „vor dem Upstream“ des lokalen /code-review. Mit einem Branch-Namen wie in /code-review ultra develop ändern Sie die Basis.
• PR prüfen: Übergeben Sie eine Nummer wie in /code-review ultra 1234, wird nichts von Ihrem Rechner hochgeladen; die Cloud klont den PR direkt. Das funktioniert mit github.com und angebundenem GitHub Enterprise Server.
• Grenzen: Eine Branch-Prüfung umfasst standardmäßig bis zu 500 geänderte Dateien und 8.000 geänderte Zeilen (laut Dokumentation können sich diese Werte ändern).
• Wo sie nicht verfügbar ist: Sie setzt die Anmeldung mit einem claude.ai-Konto voraus und ist weder über Amazon Bedrock, die Agent Platform von Google Cloud oder Microsoft Foundry noch für Organisationen mit Zero Data Retention verfügbar. Ist sie nicht verfügbar, läuft /code-review ultra als lokale Prüfung.

Eine Branch-Prüfung bündelt den Zustand Ihres lokalen Repositorys und lädt ihn in die Cloud hoch. Für nicht committete Änderungen an Dateien mit Namen, die auf Zugangsdaten hindeuten, etwa .env und *.tfvars, gelten dieselben Regeln wie beim Hochladen in eine Cloud-Session. Wie Cloud-Sessions allgemein funktionieren, erklärt unser Artikel zu Cloud-Sessions.

Ergebnisse im PR posten (--post) und aus Skripten starten

Wenn Sie einen PR auf github.com mit ultra prüfen, können Sie die Ergebnisse als einzelnen Kommentar von Ihrem eigenen GitHub-Konto im PR posten (ab v2.1.227). Es ist ein gewöhnlicher Kommentar, keine Review und keine Freigabe, und standardmäßig wird nicht gepostet (--no-post). /code-review ultra 1234 --post wählt das Posten im Startdialog vor, die Bestätigung vor dem Start bekommen Sie aber trotzdem. Gepostet wird erst, wenn die Prüfung fertig ist, Sie müssen die Session also bis zum Ende offen lassen.

Für CI oder Skripte verwenden Sie den Unterbefehl claude ultrareview. Er wartet auf die Ergebnisse und schreibt sie nach stdout (verfügbar sind --json, --timeout (Standard 45 Minuten) und --post). claude -p '/code-review ultra' startet die Prüfung nur und beendet sich, ohne zu warten – Sie erhalten also keine Ergebnisse, und wenn eine Abrechnung über das Nutzungsguthaben nötig ist, startet sie nicht einmal.

# Review PR 1234 with ultra from a script and get the results
claude ultrareview 1234

# Use a base other than the default branch
claude ultrareview origin/main

6. Der Unterschied zu ähnlichen Funktionen

Claude Code hat mehrere Prüffunktionen mit ähnlichen Namen. Besonders leicht zu verwechseln ist die GitHub-App-Funktion namens „Code Review“, weil sie auf derselben Seite dokumentiert ist wie der Befehl /code-review.

• /simplify: Vier Agenten prüfen parallel auf Wiederverwendung vorhandener Helfer, Vereinfachung, Effizienz und darauf, ob die Änderung auf der richtigen Abstraktionsebene liegt, und wenden die Korrekturen dann an. Nach Korrektheitsfehlern sucht er nicht. Die Seite Code Review rät außerdem: Wer /simplify per Skript zur Fehlersuche eingesetzt hat, sollte auf /code-review --fix umsteigen.
• /security-review: Prüft den Diff zwischen Ihrem aktuellen Branch und dem Standard-Branch von origin auf Sicherheitslücken wie Injection, Authentifizierungsprobleme und Datenlecks. Er setzt ein Remote namens origin voraus.
• Code Review (GitHub-App): Sobald ein Owner der Organisation es aktiviert, untersuchen mehrere Agenten auf der Infrastruktur von Anthropic einen PR beim Öffnen, bei jedem Push oder wenn jemand @claude review schreibt, und hinterlassen Kommentare an einzelnen Zeilen. Es ist eine Research Preview nur für Team und Enterprise (nicht für Organisationen mit Zero Data Retention). Der Preis richtet sich nach den Tokens, liegt im Schnitt bei $15–25 pro Prüfung, eine Prüfung dauert im Schnitt 20 Minuten, und abgerechnet wird über das Nutzungsguthaben getrennt von den Plan-Limits. Was es bemängelt, können Sie mit REVIEW.md steuern.
• claude-code-action: Führt Claude Code in GitHub-Actions-Workflows Ihres eigenen Repositorys aus. Das Review-Beispiel in der offiziellen Dokumentation ruft die Plugin-Version des Skills code-review auf (/code-review:code-review --comment), um den PR zu kommentieren. Die Kosten sind die Claude-API-Preise (oder Abo-Tokens) plus die Laufzeit von GitHub Actions.

Ordnet man sie nach „wo es läuft, wer zahlt und was geprüft wird“, wird es übersichtlicher. Für den eigenen Diff lokal nehmen Sie /code-review, für eine gründliche Prüfung vor dem Merge ultra, und für eine automatische Prüfung jedes PRs im Team die Code Review der GitHub-App oder claude-code-action.

7. Wann Claude den Befehl selbst startet – und wie Sie das verhindern

Claude kann /code-review von sich aus starten. Bitten Sie in normaler Sprache darum, Ihre Änderungen zu prüfen, führt Claude den Skill möglicherweise aus, ohne dass Sie den Befehl eintippen, und auch eine geplante Aufgabe mit /code-review als Prompt startet eine Prüfung. Eine geplante Aufgabe startet aber nie ultra (die Cloud-Prüfung). ultra läuft nur, wenn Sie selbst /code-review ultra eintippen.

Damit weder Claude noch geplante Aufgaben den Befehl starten, er aber verfügbar bleibt, wenn Sie ihn selbst eintippen, fügen Sie Folgendes in eine Einstellungsdatei wie ~/.claude/settings.json ein:

{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}

Hintergrundprüfungen laufen als Subagenten. Wie Subagenten mit Kontext und Modellen umgehen, erklärt unser Artikel zu Subagenten und Agent-Teams.

8. Was wann sinnvoll ist

Laut der Vergleichstabelle in der offiziellen Dokumentation eignet sich das lokale /code-review am besten für schnelles Feedback während der Arbeit und ultra für Sicherheit vor dem Merge bei umfangreichen Änderungen. Übertragen auf einen gewöhnlichen Arbeitsablauf sieht das so aus:

Weil die 3 kostenlosen Durchläufe von ultra nicht aufgefüllt werden, lohnt es sich, sie statt für kleine Korrekturen für Änderungen mit großer Tragweite oder Änderungen, bei denen die lokale Prüfung keine Klarheit gebracht hat, aufzuheben. Ebenso nehmen Sie /security-review, wenn Sie sich auf Sicherheitslücken konzentrieren wollen, und /simplify, wenn Sie die Lesbarkeit verbessern statt Fehler finden wollen – so trennt auch die Dokumentation die Befehle nach Zweck.

9. Ausprobiert am Code dieser Website

Am 2. Oktober 2026 habe ich /code-review high auf den Code des KI-Bildprüf-Tools angewendet, das auf dieser Website veröffentlicht ist. Das Tool liest die Metadaten und die Herkunftsangaben (C2PA) eines Bildes vollständig im Browser aus; geprüft wurden vier Dateien: die UI-Logik, die Parsing-Logik (ein Web Worker), der Controller und das Seiten-Template. Ich habe die Prüfung in der Claude-Code-Desktop-App ausgeführt (mitgeliefertes Claude Code 2.1.284, Modell Opus 5.5), und zwar direkt nachdem ich selbst nach Fehlern gesucht und fünf davon behoben hatte.

Jeder Befund kam in der Form „welche Datei, welche Zeile“ und „welche Eingabe führt zu welchem Ergebnis“. Ich habe jeden einzelnen am Quellcode der Bibliothek, mit der das Tool die Bildmetadaten liest (exifr), und an selbst erstellten Testbildern überprüft und dann alle 9 behoben, die sich als echt herausstellten. Die wichtigsten:

Selbst direkt nachdem ich selbst gesucht und korrigiert hatte, steckten also noch 9 Fehler anderer Art im Code. Vor allem die Befunde zu Annahmen („die Bibliothek sollte sich so verhalten“) wären ohne Blick in den Quellcode der Bibliothek schwer zu entdecken gewesen. Allerdings ist das das Ergebnis eines einzigen Durchlaufs an einer einzigen Codebasis. Es ist nicht gesagt, dass der Befehl jedes Mal mit derselben Quote echte Fehler findet, und ich habe weder mit low, medium oder max verglichen noch das kostenpflichtige ultra ausprobiert.

10. Nachteile und Vorbehalte

Aus der Nutzung und der Lektüre der offiziellen Dokumentation ergeben sich fünf Punkte, auf die Sie achten sollten:

• Er verbraucht Ihre Limits. Auch lokale Prüfungen zählen gegen Ihre normale Claude-Nutzung, und höhere Stufen verbrauchen mehr. Bei ultra zahlen Pro- und Max-Nutzer nach den 3 kostenlosen Durchläufen (Team und Enterprise von Anfang an) etwa $5–25 pro Durchlauf aus dem Nutzungsguthaben.
• Befunde nicht unbesehen übernehmen. Die Dokumentation selbst sagt, dass ab high auch unsicherere Befunde dabei sein können. Diesmal waren 9 von 10 echt, aber jeden einzelnen zu prüfen kostet trotzdem Arbeit.
• --fix lässt sich nicht mit /rewind rückgängig machen. Im Hintergrund vorgenommene Änderungen müssen Sie mit git zurücknehmen, committen Sie also vorher.
• Er prüft nur die Korrektheit des Codes. Ob Texte oder Konfigurationsinhalte den Tatsachen entsprechen, prüft er nicht. Ein auf dieser Website häufiges Problem – der Artikel sagt etwas anderes als die offizielle Spezifikation – liegt zum Beispiel außerhalb seines Bereichs.
• Claude startet ihn womöglich von sich aus. Wenn Sie das nicht wollen, beschränkt die Einstellung aus Abschnitt 7 ihn auf manuelle Aufrufe.

Mein Fazit: Ein Durchlauf auf high nach dem Schreiben von neuem Code oder einer großen Änderung war die Nutzung, die den Aufwand und den Verbrauch gerechtfertigt hat. Für Textänderungen oder kleine Konfigurationsänderungen eignet er sich dagegen nicht.

Zusammenfassung

/code-review ist ein mitgelieferter Skill, der Ihren lokalen Diff oder einen PR mit Schwerpunkt auf Korrektheitsfehlern prüft. Er läuft im Hintergrund und unterbricht Ihre Arbeit nicht, und seine Kosten bleiben innerhalb Ihrer normalen Nutzung. Bei low oder medium erhalten Sie nur sichere Befunde; bei high bis max sucht er breiter, Sie müssen aber aussortieren; und ohne Angabe gilt die zuletzt eingetippte Stufe.

--fix, das bis zur Korrektur geht, ist praktisch, doch Änderungen im Hintergrund lassen sich nicht mit /rewind rückgängig machen, deshalb ist vorheriges Committen der sichere Weg. Wenn Sie tiefer prüfen wollen, verbringt ultra etwa 5 bis 10 Minuten in der Cloud und liefert nur verifizierte Befunde; Pro und Max erhalten einmalig 3 kostenlose Durchläufe, danach kostet ein Durchlauf etwa $5–25 aus dem Nutzungsguthaben. Die ähnlich benannte Code Review der GitHub-App und claude-code-action sind etwas anderes – sowohl darin, wo sie laufen, als auch darin, was sie kosten.

Als ich den Befehl einmal auf den Code dieser Website angewendet habe, waren 9 seiner 10 Befunde echte Fehler, und das direkt nachdem ich selbst korrigiert hatte. Sie müssen jeden Befund prüfen, aber nach neuem Code oder einer großen Änderung lohnt sich ein Durchlauf durchaus.

FAQ

Q. Was ist der Unterschied zwischen /review und /code-review?

A. Heute sind beide gleich. /review ist ein Alias von /code-review und nimmt dieselben Stufen und Flags. Laut offizieller Dokumentation war /review vor v2.1.223 ein eigener, nur lesender Befehl, der einen GitHub-PR in einem einzigen Durchgang prüfte.

Q. Kostet /code-review extra?

A. Bei low bis max nicht. In der Vergleichstabelle der offiziellen Dokumentation zählen die Kosten zur normalen Nutzung. Extra kostet ultra: Nach den 3 kostenlosen Durchläufen bei Pro und Max sind es etwa $5–25 pro Durchlauf aus dem Nutzungsguthaben.

Q. Werden die 3 kostenlosen Durchläufe von ultra jeden Monat zurückgesetzt?

A. Nein. Die offizielle Dokumentation beschreibt die drei Durchläufe bei Pro und Max als einmaliges Kontingent pro Konto, das nicht aufgefüllt wird. Auch abgebrochene oder fehlgeschlagene Prüfungen zählen als ein Durchlauf. Team und Enterprise erhalten keine kostenlosen Durchläufe.

Q. Kann ich Änderungen durch --fix rückgängig machen?

A. Mit git. Änderungen aus einer Prüfung, die im Hintergrund lief, entstehen außerhalb Ihrer Checkpoints, deshalb macht /rewind sie nicht rückgängig. Lief die Prüfung im Vordergrund (eine frühere Prüfung läuft noch, -p usw.), kann /rewind sie wiederherstellen. Im Zweifel committen Sie vor --fix.

Q. Gelten Regeln aus REVIEW.md für /code-review?

A. Nein. Das lokale /code-review folgt CLAUDE.md, liest REVIEW.md aber nicht. REVIEW.md ist die Anweisungsdatei für die GitHub-App-Version von Code Review. Regeln, an die sich die lokale Prüfung halten soll, gehören in CLAUDE.md.

Quellen

• Offizielle Claude-Code-Dokumentation: Code Review (einschließlich des Abschnitts „Review a diff locally“)
• Offizielle Claude-Code-Dokumentation: Find bugs with ultrareview
• Offizielle Claude-Code-Dokumentation: Commands
• Offizielle Claude-Code-Dokumentation: Claude Code GitHub Actions
• Claude Code: CHANGELOG

Alle Quellen wurden am 2. Oktober 2026 am Originaltext geprüft. Laut offizieller Dokumentation ist ultrareview eine Research Preview; Funktionen, Preise und Verfügbarkeit können sich ändern.