> ## Documentation Index
> Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/docs/de/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](/docs/de/memory), 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](#which-branch-review-md-is-read-from).

<Note>
  Um zu ändern, wie gründlich Reviews sind oder wann sie ausgeführt werden, bitten Sie einen Owner, die [Review-Stufe](/docs/de/code-review-setup#set-the-default-review-level) oder die [Einstellung **Review runs**](/docs/de/code-review-setup#set-when-reviews-run) zu ändern.
</Note>

<h2 id="use-claude-md-for-project-wide-rules">
  CLAUDE.md für projektweite Regeln verwenden
</h2>

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](/docs/de/code-review-pull-requests#severity-levels), 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.

<h2 id="use-review-md-for-review-only-rules">
  REVIEW\.md für Regeln nur für Reviews verwenden
</h2>

`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:

```text theme={null}
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](#what-a-review-reads-for-each-branch-setup).

<Note>
  Der Code-Review-Dienst und der lokale [`/code-review`-Befehl](/docs/de/code-review-local) 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.
</Note>

<h3 id="example-review-md">
  Beispiel für REVIEW\.md
</h3>

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.

```markdown theme={null}
# 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
```

<h3 id="choose-what-to-write-in-review-md">
  Festlegen, was in REVIEW\.md stehen soll
</h3>

`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](#example-review-md) 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](#which-branch-review-md-is-read-from).

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

<h3 id="which-branch-review-md-is-read-from">
  Von welchem Branch REVIEW\.md gelesen wird
</h3>

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

<h4 id="what-counts-as-branch-protection">
  Was als Branch-Schutz gilt
</h4>

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.

<h4 id="what-a-review-reads-for-each-branch-setup">
  Was ein Review bei der jeweiligen Branch-Konfiguration liest
</h4>

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

| Branch-Schutz | Gelesene Kopie | Gelesene Dateien |
| :- | :- | :- |
| Der Standard-Branch ist geschützt, und der Pull Request zielt auf ihn oder auf einen Branch, den kein Ruleset schützt | Standard-Branch | Stammdatei und Dateien in Unterverzeichnissen |
| Der Pull Request zielt auf einen anderen Branch, den ein Ruleset schützt | Dieser Basis-Branch | Stammdatei und Dateien in Unterverzeichnissen |
| Der Standard-Branch ist nicht geschützt, und der Basis-Branch hat keine Schutzregel der einen oder anderen Art | Standard-Branch | Stammdatei |
| Code Review kann die Schutzeinstellungen nicht bestätigen. Dazu gehört ein ungeschützter Standard-Branch mit einem Basis-Branch, der nur eine klassische Regel hat | Keine | Keine |

Wenn der Check Run `REVIEW.md` erwähnt, lesen Sie [Der Check Run erwähnt REVIEW.md](/docs/de/code-review-troubleshooting#the-check-run-mentions-review-md).

<h2 id="related-resources">
  Verwandte Ressourcen
</h2>

* [Code Review](/docs/de/code-review): was der Dienst ist und wie ein Review abläuft
* [Reviews in einem Pull Request lesen und anfordern](/docs/de/code-review-pull-requests#severity-levels): was jeder Schweregrad bedeutet und wie Befunde angezeigt werden
* [Code Review einrichten](/docs/de/code-review-setup): die Review-Stufe und wann Reviews ausgeführt werden, was ein Owner festlegt
* [Lokales Review mit `/code-review`](/docs/de/code-review-local): der `/code-review`-Befehl, seine Argumente und Effort-Stufen
* [Memory](/docs/de/memory): wie `CLAUDE.md`-Dateien in Claude Code funktionieren