Claude Code First PR Review Rubric: echte Risiken vor Stilfeedback finden

Ohne Rubrik kann Claude Code eine Produktionsregression und einen Namenshinweis gleich gewichten. Das wirkt produktiv, hilft aber nicht bei der Merge-Entscheidung.

Dieser Leitfaden baut eine erste PR-Review-Rubrik. Definieren Sie P0 bis P3, Nachweise, Kommentarformat und Retry-Regeln, bevor Claude Code den Diff liest.

Weiterlesen: claude-code-code-review-checklist, claude-code-prompt-library-maintenance, claude-code-pull-request-quality. Offizielle Dokumentationsbasis: Anthropic Claude Code docs.

Warum das vor dem ersten Befehl feststeht

Regressionen, Permission-Risiken, Datenverlust und fehlende Tests vor Stilfragen finden

Der wichtigste Schritt ist, die erste Anfrage klein zu halten. Legen Sie Lesebereich, geschützte Zonen, erste Aktion und Prüfbefehl fest, bevor Claude Code editiert.

Entwickler, die Claude Code für Reviews nutzen und schärfere Findings brauchen

Praktischer Ablauf

1. Ziel und geänderte Dateien vor dem Diff einfügen
2. P0 bis P3 vor der Review definieren
3. Spekulative Kommentare ohne Nachweis verbieten
4. Test-, Build- oder Repro-Nachweis verlangen
5. P3-Stilnotizen am Ende sammeln

Situation	Was Claude Code macht	Nachweis für die Prüfung
Auth-PR	Token-Speicherung und Permission-Grenzen zuerst als P0 prüfen	build, diff, URL
UI-Fix	Kaputte Klicks und Mobile-Layout als P1 prüfen	build, diff, URL
Refactor	Verhaltensnachweis und fehlende Tests als P2 trennen	build, diff, URL

Mit diesem Nachweis wird Claude Code nach sichtbarer Arbeit bewertet, nicht nach einer selbstsicheren Abschlussnotiz.

Prompt und Code zum Kopieren

Reviewe diesen PR-Diff mit P0/P1/P2/P3. P0 bedeutet Sicherheit, Datenverlust, Payment, Auth oder Produktionsausfall. Jeder Befund enthält Zeile, Fehlerszenario, nötigen Nachweis und Fix. Stilfeedback zuletzt sammeln.

const reviewRubric = {
  P0: "security, data loss, payment, auth, production outage",
  P1: "user-visible regression or broken release path",
  P2: "test gap, unclear edge case, maintainability risk",
  P3: "style, naming, or optional cleanup"
};

function classifyReviewFinding(finding) {
  const text = finding.toLowerCase();
  if (/auth|token|payment|delete|secret|production/.test(text)) return "P0";
  if (/regression|broken|crash|deploy/.test(text)) return "P1";
  if (/missing test|edge case|unclear/.test(text)) return "P2";
  return "P3";
}

console.log(classifyReviewFinding("missing test for failed payment retry"));

Praxisbeispiele und Fehler

Situation	Was Claude Code macht	Nachweis für die Prüfung
Auth-PR	Token-Speicherung und Permission-Grenzen zuerst als P0 prüfen	build, diff, URL
UI-Fix	Kaputte Klicks und Mobile-Layout als P1 prüfen	build, diff, URL
Refactor	Verhaltensnachweis und fehlende Tests als P2 trennen	build, diff, URL

• Wenn Naming und Format zuerst kommen, füllt Claude Code die Review mit Niedrigrisiko-Notizen.
• Ohne Severity stehen Payment-Bug und Satzzeichen nebeneinander.
• Ohne Nachweisforderung wachsen plausible, aber ungeprüfte Kommentare.

Der wichtigste Schritt ist, die erste Anfrage klein zu halten. Legen Sie Lesebereich, geschützte Zonen, erste Aktion und Prüfbefehl fest, bevor Claude Code editiert.

Was in das Proof Pack gehört

Regressionen, Permission-Risiken, Datenverlust und fehlende Tests vor Stilfragen finden wird wertvoller, wenn es als Proof Pack erhalten bleibt und nicht als einzelner Chat verschwindet. Speichern Sie die ursprüngliche Anfrage, gelesene Dateien, nicht berührte Bereiche, ausgeführte Befehle, öffentliche URL oder Screenshot und die noch unsichere Entscheidung. Die nächste Sitzung kann dieselbe Einschätzung nutzen, statt den Kontext neu zu finden.

Für Entwickler, die Claude Code für Reviews nutzen und schärfere Findings brauchen geht es nicht darum, am ersten Tag ein schweres Betriebshandbuch zu schreiben. Testen Sie das Muster an einem PR, einer Notiz oder einem Deploy. Wenn es scheitert, kommt der Fehler zurück in die Checklist und die kleinere Version wird erneut versucht. Erweitern Sie Claude-Code-Zugriff erst, wenn Build, Diff, URL, CTA und Rollback sichtbar sind. Permissions vor Proof zu öffnen wirkt schneller, verschiebt aber die Prüfung in die nächste menschliche Review.

Der Umsatzpfad folgt derselben Regel. Wer noch an Grundbefehlen hängt, braucht das kostenlose PDF. Wer jede Woche dieselbe Prompt-Form wiederholt, profitiert von Gumroad. Wer Team- oder Produktionsentscheidungen trifft, passt besser zur Beratung. Dieser Artikel soll nicht alle zum Kauf drängen, sondern nur Leser mit Bedarf an PR-Review-Prompts und wiederholbare Rubriken zum Paid Guide führen und alle anderen zu PDF oder passenden Artikeln zurückschicken.

Zum kostenlosen PDF, Gumroad und Beratung führen

Wenn die Grundbefehle noch unsicher sind, starten Sie mit dem kostenlosen Cheatsheet. Für mehr Tiefe zu PR-Review-Prompts und wiederholbare Rubriken nutzen Sie den Gumroad-Leitfaden. Bei Team-Rollout, Review-Regeln oder Umsatzpfad-Design geht es zur Beratung. Produktvergleich beginnt bei products.

Ein CTA gehört nicht nur ans Ende. Am Anfang senkt ein kostenloses PDF die Hürde. Nach dem Praxisbeispiel passt Gumroad. Bei Team-Rollout oder Produktionsrisiko ist Beratung der natürliche nächste Schritt.

Zahlen nach der Veröffentlichung

Nach Veröffentlichung Klicks zu Prompt Templates, dem künftigen Code Review System und Beratung beobachten.

Bewerten Sie nicht nur PV. Trennen Sie Anfangsleser, interne Klicks, kostenlose PDF-Starts, Gumroad-Klicks und Beratungsbesuche. HTTP 200, h1, canonical, heroImage, CTA und lokaler Text müssen auf denselben slug zeigen.