Skip to main content
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.
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. 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:
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.
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.

​
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.

​
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.