DEEP DIVE: in Claude Codes review plugins

Provide a code review for the given pull request.
...
To do this, follow these steps precisely:

1. Launch a haiku agent to check if any of the following are true:
   - The pull request is closed
   - The pull request is a draft
   - The pull request does not need code review (e.g. automated PR, trivial change that is obviously correct)
   - Claude has already commented on this PR (check `gh pr view <PR> --comments` for comments left by claude)

   If any condition is true, stop and do not proceed.
   ...
2. Launch a haiku agent to return a list of file paths (not their contents) for all relevant CLAUDE.md files including:
   - The root CLAUDE.md file, if it exists
   - Any CLAUDE.md files in directories containing files modified by the pull request
3. Launch a sonnet agent to view the pull request and return a summary of the changes
4. Launch 4 agents in parallel to independently review the changes. Each agent should return the list of issues, where each issue includes a description and the reason it was flagged (e.g. "CLAUDE.md adherence", "bug").
   ...
5. For each issue found in the previous step by agents 3 and 4, launch parallel subagents to validate the issue.
   ...
6. Filter out any issues that were not validated in step 5.
   ...
7. Output a summary of the review findings to the terminal:
   - If issues were found, list each issue with a brief description.
   - If no issues were found, state: "No issues found. Checked for bugs and CLAUDE.md compliance."
   ...
   If `--comment` argument IS provided and issues were found, continue to step 8.
8. Create a list of all comments that you plan on leaving. This is only for you to make sure you are comfortable with the comments. Do not post this list anywhere.
9. Post inline comments for each issue using `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`.
   ...

Bemerkung am Rande: Der Workflow ermittelt in einem expliziten Schritt (Schritt 2), welche CLAUDE.md-Dateien relevant sind. Dadurch ist dieser Aspekt klar definiert und muss in den Folgeschritten nicht erneut abgeleitet werden.

Das Review: Unterschiedliche Subagenten für verschiedene Aspekte

Bei der Durchführung des Reviews in Schritt 4 starten vier Agenten parallel. Anstatt eines "One-fits-all"-Ansatzes erhalten die Agenten dedizierte Fokusthemen. Interessanterweise haben zwei davon exakt dieselbe Aufgabe: Die Prüfung der CLAUDE.md-Compliance wird doppelt durchgeführt. Diese Redundanz herhöht die Wahrscheinlichkeit, Fehler aufzudecken, erheblich.

Launch 4 agents in parallel to independently review the changes. Each agent should return the list of issues, where each issue includes a description and the reason it was flagged (e.g. "CLAUDE.md adherence", "bug"). The agents should do the following:

   Agents 1 + 2: CLAUDE.md compliance sonnet agents
   Audit changes for CLAUDE.md compliance in parallel. Note: When evaluating CLAUDE.md compliance for a file, you should only consider CLAUDE.md files that share a file path with the file or parents.

   Agent 3: Opus bug agent (parallel subagent with agent 4)
   Scan for obvious bugs. Focus only on the diff itself without reading extra context. Flag only significant bugs; ignore nitpicks and likely false positives. Do not flag issues that you cannot validate without looking at context outside of the git diff.

4. Agent 4: Opus bug agent (parallel subagent with agent 3)
   Look for problems that exist in the introduced code. This could be security issues, incorrect logic, etc. Only look for issues that fall within the changed code.

   **CRITICAL: We only want HIGH SIGNAL issues.** Flag issues where:
   - The code will fail to compile or parse (syntax errors, type errors, missing imports, unresolved references)
   - The code will definitely produce wrong results regardless of inputs (clear logic errors)
   - Clear, unambiguous CLAUDE.md violations where you can quote the exact rule being broken

   Do NOT flag:
   - Code style or quality concerns
   - Potential issues that depend on specific inputs or state
   - Subjective suggestions or improvements

   If you are not certain an issue is real, do not flag it. False positives erode trust and waste reviewer time.

   In addition to the above, each subagent should be told the PR title and description. This will help provide context regarding the author's intent.

Validierung im neuen Kontext

Schritt 5 beinhaltet eine explizite Validierung der gefundenen Issues durch einen völlig neuen Agenten.

5. For each issue found in the previous step by agents 3 and 4, launch parallel subagents to validate the issue. These subagents should get the PR title and description along with a description of the issue. The agent's job is to review the issue to validate that the stated issue is truly an issue with high confidence. For example, if an issue such as "variable is not defined" was flagged, the subagent's job would be to validate that is actually true in the code. Another example would be CLAUDE.md issues. The agent should validate that the CLAUDE.md rule that was violated is scoped for this file and is actually violated. Use Opus subagents for bugs and logic issues, and sonnet agents for CLAUDE.md violations.

Diese Trennung stellt sicher, dass die Validierung nicht durch den vorherigen Suchvorgang beeinflusst wird, was das Gesamtsystem robuster gegenüber False Positives macht.

GoTo statt "come from"

Der Ablauf wird durch stringente "GoTo"-artige Anweisungen gesteuert, anstatt auf eine deklarative "come from" Logik zu setzen. Das formuliert den Prozess deutlich klarer und anweisender.

7. Output a summary of the review findings to the terminal:
   - If issues were found, list each issue with a brief description.
   - If no issues were found, state: "No issues found. Checked for bugs and CLAUDE.md compliance."

   If `--comment` argument was NOT provided, stop here. Do not post any GitHub comments.

   If `--comment` argument IS provided and NO issues were found, post a summary comment using `gh pr comment` and stop.

   If `--comment` argument IS provided and issues were found, continue to step 8.

Die Toolbox des pr-review-toolkit Plugins

Dieses Plugin setzt sich aus einem Command (review-pr) und sechs spezialisierten Agenten zusammen. Das Command definiert den Workflow, der die jeweiligen Agenten orchestriert.

• code-reviewer (Modell Opus): Prüft Code gegen CLAUDE.md-Regeln und erkennt echte Bugs (Logic Errors, Security, Race Conditions). Nutzt ein Confidence-Scoring von 0-100; nur Issues ≥ 80 werden gemeldet.
• code-simplifier (Modell: Opus) :Vereinfacht und refactored Code aktiv. Der Fokus liegt auf Lesbarkeit und Konsistenz bei vollständigem Erhalt der Funktionalität.
• silent-failure-hunter (Modell: inherit): Sucht leere Catch-Blocks, verschluckte Exceptions und stille Fallbacks. Ziel: Jeder Fehler muss sichtbar geloggt oder weitergereicht werden. Arbeitet mit einer Checkliste von Anti-Patterns.
• comment-analyzer (Modell: inherit): Prüft Kommentare auf faktische Korrektheit gegenüber dem tatsächlichen Code. Identifiziert irreführende Dokumentation aus der Perspektive eines Entwicklers, der den Code Monate später liest.
• pr-test-analyzer (Modell: inherit): Bewertet Test-Coverage nach Verhalten statt Zeilenabdeckung. Identifiziert fehlende Edge-Cases. Jede Empfehlung erfordert eine Criticality-Bewertung (1–10) und benennt den verhinderten Regressionsfehler.
• type-design-analyzer (Modell: inherit): Bewertet Typ-Design auf vier Dimensionen (je 1-10): Encapsulation, Invariant Expression, Usefulness, Enforcement. Identifiziert Anti-Patterns wie anämische Domain-Modelle oder exponierte Mutabilität.

Das Bemerkenswerteste an dieser Architektur die Tatsache, dass das die KI selbstständig entscheidet, welche Agenten für das jeweilige Review relevant sind und ob deren Ausführung parallel oder sequenziell erfolgt (Schritt 2, 4, 5).

## Review Workflow:

1. **Determine Review Scope**
   - Check git status to identify changed files
   - Parse arguments to see if user requested specific review aspects
   - Default: Run all applicable reviews

2. **Available Review Aspects:**

   - **comments** - Analyze code comment accuracy and maintainability
   - **tests** - Review test coverage quality and completeness
   - **errors** - Check error handling for silent failures
   - **types** - Analyze type design and invariants (if new types added)
   - **code** - General code review for project guidelines
   - **simplify** - Simplify code for clarity and maintainability
   - **all** - Run all applicable reviews (default)

3. **Identify Changed Files**
   - Run `git diff`...

4. **Determine Applicable Reviews**

   Based on changes:
   - **Always applicable**: code-reviewer (general quality)
   - **If test files changed**: pr-test-analyzer
   - **If comments/docs added**: comment-analyzer
   - **If error handling changed**: silent-failure-hunter
   - **If types added/modified**: type-design-analyzer
   - **After passing review**: code-simplifier (polish and refine)

5. **Launch Review Agents**

   **Sequential approach** (one at a time):
   - Easier to understand and act on
   - Each report is complete before next
   - Good for interactive review

   **Parallel approach** (user can request):
   - Launch all agents simultaneously
   - Faster for comprehensive review
   - Results come back together

6. **Aggregate Results**
   ...
7. **Provide Action Plan**
   ...

Teil II: Prompt-Craft im Detail

Am konkreten Code lässt sich am besten lernen. Daher zitiert dieses Kapitel Ausschnitte die besonders bemerkenswert sind.

Explizit proaktive Trigger für den Einsatz der Agenten

Die Prompts beschreiben sehr explizit, wie ein Agent proaktiv und explizit getriggert wird. Beispiele:

code-reviewer: This agent should be used proactively after writing or modifying code...

code-simplifier: This agent should be triggered automatically after completing a coding task or writing a logical chunk of code.

Dabei kommen auch semantisch höherwertige Trigger kommen zum Einsatz, wie beim type-design-analyzer.

description: Use this agent when you need expert analysis of type design in your codebase.
Specifically use it:
(1) when introducing a new type to ensure it follows best practices for encapsulation and invariant expression,
(2) during pull request creation to review all types being added,
(3) when refactoring existing types to improve their design quality. The agent will provide both qualitative feedback and quantitative ratings on encapsulation, invariant expression, usefulness, and enforcement.

Die Beschreibungen sind dabei nicht nur deskriptiv sondern verwenden auch Beispiele für einen Chat-Verlauf in der Beschreibung

name: code-reviewer
description: ...
Examples:
...
<example>
Context: The assistant has just written a new utility function.
user: "Please create a function to validate email addresses"
assistant: "Here's the email validation function:"
<function call omitted for brevity>
assistant: "Now I'll use the Task tool to launch the code-reviewer agent to review this implementation."
<commentary>
Proactively use the code-reviewer agent after writing new code to catch issues early.
</commentary>
</example>
...

Explizites Review Scoring

Das System nutzt klare, explizit beschriebene Scoring-Modelle. Der code-reviewer definiert feste Konfidenz-Intervalle und meldet nur Issues ab einem Wert von 80. Ein weiteres Beispiel liefert der pr-test-analyzer, der konkrete Bewertungsdimensionen vorgibt.

(Beispiel code-reviewer Agent)

## Issue Confidence Scoring

Rate each issue from 0-100:

- **0-25**: Likely false positive or pre-existing issue
- **26-50**: Minor nitpick not explicitly in CLAUDE.md
- **51-75**: Valid but low-impact issue
- **76-90**: Important issue requiring attention
- **91-100**: Critical bug or explicit CLAUDE.md violation

**Only report issues with confidence ≥ 80**
...

Eine weitere gibt es imim pr-test-analyzer Agenten die die Dimensionen nennt die bewertet werden sollen.

**Analysis Framework:**
...
1. **Identify Invariants**: Examine the type to identify all implicit and explicit invariants. ...
2. **Evaluate Encapsulation** (Rate 1-10): ...
3. **Assess Invariant Expression** (Rate 1-10): ...
4. **Judge Invariant Usefulness** (Rate 1-10): ...
5. **Examine Invariant Enforcement** (Rate 1-10): ...

Detaillierter Workflow für die Verbesserung

Die Agenten enthalten detaillierte Workflows, die vorgeben, wie nach Verbesserungsmöglichkeiten gesucht werden soll. Beim code-simplifier sticht besonders der zweite Schritt hervor, der die KI zwingt, aktiv nach Möglichkeiten für mehr Eleganz und Konsistenz zu suchen.

Your refinement process:

1. Identify the recently modified code sections
2. Analyze for opportunities to improve elegance and consistency
3. Apply project-specific best practices and coding standards
4. Ensure all functionality remains unchanged
5. Verify the refined code is simpler and more maintainable
6. Document only significant changes that affect understanding

Weiche Vorgaben durch "Gefühl"

Oft ist es zielführender, dem Agenten ein "Gefühl" oder eine grundlegende Haltung zu vermitteln, anstatt starre Regeln zu diktieren. Folgende Ansätze verdeutlichen das:

Priorisierung statt absoluter Regeln: Der code-simplifier gewichtet Lesbarkeit ausdrücklich höher als extreme Kompaktheit

You prioritize readable, explicit code over overly compact solutions.

Zielsetzung vor Umsetzung: Beim comment-analyzer wird sehr plastisch beschrieben, aus welchem Blickwinkel der Code betrachtet werden soll. Meiner Meinung nach ist das ein brillanter Schachzug: Die KI liest die Kommentare konsequent aus der Perspektive eines Entwicklers, der den Code Monate später ohne Kontext warten muss und nicht aus der Sicht des ursprünglichen Autors.

Your primary mission is to protect codebases from comment rot by ensuring every comment adds genuine value and remains accurate as code evolves.
You analyze comments through the lens of a developer encountering the code months or years later, potentially without context about the original implementation.

Teil III: Übertragbare Patterns

Die Detailanalyse offenbart wiederkehrende Strukturen, die weit über den spezifischen Anwendungsfall "Code Review" hinausgehen.

Pattern 1: Model Tiering

• Beobachtung: Das System setzt verschiedene Modelle sehr bewusst ein: Haiku für günstige Gate-Checks, Sonnet für Zusammenfassungen und Opus ausschließlich für komplexe Bug-Erkennung.
• Regel: Nicht jeder Schritt in einer Pipeline erfordert das stärkste Modell. Identifiziere präzise, welche Aufgaben hohe Intelligenz benötigen und wo reines Pattern-Matching ausreicht.

Pattern 2: Two-Stage Validation

• Beobachtung: Issues werden erst gesammelt und anschließend von einem separaten Agenten validiert. Nur bestätigte Issues schaffen es in den Bericht.
• Regel: Die Problemidentifikation muss von der Problembewertung getrennt werden, in verschiedenen Kontexten/Agenten. Das minimiert die Auswirkungen von False Positives erheblich.
• Übertragung: Nach meiner Erfahrung ist dieses Pattern essenziell, sobald Nutzer den KI-Ergebnissen vertrauen müssen. Die Trennung der Kontexte durch verschiedene Agenten minimiert False Positives enorm.

Pattern 3: Redundant Agents - "Self-Consistency Prompting"

• Beobachtung: Das Pipeline-Plugin startet zwei identische Agenten, die exakt denselben Änderungssatz unabhängig voneinander prüfen.
• Regel: Wenn Zuverlässigkeit Vorrang vor Effizienz hat, sollten Analysen mehrfach ausgeführt werden. Durch die stochastische Natur von LLMs deckt ein zweiter Durchlauf oft Punkte auf, die beim ersten Mal übersehen wurden.
• Übertragung: Überall dort, wo Korrekte Ergebnisse kritisch sind, ist bewusste Redundanz für eine exzellente Architekturentscheidung.

Pattern 4: Explicit Negative Lists

• Beobachtung: Der Prompt definiert klipp und klar, was kein Issue ist (z. B. vorbestehende Probleme, Nitpicks, Linter-Issues).
• Regel: Sage der KI nicht nur, was sie tun soll, sondern explizit auch, was sie lassen soll. Negative Constraints wirken oft stärker als positive Instruktionen.
• Übertragung: Jeder Agent, der Entscheidungen trifft, profitiert massiv von einer solchen Ausschlussliste.

Fazit

Zwei Plugins und wenige hundert Zeilen Markdown genügen, um einen kompakten Lehrgang in KI-Agenten-Architektur zu liefern. Die Patterns, die Anthropic in diesen Review-Plugins anwendet, sind keine theoretischen Konzepte sonden echte Praxis. Die angesprochenen Plugins sind Open Source auf GitHub verfügbar. Meiner Meinung nach gibt es keinen besseren nächsten Schritt, als sich diese selbst im Detail anzusehen.