requesting-code-review

Überblick über die requesting-code-review-Skill

Die Skill requesting-code-review ist ein leichtgewichtiges Workflow-Muster, um zum richtigen Zeitpunkt, mit dem richtigen Diff und mit genug Implementierungskontext eine gezielte Code-Review anzustoßen, damit ein Reviewer-Agent wirklich brauchbares Feedback geben kann. Statt nur vage „please review my code“ zu schreiben, zwingt sie dazu, einen Commit-Bereich, eine Zusammenfassung der Änderungen und die beabsichtigten Anforderungen mitzugeben.

Was die requesting-code-review-Skill tatsächlich macht

Im Kern weist requesting-code-review dich an, den Subagenten superpowers:code-reviewer mit einer vorbereiteten Vorlage in code-reviewer.md aufzurufen. Der eigentliche Mehrwert ist nicht ausgefallene Automatisierung, sondern das Framing der Review. Der Reviewer sieht das Arbeitsergebnis und den Plan — nicht deine komplette Session-Historie. Dadurch bleibt die Review enger fokussiert und die Ergebnisse lassen sich leichter umsetzen.

Für wen sich requesting-code-review lohnt

Diese Skill passt am besten für Entwickler und AI-Agent-Nutzer, die:

• in commit-basierten Workflows arbeiten
• Features schrittweise ausliefern
• einen wiederholbaren Checkpoint „Review vor dem Weiterarbeiten“ wollen
• mit Subagenten arbeiten und eine sauberere Übergabe brauchen als mit einem generischen Prompt

Besonders nützlich ist sie, wenn du Reviews oft zu spät anfragst — nämlich erst dann, wenn sich schon mehrere Aufgaben zu einem großen Diff aufgestaut haben.

Der eigentliche Job-to-be-done

Nutzer installieren requesting-code-review nicht einfach nur, um „eine Review zu bekommen“. Sie installieren die Skill, um vermeidbare Nacharbeit zu reduzieren:

• Probleme vor dem Merge erkennen
• gegen den ursprünglichen Plan validieren
• nach Schweregrad priorisiertes Feedback erhalten
• den Kontext der Hauptaufgabe erhalten, während ein Reviewer-Agent den Code separat prüft

Warum diese Skill nützlicher ist als ein normaler Review-Prompt

Die requesting-code-review-Skill bringt praktische Struktur mit, die in vielen ad hoc formulierten Prompts fehlt:

• Timing-Hinweise für Reviews: nach jeder Aufgabe, nach größeren Features, vor dem Merge
• explizite Eingaben für BASE_SHA und HEAD_SHA
• eine Review-Vorlage mit Checks für Codequalität, Architektur, Tests, Anforderungen und Production Readiness
• Severity-Kategorien, die Nacharbeit einfacher machen

Dadurch wird das Ergebnis deutlich umsetzbarer als bei „scan my latest changes“.

Worauf es vor der Einführung am meisten ankommt

Die wichtigste Frage bei der Einführung ist der Fit: Diese Skill funktioniert am besten, wenn deine Arbeit als sauberer git-Bereich abbildbar ist und du das gewünschte Verhalten kurz beschreiben kannst. Wenn dein Branch chaotisch ist, der Plan unklar bleibt oder deine Änderungen mit unzusammenhängenden Edits vermischt sind, sinkt die Qualität der Review deutlich.

Wichtige Einschränkung, die du vorher kennen solltest

requesting-code-review for Code Review ist für sich genommen kein vollständiges Review-System. Es enthält keine Scripts, keine Enforcement-Regeln und keine repository-spezifischen Checker. Es ist ein diszipliniertes Muster für Prompting und Übergabe. Das ist wertvoll — aber die Qualität hängt stark vom Commit-Bereich und von der Klarheit deiner Anforderungen ab.

So verwendest du die requesting-code-review-Skill

requesting-code-review in deinem Skills-Setup installieren

Wenn du das im Repository genutzte Skills-CLI-Muster verwendest, installierst du die Skill so:

npx skills add https://github.com/obra/superpowers --skill requesting-code-review

Wenn deine Umgebung die Sammlung obra/superpowers bereits verfügbar hat, musst du die requesting-code-review-Skill aus diesem Pack nur aktivieren oder referenzieren.

Diese Dateien solltest du zuerst lesen

Für eine schnelle Bewertung starte mit:

1. skills/requesting-code-review/SKILL.md
2. skills/requesting-code-review/code-reviewer.md

SKILL.md erklärt, wann du eine Review auslösen solltest. code-reviewer.md ist die wichtigere Datei, wenn dir die Ausgabequalität wichtig ist, weil dort exakt steht, was der Reviewer prüfen soll.

Die vorgesehenen Trigger-Zeitpunkte verstehen

Die Skill ist dafür gedacht, verwendet zu werden:

• nach jeder Aufgabe in einer subagent-gesteuerten Entwicklung
• nach einem größeren Feature
• vor dem Merge nach main

Optionale, aber besonders wertvolle Zeitpunkte sind:

• wenn du festhängst und einen frischen Blick brauchst
• vor einem riskanten Refactor
• nach dem Beheben eines komplexen Bugs

Wenn du sie nur ganz am Ende eines großen Branches nutzt, verschenkst du einen Großteil des Nutzens.

Vor dem Aufruf die minimal nötigen Inputs sammeln

Die Skill funktioniert am besten, wenn du Folgendes mitlieferst:

• was implementiert wurde
• den Plan oder die Anforderungen
• BASE_SHA
• HEAD_SHA
• eine kurze Beschreibung der Änderung

Typische git-Kommandos:

BASE_SHA=$(git rev-parse HEAD~1)
HEAD_SHA=$(git rev-parse HEAD)

Bei Feature-Branches kann origin/main die bessere Basis sein als HEAD~1, wenn du ein umfassenderes Review-Fenster willst.

Einen sauberen Diff-Bereich verwenden statt einer vagen Anfrage nach „latest work“

Das ist der Teil mit dem größten Hebel im requesting-code-review usage-Muster. Eine Review, die an BASE_SHA..HEAD_SHA gebunden ist, ist deutlich besser, als einen Agenten aus dem Working Tree oder aus der Chat-Historie erraten zu lassen, was sich geändert hat.

Gut:

• „Review commits from feature start to current head against the signup flow requirements.“

Schwach:

• „Can you review my recent auth changes?“

Die stärkere Variante begrenzt den Scope und reduziert das Rätselraten des Reviewers.

Aus einem groben Ziel eine starke Review-Anfrage machen

Eine grobe Anfrage wie diese ist zu dünn:

Please review my new feature.

Eine stärkere Anfrage auf Basis der Skill sieht so aus:

Review the password reset implementation for production readiness.

What was implemented:
- Added reset token generation and validation
- Added reset email endpoint
- Added UI flow for requesting and completing reset

Plan/requirements:
- Tokens expire after 30 minutes
- Single-use tokens only
- No user enumeration from the request endpoint
- Existing login flow must remain unchanged

Base SHA: abc1234
Head SHA: def5678
Description:
Task 2 of auth hardening. Main changes are in API handlers, email service, and reset form.

So bekommt der Reviewer genug Kontext, um Korrektheit zu bewerten — nicht nur Stilfragen.

Den Reviewer-Subagenten so aufrufen, wie die Skill es erwartet

Die Repository-Anleitung sagt, dass du das Task-Tool mit dem Typ superpowers:code-reviewer verwenden und die Vorlage in code-reviewer.md ausfüllen sollst. Diese Vorlage fordert den Reviewer dazu auf:

• Implementierung und Plan zu vergleichen
• den git-Diff zu prüfen
• Qualität, Architektur, Tests und Production Readiness zu checken
• Findings nach Schweregrad zurückzugeben

Wenn deine Agent-Plattform Subagenten unterstützt, halte die Review isoliert, statt sie in dieselbe Arbeitskonversation zu mischen.

Was die Reviewer-Vorlage in requesting-code-review besonders gut findet

Die eingebaute Checkliste ist besonders stark darin, Folgendes sichtbar zu machen:

• fehlende Anforderungen
• offensichtliche Lücken bei der Production Readiness
• Probleme bei der Testabdeckung
• Architekturthemen
• gefährliche Edge Cases
• ausgelassene Aspekte bei Backward Compatibility oder Migrationen

Weniger spezialisiert ist sie auf domänenspezifische Compliance, repository-spezifische Konventionen oder tiefgehende Laufzeitverifikation — es sei denn, du ergänzt das explizit.

Empfohlener Workflow für reale Projekte

Ein praxistauglicher requesting-code-review guide sieht so aus:

1. eine klar abgegrenzte Aufgabe abschließen
2. den exakten Diff-Bereich bestimmen
3. Absicht und Acceptance Criteria zusammenfassen
4. den Reviewer mit der Vorlage starten
5. kritische und wichtige Probleme beheben
6. die Review erneut ausführen, wenn die Fixes substanziell sind
7. mit der Entwicklung weitermachen oder mergen

Diese Skill ist am effektivsten als Checkpoint zwischen Implementierungsschritten — nicht nur als letzte Hürde vor dem Merge.

Tipps, die die Ausgabequalität spürbar verbessern

Für bessere Review-Ergebnisse:

• einen Diff-Bereich verwenden, der genau eine logische Änderung enthält
• Acceptance Criteria angeben, nicht nur einen Feature-Namen
• riskante Bereiche wie Migrationen, Auth, Concurrency, Caching oder API Contracts nennen
• erwähnen, ob Tests hinzugefügt wurden und welche Typen davon
• sagen, ob Breaking Changes erwartet oder ausgeschlossen sind

Diese Details helfen dem Reviewer, beabsichtigte Trade-offs von versehentlichen Auslassungen zu unterscheiden.

Häufige Fehlanwendung, die den Nutzen senkt

Die Entscheidung für requesting-code-review install ergibt weniger Sinn, wenn dein Team regelmäßig:

• viele unzusammenhängende Änderungen in einen Bereich packt
• keine schriftlichen Anforderungen hat
• keine sinnvollen git-Grenzen nutzt
• erwartet, dass die Skill menschliche Freigabe oder CI ersetzt

In solchen Fällen solltest du zuerst den Workflow aufräumen — oder mit noisigeren Reviews rechnen.

FAQ zur requesting-code-review-Skill

Ist requesting-code-review gut für Einsteiger?

Ja, sofern du grundlegende git-Konzepte wie Commits und SHAs bereits verstehst. Die Skill ist einfach, setzt aber voraus, dass du definieren kannst, was sich geändert hat und was es tun sollte. Wenn Einsteiger diesen Kontext weglassen, bekommen sie zwar trotzdem Feedback — nur eben weniger verlässlich.

Bewertet diese Skill uncommitted changes?

Nicht im eigentlichen Design. Der Workflow basiert auf BASE_SHA und HEAD_SHA und ist deshalb bei committeter Arbeit am stärksten. Du kannst ihn zwar für unstaged oder uncommitted changes anpassen, entfernst dich damit aber von der Kernstruktur der Skill — und machst die Review meist weniger reproduzierbar.

Worin unterscheidet sich requesting-code-review davon, eine AI einfach um Code-Review zu bitten?

Ein normaler Prompt erzeugt oft eine generische Review, weil das Modell Scope, Absicht und Acceptance Criteria selbst erschließen muss. requesting-code-review verbessert das, indem es Folgendes verlangt:

• ein explizites Diff
• eine klare Implementierungszusammenfassung
• den ursprünglichen Plan oder die Anforderungen
• ein ausgabeformat nach Schweregrad

Das Ergebnis ist in der Regel leichter zu vertrauen und leichter umzusetzen.

Wann sollte ich requesting-code-review nicht verwenden?

Lass es weg, wenn:

• deine Änderung noch zu unvollständig ist, um sie sinnvoll zu bewerten
• das Diff mehrere unzusammenhängende Features mischt
• du das erwartete Verhalten selbst noch nicht kennst
• du repository-spezifische Static Checks mehr brauchst als urteilsbasierte Review

Schlecht passt die Skill auch, wenn dein Team grundsätzlich nicht mit git-Commit-Bereichen arbeitet.

Ersetzt sie menschliche Code-Reviews?

Nein. Am sinnvollsten ist sie als Pre-Review oder als Qualitäts-Gate zwischen zwei Schritten. Sie kann Probleme früh aufdecken und spätere menschliche Reviews glatter machen, ersetzt aber weder Domänenwissen noch Teamkonventionen oder organisatorische Freigabeprozesse.

Ist requesting-code-review nur für große Features gedacht?

Nein. Tatsächlich spielt die Skill ihre Stärken gerade bei kleineren Diffs aus. Sie fördert ausdrücklich frühe und häufige Reviews — und das ist oft wirksamer, als auf einen einzigen großen Enddurchlauf zu warten.

Welchen Ecosystem-Fit sollte ich erwarten?

Diese Skill passt am besten in den obra/superpowers-Workflow, besonders wenn du ohnehin mit Subagenten arbeitest. Sie ist schlanker als ein vollständiges Review-Framework und leichter einzuführen als eigene Review-Automatisierung — das bedeutet allerdings auch weniger Guardrails.

So verbesserst du die requesting-code-review-Skill

Dem Reviewer bessere Anforderungen geben, nicht nur besseren Code

Der häufigste Fehler ist schwacher Plankontext. Wenn du nur sagst „implemented notifications“, kann der Reviewer nicht erkennen, ob ein fehlender Retry-Pfad ein Bug oder bewusst out of scope ist. Füge konkrete Erwartungen hinzu:

• Trigger-Bedingungen
• Fehlerverhalten
• Erwartungen an Backward Compatibility
• Performance- oder Sicherheitsanforderungen

Bessere Anforderungen führen zu besseren Review-Urteilen.

Den kleinsten sinnvollen Review-Slice wählen

Die requesting-code-review-Skill funktioniert am besten für eine einzelne Aufgabe oder ein eng zusammenhängendes Änderungspaket. Wenn das Diff Schema-Arbeit, API-Änderungen, UI-Updates und zusätzliches Cleanup enthält, werden Findings breiter und weniger umsetzbar. Teile die Arbeit wenn möglich in reviewbare Einheiten auf.

Den richtigen Base-Commit wählen

Ein schlechter BASE_SHA führt zu irreführendem Feedback. Wenn du HEAD~1 verwendest, das Feature aber über sechs Commits läuft, sieht der Reviewer zu wenig. Wenn du einen sehr alten Base-Commit nimmst, sieht der Reviewer zu viel Rauschen. Wähle die Basis, die genau zu der logischen Arbeitseinheit passt, die beurteilt werden soll.

Platzhalter durch konkrete Angaben ersetzen, die der Reviewer gedanklich testen kann

Die mitgelieferte Vorlage nutzt Platzhalter wie:

• {WHAT_WAS_IMPLEMENTED}
• {PLAN_OR_REQUIREMENTS}
• {BASE_SHA}
• {HEAD_SHA}
• {DESCRIPTION}

Fülle diese bei riskanten Änderungen nicht mit Einzeilern. Beschreibe das tatsächlich erwartete Verhalten. Zum Beispiel ist „prevents user enumeration and invalidates token after first successful reset“ deutlich stärker als „added password reset.“

Dem Reviewer sagen, wo das Risiko liegt

Wenn du die riskanten Stellen kennst, sag es explizit:

• „Please pay special attention to race conditions around token reuse.“
• „Check backward compatibility for existing API consumers.“
• „Focus on whether tests cover the error path and expiry boundary.“

So lenkst du die Aufmerksamkeit gezielt und erhöhst die Chance auf wirklich nützliche Findings.

Die Review nach dem ersten Durchlauf verstärken

Nach der ersten Ausgabe:

1. die klar korrekten kritischen Probleme beheben
2. Findings hinterfragen, die falsch wirken
3. unklare Anforderungen präzisieren
4. bei substanziellen Änderungen eine zweite Review auf dem aktualisierten Diff ausführen

Die Skill selbst ermutigt dazu, dem Reviewer zu widersprechen, wenn er falsch liegt. Das ist ein gutes Zeichen: Sie soll Urteilsvermögen unterstützen, nicht ersetzen.

Bei Bedarf repository-spezifische Review-Kriterien ergänzen

Die Standarddatei code-reviewer.md deckt gängige Review-Dimensionen gut ab, aber viele Teams brauchen mehr. Verbessere requesting-code-review for Code Review, indem du projektspezifische Checks ergänzt, etwa:

• Regeln für das Ausrollen von Migrationen
• Anforderungen an Observability
• Erwartungen an Accessibility
• Security-Review-Punkte
• Sprach- oder Framework-Konventionen

Das ist das größte Upgrade, wenn du weniger generische Ausgaben willst.

Auf diese wiederkehrenden Failure Modes achten

Typische Qualitätsverluste kommen meist von:

• fehlenden oder vagen Anforderungen
• verrauschten Commit-Bereichen
• keiner Erwähnung des erwarteten nichtfunktionalen Verhaltens
• einer Review-Anfrage erst, nachdem sich zu viele Aufgaben angesammelt haben
• dem Behandeln kleiner Vorschläge als Pflicht, während kritische Designprobleme übersehen werden

Wenn die Ausgabe flach wirkt, prüfe zuerst die Inputs.

Die Ausgabe verbessern, indem du nach Entscheidungen fragst — nicht nur nach Defekten

Ein stärkeres requesting-code-review usage-Muster ist, den Reviewer auch Trade-offs bewerten zu lassen. Zum Beispiel:

• „Flag any unnecessary complexity.“
• „Call out if this should be split before merge.“
• „Assess whether current tests justify production readiness.“

So verschiebst du die Review weg von lint-artigen Kommentaren hin zu einer belastbaren Bewertung der Release-Qualität.

Praktischer Weg, die Skill im eigenen Setup weiterzuentwickeln

Wenn du diese Skill ernsthaft einführst, solltest du zuerst drei Dinge anpassen:

1. deine bevorzugte Regel zur Auswahl des Base-Commits
2. ein Standardformat für Anforderungen und Acceptance Criteria
3. zusätzliche Checklistenpunkte für deinen Stack und deinen Release-Prozess

Diese Ergänzungen erhalten die Einfachheit von requesting-code-review, machen die Skill im täglichen Delivery-Alltag aber deutlich nützlicher.