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.

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. Sie können außerdem eine REVIEW.md in einem Unterverzeichnis hinzufügen, um zusätzlich zur Stammdatei Prüfungen für Änderungen unter diesem Pfad 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.

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.

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

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