Code Review anpassen

Legen Sie mit REVIEW.md und CLAUDE.md fest, was Code Review in Ihren Pull Requests kennzeichnet: Schweregrade neu kalibrieren, Pfade überspringen, Prüfungen hinzufügen und sehen, welche Kopie gilt.

Sie können ändern, was Code Review in Ihrem Repository kennzeichnet, indem Sie Anweisungen in das Repository committen. So reduzieren Sie die Anzahl der Nits, unterbinden Kommentare zu generierten Dateien oder fügen eine Regel hinzu, die Ihrem Team wichtig ist. Legen Sie die Anweisungen in einer von zwei Dateien ab:

• CLAUDE.md: Projektanweisungen, die Claude Code für jede Aufgabe liest, einschließlich Reviews. Code Review liest sie als Projektkontext und kennzeichnet Änderungen, die gegen sie verstoßen.
• REVIEW.md: Anweisungen ausschließlich für Reviews. Verwenden Sie diese Datei, um festzulegen, was Ihr Team gekennzeichnet haben möchte, mit welchem Schweregrad und was übersprungen werden soll.

Fügen Sie REVIEW.md im Stammverzeichnis Ihres Repositorys hinzu und mergen Sie die Datei. Schützen Sie anschließend Ihren Standard-Branch.

[!NOTE]

Um zu ändern, wie gründlich Reviews sind oder wann sie ausgeführt werden, bitten Sie einen Owner, die Review-Stufe oder die Einstellung Review runs zu ändern.

CLAUDE.md für projektweite Regeln verwenden

Code Review liest die CLAUDE.md-Dateien Ihres Repositorys als Projektkontext. Eine Änderung, die gegen eine ihrer Regeln verstößt, wird zu einem Befund mit dem Schweregrad, der zum Problem passt.

Ein Review liest die CLAUDE.md im Stammverzeichnis Ihres Repositorys sowie die CLAUDE.md-Dateien in den übergeordneten Verzeichnissen jeder geänderten Datei. Die CLAUDE.md eines Unterverzeichnisses wird gelesen, wenn der Pull Request eine Datei unter diesem Pfad ändert.

REVIEW.md für Regeln nur für Reviews verwenden

REVIEW.md ist eine Datei im Stammverzeichnis Ihres Repositorys, die Code Review an Ihr Repository anpasst. Auf einem geschützten Branch können Sie außerdem eine REVIEW.md in den meisten Unterverzeichnissen hinzufügen, um zusätzlich zur Stammdatei Prüfungen für Änderungen unter diesem Unterverzeichnis hinzuzufügen.

Die Agenten, die Probleme finden, und die Agenten, die sie verifizieren, erhalten ihren Inhalt als Review-Anweisungen Ihres Repositorys, zusammen mit den Standard-Review-Richtlinien von Code Review. Der Schritt, der das endgültige Review verfasst, zieht sie heran, bevor er den Schweregrad festlegt und die Zusammenfassung schreibt.

Diese Beispielstruktur enthält eine Stammdatei und eine Datei in einem Unterverzeichnis:

your-repo/
├── REVIEW.md            # Root file
├── services/
│   └── billing/
│       └── REVIEW.md    # Adds checks for changes under services/billing/
└── src/

Bevor Sie sich auf eine Datei in einem Unterverzeichnis verlassen, schützen Sie Ihren Standard-Branch und prüfen Sie, was ein Review bei Ihrer Branch-Konfiguration liest.

[!NOTE]

Der Code-Review-Dienst und der lokale /code-review-Befehl sind zwei separate Tools, und sie lesen unterschiedliche Dateien. Der Dienst liest sowohl CLAUDE.md als auch REVIEW.md. Der /code-review-Befehl, den Sie in einer Claude Code-Sitzung auf Ihrem eigenen Rechner ausführen, liest Ihre CLAUDE.md-Dateien, nicht jedoch REVIEW.md. Legen Sie Richtlinien, die an beiden Stellen angewendet werden sollen, in CLAUDE.md ab, und reservieren Sie REVIEW.md für Regeln, die speziell für das Review von Pull Requests gelten.

Wann eine REVIEW.md in einem Unterverzeichnis nicht angewendet wird

Code Review wendet keine REVIEW.md in oder unterhalb eines Unterverzeichnisses mit einem dieser Namen an, unabhängig davon, was das Unterverzeichnis enthält. Ein Unterverzeichnisname passt nur als Ganzes, in beliebiger Groß- und Kleinschreibung und auf beliebiger Tiefe, sodass Tests passt und integration-tests nicht:

• Tests: test, tests, __tests__, testdata, fixtures, __fixtures__, golden, corpus, snapshots, __snapshots__
• Beispiele: example, examples, sample, samples, demo, demos
• Generierter Code: generated
• Code von Drittanbietern: vendor, third_party, third-party, thirdparty, node_modules, bower_components, external, extern, deps, godeps, pods, carthage, site-packages, contrib

Legen Sie Prüfungen für diese Unterverzeichnisse in der Stamm-REVIEW.md ab oder in der REVIEW.md eines übergeordneten Unterverzeichnisses, sofern weder dieses übergeordnete Verzeichnis noch ein darüberliegendes auf der Liste steht.

Die übrigen REVIEW.md-Dateien in Unterverzeichnissen auf den Pfaden, die ein Pull Request ändert, teilen sich einen Grenzwert von 150.000 Bytes, die Stammdatei nicht mitgerechnet. Wenn der Check Run meldet, dass einige davon nicht hineingepasst haben, kürzen Sie die Dateien, sodass sie diesen Grenzwert einhalten.

Beispiel für REVIEW.md

Diese REVIEW.md kalibriert die Schweregrade für einen Backend-Dienst neu, begrenzt Nits, überspringt generierte Dateien und fügt Repository-spezifische Prüfungen hinzu.

# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.

## Cap the nits

Report at most five Nits per review.

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check

- New API routes have an integration test
- Log lines don't include email addresses, user IDs, or request bodies
- Database queries are scoped to the caller's tenant

Festlegen, was in REVIEW.md stehen soll

REVIEW.md ist frei formuliertes Markdown, das ändert, was ein Review findet und meldet. Das Format des Reviews ändert es nicht. Suchen Sie das Problem, das Sie beobachten, und fügen Sie dann eine Anweisung wie die gezeigte hinzu. Das Beispiel verwendet die ersten vier.

• Die falschen Dinge werden als Important markiert: Definieren Sie neu, was 🔴 Important für Ihr Repository bedeutet. Die Standardkalibrierung zielt auf Produktionscode ab, und für ein Dokumentations-Repository, ein Konfigurations-Repository oder einen Prototyp kann eine deutlich engere Definition sinnvoll sein. Geben Sie an, welche Arten von Befunden Important sind und welche höchstens Nit. Sie können auch hochstufen, etwa indem Sie jeden Verstoß gegen CLAUDE.md als Important behandeln.
• Zu viele Nits: Begrenzen Sie, wie viele 🟡 Nit-Kommentare ein einzelnes Review veröffentlicht. Eine Obergrenze wie „melde höchstens fünf Nits“ hält Reviews umsetzbar.
• Kommentare zu generierten Dateien oder zu Dingen, die CI bereits prüft: Listen Sie Pfade und Befundkategorien auf, bei denen Claude Befunde überspringen soll. Typische Kandidaten sind generierter Code, Lockfiles und eingebundene (vendored) Abhängigkeiten sowie alles, was Ihre CI bereits durchsetzt, etwa Linting oder Rechtschreibprüfung. Für Pfade, die ein gewisses Review, aber keine vollständige Prüfung verdienen, legen Sie stattdessen eine höhere Schwelle fest: „in scripts/ nur melden, wenn nahezu sicher und schwerwiegend.“
• Eine Teamregel wird nicht geprüft: Fügen Sie Regeln hinzu, die bei jedem Pull Request gekennzeichnet werden sollen, etwa „neue API-Routen müssen einen Integrationstest haben.“
• Befunde, die sich als falsch herausstellen: Verlangen Sie Belege, bevor eine Art von Befund veröffentlicht wird. Zum Beispiel reduziert „Aussagen zum Verhalten benötigen eine file:line-Angabe im Quellcode, keine Ableitung aus der Benennung“ Fehlalarme, die den Autor sonst eine zusätzliche Runde kosten würden.

Einige dieser Anweisungen erfordern die Stammdatei auf einem geschützten Standard-Branch.

Beschränken Sie REVIEW.md auf Anweisungen, die das Review-Verhalten ändern, und belassen Sie allgemeinen Projektkontext in CLAUDE.md.

Andere Dateien in REVIEW.md einbinden

Sie können Review-Anweisungen auf mehrere Dateien aufteilen und diese in Ihre Stamm-REVIEW.md einbinden. Nutzen Sie dies, wenn REVIEW.md zu lang wird oder wenn Sie Review-Regeln bereits in einer anderen Datei pflegen.

Um eine Datei einzubinden, fügen Sie der Stamm-REVIEW.md eine Zeile hinzu, die nur @ und den Dateinamen enthält. Code Review setzt den Inhalt der Datei an die Stelle dieser Zeile, sodass er als Teil von REVIEW.md gilt. In diesem Beispiel gibt die Stammdatei eine eigene Anweisung und bindet dann zwei Regeldateien ein:

# Review instructions

Report at most five Nits per review.

@review-security.md
@review-api.md

Speichern Sie die eingebundenen Dateien im Stammverzeichnis des Repositorys, neben REVIEW.md:

your-repo/
├── REVIEW.md
├── review-security.md
└── review-api.md

Code Review bindet die Dateien ein, wenn es REVIEW.md aus einem geschützten Branch liest. Prüfen Sie daher, welchen Branch ein Review für Ihr Repository liest:

• Geschützter Branch: Code Review setzt die eingebundene Datei an die Stelle ihrer @-Zeile
• Ungeschützter Standard-Branch: Die @-Zeile bleibt als reiner Text in REVIEW.md. Wenn der Pull Request die in der Zeile genannte Datei ändert, wird die Zeile weggelassen.

Wenn ein Review eine eingebundene Datei nicht anwendet, prüfen Sie jeden dieser Punkte:

• Speicherort: Verschieben Sie die Datei in das Stammverzeichnis des Repositorys. Außer bei einer Skill-Datei wird ein Pfad in ein Unterverzeichnis wie @docs/review-rules.md nicht eingebunden.
• Name: Geben Sie den Dateinamen exakt an, einschließlich Groß- und Kleinschreibung, und verwenden Sie einen Namen ohne Leerzeichen. Eine Zeile, deren Name keiner Datei neben REVIEW.md entspricht, bleibt als reiner Text in REVIEW.md, und der Check Run meldet sie nicht als übersprungene Einbindung.
• Eine Ebene: Führen Sie jede Datei in der Stamm-REVIEW.md auf. Eine @-Zeile in einer eingebundenen Datei oder in einer REVIEW.md in einem Unterverzeichnis bleibt reiner Text (bei Skill-Dateien ist das anders), und ein Markdown-Link auf eine andere Datei ist keine Einbindung.
• Grenzwerte: Binden Sie höchstens acht verschiedene Dateien ein, und halten Sie REVIEW.md und die eingebundenen Dateien zusammen unter 150.000 Bytes. Eine Datei, die das Byte-Limit erreichen würde, wird vollständig übersprungen und nicht gekürzt. Der Check Run meldet, wie viele Einbindungszeilen er aufgrund eines der beiden Grenzwerte übersprungen hat.
• Links: Verwenden Sie in REVIEW.md und den eingebundenen Dateien insgesamt höchstens 64 Markdown-Links. Links auf http-, https- oder mailto-Adressen und auf #-Anker zählen nicht, ebenso wenig Links in einer Skill-Datei. Oberhalb dieses Grenzwerts überspringt das Review Ihre gesamte Stamm-REVIEW.md, nicht nur die eingebundenen Dateien. Der Check Run meldet dann, dass die Anweisungen nicht angewendet wurden.
• Gemergte Kopie: Mergen Sie die eingebundene Datei in den Branch, aus dem REVIEW.md gelesen wird. Das Review liest beide aus demselben Commit, niemals aus den Änderungen des Pull Requests selbst.

Eine Skill-Datei einbinden

Damit Reviews Richtlinien befolgen, die Sie in einem Skill pflegen, binden Sie die SKILL.md des Skills in Ihre Stamm-REVIEW.md ein. Code Review führt keine Skills aus.

Fügen Sie @ und den Pfad zu SKILL.md in der Form .claude/skills/<folder>/SKILL.md in einer eigenen Zeile hinzu:

# Review instructions

Report at most five Nits per review.

@.claude/skills/api-review/SKILL.md

Treat any change under `migrations/` as Important.

Schützen Sie den Branch, aus dem REVIEW.md gelesen wird, denn Code Review bindet eine Skill-Datei nur ein, wenn es REVIEW.md aus einem geschützten Branch liest. Die Skill-Datei zählt zu den Grenzwerten von acht Dateien und 150.000 Bytes und hat einen eigenen Grenzwert von 30.000 Bytes.

Eine Skill-Zeile schreiben, die Code Review einbindet

Verwenden Sie einen Ordnernamen ohne Leerzeichen. Eine Zeile mit einem Leerzeichen im Pfad bleibt als reiner Text in REVIEW.md, und der Check Run meldet sie nicht als übersprungene Einbindung.

Wenn die @-Zeile für einen Skill gegen eine der folgenden Regeln verstößt, bindet Code Review den Skill aus dieser Zeile nicht ein:

• Pfad: Schreiben Sie den Pfad ausgehend vom Stammverzeichnis des Repositorys als .claude/skills/<folder>/SKILL.md, wobei der Ordner des Skills direkt unter skills/ liegt. Anders als ein Dateiname im Stammverzeichnis wird ein Pfad dieser Form, der keiner Datei entspricht, übersprungen und gezählt.
• Quelle: Kopieren Sie Richtlinien aus jeder anderen Datei unter .claude/ oder aus einem mitgelieferten, persönlichen oder Plugin-Skill in eine Datei neben REVIEW.md. Diese können Sie nicht direkt einbinden.
• Datei: Committen Sie SKILL.md als reguläre Textdatei. Code Review folgt keinem symbolischen Link, unabhängig davon, ob der Link die Datei selbst oder ein Ordner in ihrem Pfad ist.
• Größe: Halten Sie SKILL.md bei höchstens 30.000 Bytes, einschließlich Frontmatter
• Anzahl: Schreiben Sie höchstens acht Skill-Zeilen. Eine wiederholte Zeile zählt erneut zu den acht.
• Blöcke in REVIEW.md: Halten Sie die @-Zeile außerhalb von Code-Fences. Schließen Sie jeden HTML-Kommentar und jeden <pre>-, <script>-, <style>- oder <textarea>-Block oberhalb davon.

Wenn Code Review eine Skill-Zeile überspringt, weil sie gegen die Regel Datei, Größe, Anzahl oder Blöcke verstößt, zählt die Meldung des Check Runs zu übersprungenen Einbindungszeilen sie mit. Die Meldung erscheint nur, wenn das Review REVIEW.md aus einem geschützten Branch anwendet.

Prüfen, was ein Review von einem Skill erhält

Wenn der Skill eingebunden ist, erhält ein Review den Hauptteil von SKILL.md und sonst nichts aus dem Skill. Prüfen Sie den Skill daher anhand der folgenden Liste.

• Frontmatter: Wiederholen Sie im Hauptteil alles, was ein Review aus dem Frontmatter benötigt, zum Beispiel die Bedingungen, die description für die Verwendung des Skills angibt
• Eingefügte Befehle: Schreiben Sie aus, was ein !-Befehl liefern würde. Code Review führt den Befehl nicht aus und ersetzt die gesamte Zeile oder den gesamten Block, der ihn enthält, durch einen Platzhalter.
• Ersetzungen: Ersetzen Sie $ARGUMENTS und andere Ersetzungen durch festen Text, da ein Review keine Argumente übergibt und sie unverändert lässt
• Unterstützende Dateien: Kopieren Sie, was ein Review benötigt, in SKILL.md, da Code Review keine Skripte, verlinkten Dateien oder @file-Verweise lädt
• Ausschlüsse und Nit-Obergrenzen: Schreiben Sie Anweisungen, die Befunde ausschließen oder Nits begrenzen, in REVIEW.md oder eine Datei daneben, nicht in den Skill. Code Review akzeptiert den Text eines Skills für keines von beiden als Begründung.
• Links auf Repository-Dateien: Beschreiben Sie in Worten, worauf ein Link oder @file-Verweis zeigt. Das Review sieht den Pfad als reinen Text oder als Platzhalter.

Wenn Sie die !-Befehle, $ARGUMENTS oder Links des Skills bearbeiten, ändern Sie auch, wie er in Claude Code funktioniert. Wenn Ihr Team darauf angewiesen ist, kopieren Sie die Richtlinien in eine Datei neben REVIEW.md und binden Sie diese Datei anstelle des Skills ein.

Zeichen, die Code Review im Skill-Text ändert

Code Review ändert einige Zeichen im Text des Skills, sodass Ihre Codebeispiele ein Review in der folgenden Form erreichen.

In SKILL.md:       Use `items[0]`, never `List<String>`.
The review reads:  Use ˋitems(0)ˋ, never ˋList< String>ˋ.

In SKILL.md:       Run `ps | grep api` and ask @alice.
The review reads:  Run ˋps ¦ grep apiˋ and ask @ alice.

Wenn eine Regel von einem dieser Zeichen abhängt, beschreiben Sie sie zusätzlich in Worten.

Von welchem Branch REVIEW.md gelesen wird

Code Review liest REVIEW.md aus dem Basis-Branch des Pull Requests oder aus dem Standard-Branch, niemals aus den Änderungen des Pull Requests selbst. Um das Review-Verhalten zu ändern, mergen Sie die Änderung an REVIEW.md zuerst.

Halten Sie REVIEW.md auf Ihrem Standard-Branch und schützen Sie diesen Branch. Wenn ein Review die Kopie auf einem geschützten Standard-Branch liest (die erste Zeile der folgenden Tabelle), berücksichtigt es diese Anweisungen aus der Stammdatei:

• Herabsetzen des Schweregrads eines Befunds
• Ausschließen von Pfaden, Dateien oder Arten von Problemen
• Begrenzen von Nit-Kommentaren

Schreiben Sie Ausschlüsse und Nit-Obergrenzen in REVIEW.md oder eine Datei daneben, nicht in einen eingebundenen Skill.

Was als Branch-Schutz gilt

Code Review wertet diese Einstellungen als Schutz:

• Standard-Branch: eine klassische Branch-Schutzregel oder ein Ruleset
• Jeder andere Branch: ausschließlich ein Ruleset

Ein Ruleset zählt, wenn es Aktualisierungen einschränkt oder Pull Requests mit mindestens einer Genehmigung erfordert. Wenn es Pull Requests erfordert, muss es außerdem diese Genehmigung bei einem neuen Push verwerfen oder verlangen, dass die Genehmigung nach dem letzten Push erfolgt.

Was ein Review bei der jeweiligen Branch-Konfiguration liest

Suchen Sie die Situation Ihres Repositorys in der ersten Spalte der folgenden Tabelle.

Wenn der Check Run REVIEW.md erwähnt, lesen Sie Der Check Run erwähnt REVIEW.md.

Verwandte Ressourcen

• Code Review: was der Dienst ist und wie ein Review abläuft
• Reviews in einem Pull Request lesen und anfordern: was jeder Schweregrad bedeutet und wie Befunde angezeigt werden
• Code Review einrichten: die Review-Stufe und wann Reviews ausgeführt werden, was ein Owner festlegt
• Lokales Review mit /code-review: der /code-review-Befehl, seine Argumente und Effort-Stufen
• Memory: wie CLAUDE.md-Dateien in Claude Code funktionieren