Code Review mit Claude Code: Finde Bugs, bevor sie in die Produktion gelangen

Was ist Claude Code Review?

Claude Code Review ist ein Multi-Agent-Code-Reviewsystem, das einen PR im Kontext des Repos betrachtet und potenzielle Bugs, Sicherheitsprobleme und Regressionen meldet. GitHub Code Review lässt diese Agents gegen einen GitHub-PR laufen, während das lokale /code-review dir direkt aus Claude Code eine Review deines aktuellen Diffs liefert.

Wichtig ist hier der Kontext. Ein klassisches Diff-Review bittet jemanden, die geänderten Zeilen zu prüfen. Claudes Review-Agents betrachten diese Änderungen im Kontext des gesamten Repos. Der GitHub-Workflow nutzt mehrere spezialisierte Agents parallel, gefolgt von Verifikation, Deduplikation und Schweregrad-Bewertung.

Beispielsweise kann eine 10-Zeilen-Änderung an einer pandas-Transformation vom Schema eines vorgelagerten dbt-Modells, dem Grain einer Snowflake-Tabelle und Annahmen in einem nachgelagerten Dashboard abhängen.

Claude genehmigt oder blockiert einen PR nicht. GitHub Code Review meldet ein neutrales Check-Ergebnis, daher bleiben bestehende Branch-Protection-Regeln unverändert, außer du baust eigene CI-Logik um die Check-Ausgabe herum.

Drei Review-Oberflächen

Derzeit gibt es 3 Hauptwege, Code mit Claude Code zu reviewen.

Der lokale Befehl /code-review prüft die Commits deines Branches. Du kannst ihm auch eine bestimmte Datei, einen Branch, eine PR-Nummer oder einen Git-Ref-Bereich übergeben.

GitHub Code Review ist rund um den PR selbst konzipiert. Je nach Repo-Konfiguration kann es einmalig nach PR-Erstellung, nach jedem Push oder nur auf Anforderung per @claude review prüfen.

/code-review ultra ist die schwergewichtigere Option. Anthropic nennt die Funktion ultrareview, und /ultrareview funktioniert als Alias, wenn sie für deinen Account freigeschaltet ist. Eine Flotte von Review-Agents läuft in einer Remote-Sandbox; jeder gemeldete Bug wird reproduziert und verifiziert, bevor er in den Findings erscheint. Aktuell ist das eine Research Preview, ein typischer Lauf dauert 5 bis 10 Minuten.

Was Claude flaggt – und was nicht

Claude Code Review priorisiert Korrektheit. In der Dokumentation von Anthropic werden produktionsrelevante Bugs klar von Formatierungspräferenzen und fehlender Testabdeckung unterschieden.

Die Findings nutzen 3 Schweregrade:

Diese Unterscheidung ist hilfreich, weil Data Scientists oft sehr unterschiedliche Vorstellungen haben, was Review-Zeit verdient. Ein Namensvorschlag zu revenue_df versus weekly_revenue ist nicht dasselbe Kaliber wie eine Umsatzverdopplung, weil sich ein Many-to-Many-Join in eine Transformation geschlichen hat.

Wie richtest du Code Review in Claude Code ein?

Das Setup von Claude Code Review unterscheidet sich je nach lokalem Review oder GitHub-PR-Review. Das lokale /code-review benötigt keine GitHub App und kann erfolgen, bevor du überhaupt einen PR öffnest. 

Für GitHub Code Review muss ein Owner oder Primary Owner der Organisation die Claude GitHub App konfigurieren und Repos auswählen. Für PR-Reviews solltest du eine spezielle Datei REVIEW.md anlegen, die reine Review-Regeln enthält.

CLAUDE.md vs. REVIEW.md

CLAUDE.md und REVIEW.md haben unterschiedliche Zwecke – das Vermischen führt schnell zu lauten, unpräzisen Reviews.

CLAUDE.md enthält allgemeine Projektanweisungen, die Claude aufgabenübergreifend nutzt. Code Review liest diese ebenfalls; neu eingeführte Verstöße werden als Nits gemeldet.  REVIEW.md ist hingegen speziell für das Review-Verhalten und sagt den Review-Agents, was dein Team flaggen, überspringen oder als Wichtig behandeln will.

Für ein Python-Data-Repo würde ich CLAUDE.md auf Dinge wie Repo-Struktur, wie man pytest ausführt, ob Transformationen pandas oder polars nutzen und wo SQL-Modelle liegen, fokussieren. 

Regeln fürs Review kämen in REVIEW.md. Mögliche Beispiele:

• „Prüfe jede neue Transformation auf einen passenden Test.“
• „Niemals Zugangsdaten loggen."
• „Generierte Dateien überspringen."

Eine kleine  REVIEW.md könnte so aussehen:

# Review instructions

## Important findings

Report as Important:
- Incorrect joins or filters that can change dataset grain
- Missing tenant or customer scoping
- Secrets or credentials written to logs
- Silent changes to revenue or customer metrics

## Do not report
- Formatting already enforced by Ruff
- Generated files
- *.lock files

## Always check
- New transformations have tests
- Joins use the intended keys
- Datetime operations specify timezone assumptions
- Missing values are handled explicitly

Ich empfehle, REVIEW.md schlank zu halten, damit wichtige Regeln nicht verwässern. Die aktuelle Implementierung liest die Datei außerdem als reine Anweisungen – lege Regeln direkt hinein statt den @-Shortcut zu verwenden. 

Übrigens: Beim lokalen Entwickeln liest /code-review REVIEW.md nicht. Es folgt CLAUDE.md, während die GitHub-Code-Review-Pipeline REVIEW.md für review-spezifische Instruktionen nutzt.

Wenn du lokal und auf GitHub dieselben Review-Regeln willst, packe die allgemeinen Regeln in CLAUDE.md und wiederhole die review-spezifischen Regeln bei Bedarf in REVIEW.md.

Für mehr Details lies unseren Guide zum Schreiben der besten CLAUDE.md.

GitHub App und Trigger-Modus

GitHub Code Review wird von einem Owner oder Primary Owner der Organisation in den Admin-Einstellungen von Claude konfiguriert. Die Admin-Person installiert die Claude GitHub App, erteilt Repo-Zugriff, wählt die zu prüfenden Repos und weist jedem Repo ein Review-Verhalten zu.

Es gibt 3 Trigger-Modi:

Eine Ausnahme gilt für alle 3: Claude reviewt niemals automatisch einen Pull Request aus einem Fork. Jemand muss @claude review kommentieren.

Seit dem Update im Juli 2026 haben sich die manuellen Befehle ebenfalls geändert: 

• @claude review startet eine einzelne Review und abonniert den PR nicht für zukünftige Pushes. 

• @claude review always startet eine Review und abonniert den PR für Push-getriggerte Reviews in Zukunft.

• @claude review once verhält sich wie der nackte Befehl.

Wenn du Claude Code Review Anfang 2026 gelernt hast, könnten ältere Tutorials noch sagen, dass @claude review den PR für spätere Reviews abonniert. Das änderte sich im Juli 2026 und gilt weiterhin im September 2026.

Pro- und Max-User ohne Zugriff auf das GitHub Code Review der Organisation können die App komplett überspringen und lokal /code-review nutzen – mit /code-review ultra für eine tiefere Review.

Wie prüfst du ein Diff lokal mit /code-review?

Der lokale Befehl /code-review prüft deinen aktuellen Branch, bevor du einen PR öffnest. Ich starte immer damit, weil Probleme so früh auffallen – und fehlgeschlagene CI vermieden werden können.

Der Fall für die Review

Angenommen, wir haben ein E-Commerce-Repo mit einer Orders-Tabelle mit order_id, customer_id, order_date, status und revenue und erstellen weekly_revenue.py, um den Wochenumsatz zu berechnen:

orders = load_orders()
customers = load_customers()

# Derive the reporting week from the order date
orders["week"] = orders["order_date"].dt.to_period("W").dt.start_time

weekly_revenue = (
    orders
    .merge(customers, on="customer_id", how="inner")
    .groupby("week", as_index=False)["revenue"]
    .sum()
)

Auf den ersten Blick wirkt alles unauffällig. Das merge() ist explizit, das Grouping ist lesbar, und die Umsatzaggregation erfolgt nach dem Join.

Das Problem: Die Kundentabelle enthält für manche Kunden mehrere historische Einträge. Ein Kunde mit 2 Datensätzen produziert nach dem Join 2 Zeilen – und verdoppelt so den diesem Kunden zugeordneten Umsatz. Genau solche Bugs übersieht man leicht, wenn man die Transformation lokal liest, ohne den Table-Grain zu prüfen.

Den Diff einschränken

Führe in deiner Claude-Code-Session /code-review aus.

Der Befehl prüft die Commits deines aktuellen Branches gegenüber dem Upstream-Branch sowie uncommittete Änderungen. Du kannst auch eine Datei, einen Branch, einen PR oder einen Bereich wie main...feature/weekly-revenue angeben.

Zum Beispiel:

/code-review weekly_revenue.py

oder:

/code-review main...feature/weekly-revenue

Du kannst auch ein Effort-Level setzen, z. B. /code-review high. Bei low und medium meldet die Review nur die Funde mit höchster Sicherheit, während high bis max die Abdeckung erweitert – mit dem Risiko von mehr False Positives. 

Mit Flags die Review steuern

Mit der Zeit werden zwei Flags besonders nützlich: 

• --fix wendet Funde nach der Review auf deinen Working Tree an.

• --comment postet sie als Inline-Kommentare.

Claude führt die Review als Hintergrund-Subagent aus – du kannst weiterarbeiten, während die Änderung verarbeitet wird. Die Findings kommen zurück in deine Session, sobald die Review fertig ist.

Die Review könnte etwa Folgendes melden:

🔴 Important
weekly_revenue.py:9

The merge on customer_id can duplicate order rows because
customers contains multiple records per customer. This can
inflate revenue when a customer has more than one matching
customer record.

Verify that customer_id is unique in customers or join against
the intended current-record subset before aggregating revenue.

Die Review benennt einen konkreten Fehlerfall und gibt mir etwas, das ich am tatsächlichen Schema verifizieren kann – statt Claudes Urteil blind zu vertrauen.

Die Findings lesen

Ich würde trotzdem alles manuell prüfen, bevor ich /code-review --fix ausführe. Suche zunächst den Code, der customers erstellt, prüfe die Eindeutigkeits-Constraints und sieh dir die Tests rund um weekly_revenue.py an.

Wenn customers.customer_id wirklich eindeutig ist, ist Claudes Fund ein False Positive. Wenn die Tabelle pro Kunde und Gültigkeitsdatum eine Zeile enthält, ist der Fund real – und die Transformation muss angepasst werden.

Der springende Punkt: Claudes Reviewer schaut auf das Codeverhalten, während ich weiterhin wissen muss, was die Daten fachlich bedeuten.

Du kannst Claude nach der Review um weitere Untersuchung bitten:

Investigate the customer_id join finding.
Check how the customers table is built and determine whether
customer_id is unique at the point of this merge. Do not modify
the code yet.

Dieser zweite Schritt ist oft hilfreicher, als Claude stumpf den Kommentar „fixen“ zu lassen. So wird aus der Review eine kurze Untersuchung – keine reine Code-Generierung.

Wie läuft Claude Code Review auf einem GitHub-PR?

GitHub Code Review bringt Claudes Findings direkt in den PR – Reviewer sehen das Problem neben der Codeänderung. 

Die Reihenfolge ist wichtig, weil die Review an einen bereits existierenden PR angehängt wird:

1. Push den Branch weekly-revenue per git push zu GitHub.

2. Öffne den Pull Request. Claude kann nur offene PRs prüfen; vorher passiert nichts.

3. Ist das Repo auf automatischen Trigger gestellt, startet die Review automatisch. Bei Manuell poste @claude review als Top-Level-PR-Kommentar, um sie zu starten.

Drei Anforderungen führen hier oft zu Stolpersteinen: Der Befehl muss ein Top-Level-PR-Kommentar sein (keine Antwort auf einen Inline-Kommentar), und du brauchst Schreib-, Maintain- oder Admin-Rechte im Repo. Außerdem muss der Befehl den Kommentar beginnen – mit once oder always in derselben Zeile, wenn sie ergänzt werden.

Die Review auslösen

Kostenrelevant ist die Wahl zwischen den beiden manuellen Befehlen – nicht zwischen manuell und automatisch.

@claude review führt eine einzelne Review aus und lässt den PR unabonniert. @claude review always startet eine Review und abonniert den PR, sodass jeder spätere Push eine neue Review auslöst.

Dies ist das Verhalten seit Juli 2026 und Stand September 2026. Zuvor abonnierte der nackte Befehl @claude review zukünftige Reviews. Wenn du einem älteren Tutorial folgst, prüfe das zuerst.

Die Review dauert oft rund 20 Minuten, wobei Anthropic sagt, dass Kosten und Dauer von Größe und Komplexität des PR abhängen. Jede Review wird zudem separat über Nutzungsguthaben abgerechnet und verbraucht nicht das inkludierte Kontingent des Team- oder Enterprise-Plans. Wenn du mehr über die Kostenstruktur wissen willst, lies unseren Guide zu Nutzungsgrenzen von Claude Code.

Inline-Kommentare und Check-Run lesen

Nach Abschluss postet Claude Inline-Kommentare an den relevanten Zeilen. Der GitHub-Check enthält außerdem eine Schweregrad-Zusammenfassung – hilfreich, wenn ein PR mehrere Findings in weekly_revenue.py, SQL-Modellen und Testdateien hat.

Zum Beispiel:

Der Inline-Kommentar ist der Ort für die eigentliche Untersuchung. Der Check-Run liefert den Überblick.

Wichtig: Ein Klick auf 👍 oder 👎 triggert keine neue Review, und das Beantworten eines Inline-Kommentars führt nicht dazu, dass Claude reagiert. Für eine erneute Review: Code fixen und pushen oder @claude review als neuen Top-Level-PR-Kommentar posten.

Die Review blockiert den Merge nicht automatisch. Der Check ist neutral, enthält aber maschinenlesbare Schweregrad-Infos, die ein Team z. B. via gh und jq auswerten kann, um ein eigenes Merge-Gate zu bauen.

Wie triagierst du Claudes Review-Kommentare?

Der Zweck ist, den Menschen in der Schleife zu behalten. Das heißt: Jede Claude-Review erfordert die Entscheidung, ob ein Fund ein echter Bug, eine nicht-blockierende Verbesserung oder ein False Positive ist. Denn ein Reviewer kann Implementierungsverhalten prüfen, kennt aber nicht zwingend alle fachlichen Annahmen hinter Datensätzen oder Metriken.

Ich nutze eine einfache 3-Wege-Entscheidung:

Diese letzte Kategorie ist wichtig. Ein Reviewer mit 30 Findings ist nicht automatisch besser als einer mit 5. Ein False-Positive-Kommentar zu einem pandas-Merge kann mehr Zeit kosten als die ursprüngliche Codeänderung.

Fixen, überspringen oder zurückweisen

Ist der Bug mit den duplizierten Kundenzeilen real, kann ich Claude bitten, das Upstream-Modell zu prüfen und dann folgenden Fix umzusetzen:

The customer_id finding is valid. Inspect the existing customer
model and update weekly_revenue.py to join only the current
customer record. Add a regression test for a customer with
multiple historical records, then run the relevant tests.

Claude kann dann das Repo inspizieren, den Python-Code ändern, den Test hinzufügen und die Testsuite ausführen.

Wenn du aus GitHub-Review-Kommentaren arbeiten willst, kann Claude Code auch über die GitHub CLI (gh) mit dem Repo interagieren. Wichtig ist: Wähle die konkreten Fixes aus, die du für valide hältst – statt „alles“ automatisch reparieren zu lassen.

So bleiben Entwickler im Review-Loop:

1. Claude findet ein mögliches Problem.
2. Ich verifiziere es anhand von Code und Datenannahmen.
3. Claude setzt den gewünschten Fix um.
4. Tests laufen.
5. Claude reviewt das resultierende Diff erneut.

Dieser Kreislauf ist deutlich sicherer, als die erste Review-Ausgabe wie eine automatische Refactor-Queue zu behandeln.

Wofür braucht ein Data-PR weiterhin Menschen?

Der Ausfallmodus, den Claude nicht abdeckt: Code läuft korrekt – tut aber trotzdem das Falsche. Drei Varianten tauchen immer wieder auf:

• Annahmen außerhalb des Diffs. Claude liest dein Repo, nicht dein Data Warehouse, deinen Config-Service oder Verträge eines anderen Teams. Ein Join kann die richtigen Keys nutzen und dennoch den Grain des Ergebnisses verändern, denn die Zeilenanzahl pro Key ist eine Eigenschaft der Upstream-Tabelle, nicht des Codes vor dir.

• Definitionen, die nur dein Team hält. Ob Umsatz auf Order-, Kunden- oder Wochenebene gezählt werden soll, ist eine Business-Entscheidung. Claude kann dir sagen, dass ein groupby() alles summiert, was es bekommt. Es kann dir nicht sagen, welche Zahl Finance abzeichnet.

• Zeit- und Typannahmen. Bedeutet 2026-08-27 einen UTC-Tag, einen lokalen Geschäftstag oder ein Reporting-Datum eines Upstream-Modells? Stillen Typzwang gibt es ebenso: Operationen über Objekt-, nullbare Integer-, timezone-aware Datetime- und String-Spalten liefern etwas Plausibles – ändern aber heimlich Vergleichslogik.

Data Leakage ist das schärfste Beispiel der ersten Kategorie. Eine Feature-Transformation kann ein Trainingsset mit einer Tabelle joinen, die Informationen erst nach dem Vorhersagedatum enthielt. Der Join ist gültig, die Zeilenzahl stimmt – und das Modell ist verfälscht.

Ich behandle Claude daher als Reviewer des Implementierungsverhaltens – nicht als Eigentümer der Definition.

Wann solltest du Code Review vs. Ultrareview nutzen?

Nutze /code-review für schnelles lokales Feedback und /code-review ultra für einen tieferen Pre-Merge-Check. Beide prüfen Code, aber /code-review ist für Iteration gedacht, während die Ultra-Review mehrere Remote-Agents einsetzt und gemeldete Bugs unabhängig verifiziert.

Anthropic beschreibt die Ultra-Review derzeit als Research Preview. Pro- und Max-Abonnenten erhalten einmalig 3 kostenlose Läufe (ohne Auffrischung), danach kostet eine Review typischerweise 5 bis 25 $, abhängig von der Größe der Änderung. Team- und Enterprise-Nutzer erhalten diese Freiläufe nicht; die Funktion ist nicht verfügbar auf Amazon Bedrock, Google Clouds Agent Platform, Microsoft Foundry sowie für Organisationen mit Zero Data Retention.

Der wichtige Unterschied ist die Verifikation. /code-review ultra sendet den Repo-Stand in eine Remote-Sandbox und lässt eine Flotte von Reviewer-Agents laufen; gemeldete Bugs werden unabhängig reproduziert, bevor sie als Findings zurückkommen.

Ich würde das nicht bei jedem Commit laufen lassen. Wenn ich nur einen Variablennamen in einem Python-Notebook ändere oder das Format eines dbt-Modells anpasse, reicht ein lokales /code-review. Wenn ich die Feature-Generierung eines Produktionsmodells ändere, eine Umsatztransformation neu schreibe oder eine kundenbezogene Aggregation modifiziere, ergibt der zusätzliche Review-Pass Sinn.

Es gibt auch einen Namensfeinschliff. Der dokumentierte Befehl lautet /code-review ultra, und /ultrareview ist ein Alias, der funktioniert, wenn ultrareview für deinen Account verfügbar ist. Ältere Tutorials stellen /ultrareview oft als Primärbefehl dar, aber die Dokumentation von Anthropic behandelt die tiefe Cloud-Review mittlerweile als Teil der /code-review-Befehlsfamilie. /code-review ultra fällt auf eine lokale Review zurück, wenn die Cloud-Funktion nicht verfügbar ist.

Ultra-Review auf demselben PR ausführen

Im Repo ausführen:

/code-review ultra

Um direkt einen GitHub-PR zu prüfen:

/code-review ultra <pr#>

Ohne Argument vergleicht /code-review ultra deinen aktuellen Branch mit dem Default-Branch und inkludiert uncommittete und gestagte Änderungen. Ein Branch-Review ist standardmäßig bei ca. 500 geänderten Dateien und 8.000 geänderten Zeilen gedeckelt; Anthropic weist darauf hin, dass sich diese Zahlen ändern können. Ist dein Diff zu groß, pushe den Branch und reviewe ihn stattdessen als PR.

Mit einer PR-Nummer klont die Remote-Umgebung den PR von GitHub – von deiner Maschine wird nichts hochgeladen.

Vor dem Start zeigt Claude den Review-Umfang, verbleibende freie Läufe und die Kostenschätzung. Nach Bestätigung läuft die Review im Hintergrund – du kannst Claude Code währenddessen weiter nutzen.

Für unser weekly_revenue.py-Beispiel würde ich die Findings vergleichen – nicht automatisch annehmen, dass die tiefere Review immer recht hat.

Wenn /code-review den Kunden-Join flaggt und die Ultra-Review dieselbe Umsatzverdopplung unabhängig reproduziert, steigt mein Vertrauen in diesen Fund. Ignoriert die Ultra-Review ihn, weil die Upstream-Tabelle Eindeutigkeit garantiert, würde ich die Evidenz beider Reviews und die tatsächliche Modelldefinition prüfen, bevor ich den Code ändere.

Das ist ein Vorteil mehrerer Reviewer: Uneinigkeit liefert Ansatzpunkte für die Untersuchung.

Es gibt auch eine Kostenperspektive. GitHub Code Review kostet derzeit im Schnitt 15 bis 25 $ pro Review, während die Ultra-Review nach den freien Pro-/Max-Läufen typischerweise 5 bis 25 $ kostet. GitHub-Code-Review-Kosten sind getrennt vom inkludierten Plan-Nutzungskontingent; Anthropic bietet für Organisationen Ausgabensteuerung.

Wenn du allein arbeitest, ist lokales /code-review plus gelegentliches /code-review ultra ein solider Start-Workflow. Wenn ihr im Team- oder Enterprise-Plan seid und jeder PR automatisch eine Review tragen soll, ergibt GitHub Code Review mehr Sinn.

Ein praxisnaher Claude-Code-Review-Workflow

Der nützliche Workflow ist nicht „Claude vor jedem Merge laufen lassen“. Es ist eine Abfolge, in der jede Review zu einem anderen Zeitpunkt stattfindet – mit unterschiedlichen Kosten und unterschiedlichen Problemklassen.

So würde ich bei einer Produktivänderung vorgehen:

Write code
	   ↓
Run tests and data checks
	   ↓
/code-review
	   ↓
Fix verified findings
	   ↓
Open GitHub PR
	   ↓
GitHub Code Review
	   ↓
Human triage
	   ↓
/code-review ultra for higher-risk changes
	   ↓
Final tests
	   ↓
Human merge

Die lokale Review fängt Probleme ab, solange sie billig zu beheben sind. Die GitHub-Review liefert dem Team einen gemeinsamen Nachweis der Findings, während die Ultra-Review eine aufwändigere Zweitmeinung vor einem folgenreichen Merge bietet.

Zusätzliche Checks für Data Scientists

Für Datenarbeit würde ich 4 Checks rund um Claude ergänzen – statt zu erwarten, dass das Modell die gesamte Review übernimmt:

• Zeilenanzahl und Dataset-Grain vor und nach wichtigen Joins prüfen
• Unit- oder Integrationstests um Transformationen und Feature-Logik ausführen.
• Bei ML-Features auf Leakage prüfen.
• Business-Metriken gegen eine verifizierte Abfrage oder ein Dashboard validieren.

Claude kann an allen 4 Aktivitäten teilnehmen – aber das erwartete Ergebnis sollte aus Code, Tests oder Daten stammen, nicht aus Claudes Erklärung.

Fazit

Claude Code Review funktioniert am besten, wenn ich es wie eine weitere Ingenieurin im Review-Thread behandle – nicht wie einen automatischen Abnicker.

Der lokale Befehl /code-review liefert dir eine schnelle Review, bevor der PR existiert. GitHub Code Review bringt Multi-Agent-Funde in den PR für Team- und Enterprise-Organisationen, während /code-review ultra dir eine tiefere Remote-Review gibt, wenn die Änderung eine zweite Runde verdient.

Ich würde klein starten: Baue /code-review in deinen normalen Branch-Workflow ein, schreibe eine kurze REVIEW.md für deine GitHub-Reviews und nutze /code-review ultra bei Änderungen, bei denen ein schlechter Merge wirklich teuer wäre.

Für die Modellgrundlagen bietet unser Kurs Introduction to Claude Models den weiteren Kontext; GitHub Foundations und Intermediate GitHub Concepts decken den Git- und GitHub-Workflow ab, auf dem Code Review aufsetzt. Mehr Inspiration, wie du GitHub-Repos mit Claude triagierst, findest du im Claude-Code-Connector-Tutorial.