requesting-code-review

Überblick

Was diese Skill macht

Die requesting-code-review Skill definiert einen klaren, wiederholbaren Workflow, mit dem Sie einen AI-Code-Review-Subagenten Ihre Änderungen prüfen lassen, bevor sie eingecheckt werden. Sie ist für Git-basierte Projekte konzipiert und hilft Ihnen:

• Zu entscheiden, wann Sie ein Review anstoßen (nach Aufgaben, Features und vor dem Merge)
• Präzisen Kontext für den Reviewer mit Git-SHAs und Anforderungen zu paketieren
• Den Reviewer auf den Code-Diff zu fokussieren, nicht auf Ihren privaten Sitzungsverlauf
• Feedback nach Schweregrad zu klassifizieren, damit Sie wissen, was jetzt vs. später zu beheben ist

Im Kern geht es bei requesting-code-review um früh und häufig reviewen, damit Probleme erkannt werden, bevor sie sich durch den Codebestand fortpflanzen.

Für wen sie gedacht ist

Diese Skill passt gut, wenn Sie:

• Mit Git arbeiten und regelmäßig Feature-Branches oder PRs erstellen
• Eine strukturierte, wiederholbare Art suchen, AI-unterstützte Code-Reviews anzufordern
• Subagent-driven Development nutzen (z. B. einen dedizierten code-reviewer Agent)
• Wert auf Produktionsreife legen: Korrektheit, Architektur, Tests und Anforderungsabdeckung

Besonders nützlich ist sie für:

• Einzelentwickler, die ein verlässliches Sicherheitsnetz möchten
• Kleine Teams ohne dedizierte Code-Reviewer
• Projekte, in denen Commit-Historie und Diffs die zentrale Quelle der Wahrheit sind

Wann sie nicht gut passt

requesting-code-review ist möglicherweise nicht ideal, wenn:

• Sie kein Git verwenden oder keinen Zugriff auf Commit-SHAs haben
• Sie allgemeine Codegenerierung oder Refactoring-Hilfe möchten, nicht das Review konkreter Änderungen
• Sie keinen klaren Plan, keine Spezifikation oder Anforderungen zu den zu reviewenden Änderungen bereitstellen können

In diesen Fällen ist eventuell eine allgemeinere Coding- oder Planungs-Skill sinnvoller als ein reviewzentrierter Workflow.

Probleme, die sie löst

Ohne konsistenten Review-Prozess passiert es Entwicklern oft, dass sie:

• Vergessen, an wichtigen Meilensteinen ein Review anzufordern
• Zu wenig Kontext teilen (oder viel zu viel Sitzungsverlauf)
• Feedback erhalten, das unstrukturiert und schwer umsetzbar ist

Die requesting-code-review Skill löst diese Probleme, indem sie:

• Verpflichtende und optionale Review-Checkpoints definiert
• Die Inputs für das Review standardisiert (Git-Range, Anforderungen, Zusammenfassung)
• Mit einem dedizierten code-reviewer Subagenten kombiniert wird, der nach Schweregrad sortiertes Feedback zurückgibt

Verwendung

Installation

Um die requesting-code-review Skill aus dem obra/superpowers Repository zu installieren, verwenden Sie die Skills CLI:

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

Damit werden die Skill-Definition sowie die zugehörigen Dateien geladen, einschließlich der `code-reviewer` Subagent-Vorlage.

Nach der Installation öffnen Sie das Skill-Verzeichnis und schauen sich zuerst diese Dateien an:

- `SKILL.md` – überblicksartige Beschreibung und Workflow-Schritte für Code-Reviews
- `code-reviewer.md` – der Agent-Prompt/die Vorlage, die das eigentliche Code-Review durchführt

### Kern-Workflow auf einen Blick
Der `requesting-code-review` Workflow besteht aus drei Hauptphasen:

1. **Entscheiden, wann reviewed wird**
   - Nach jeder Aufgabe in einem subagent-gesteuerten Workflow
   - Nachdem Sie ein größeres Feature fertiggestellt haben
   - Vor dem Merge in Ihren Hauptbranch
2. **Review-Kontext vorbereiten**
   - Den Git-Commit-Range mit `BASE_SHA` und `HEAD_SHA` erfassen
   - Zusammenfassen, was implementiert wurde und was es leisten soll
   - Die Platzhalter in `code-reviewer.md` ausfüllen
3. **Review ausführen und auf Feedback reagieren**
   - Den `superpowers:code-reviewer` Subagenten starten
   - Kritische Issues sofort beheben, wichtige vor dem Weitermachen, und kleinere Issues protokollieren

### Schritt 1: Den richtigen Review-Zeitpunkt wählen
Laut `SKILL.md` verwenden Sie `requesting-code-review`:

**Verpflichtende Checkpoints:**

- **Nach jeder Aufgabe** in subagent-driven Development
- **Nach Abschluss eines größeren Features**
- **Vor dem Merge** in Ihren Hauptbranch (z. B. `main`, `master`)

**Optionale, aber wertvolle Checkpoints:**

- Wenn Sie **feststecken** und einen frischen Blick benötigen
- **Vor einem Refactoring**, als Baseline-Check des aktuellen Verhaltens
- Nach der Behebung eines **komplexen Bugs**, um sicherzustellen, dass keine Regressionen oder neuen Probleme entstanden sind

Machen Sie es sich zur Gewohnheit, diese Skill an diesen Punkten auszulösen, damit Reviews automatisch stattfinden und nicht zur Nebensache werden.

### Schritt 2: Git-Commit-Range erfassen
Der Reviewer braucht einen sauberen, klar abgegrenzten Diff. Verwenden Sie Git-SHAs, um den Range anzugeben:

```bash
BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)

• BASE_SHA sollte auf den Commit zeigen, der Ihren Ausgangspunkt repräsentiert, etwa den vorherigen Commit oder die Spitze von origin/main.
• HEAD_SHA sollte der Commit sein, der Ihre aktuellsten Arbeiten enthält.

Sie können HEAD~1 anpassen oder eine andere Basis wählen, passend zu Ihrer Branch-Strategie – wichtig ist, dass der Range genau die Änderungen umfasst, die Sie reviewen lassen möchten.

Schritt 3: Review-Request-Vorlage vorbereiten

Die Datei code-reviewer.md definiert, wie Sie mit dem Code Review Agent kommunizieren. Sie enthält Platzhalter, die Sie ausfüllen müssen, bevor Sie den Subagenten starten.

Wichtige Platzhalter:

• {WHAT_WAS_IMPLEMENTED} – Eine prägnante Beschreibung dessen, was Sie gerade gebaut oder geändert haben
• {PLAN_OR_REQUIREMENTS} – Spezifikation, Ticket oder Business-Anforderungen, die die Implementierung erfüllen soll
• {BASE_SHA} – Der Start-Commit-SHA für den Diff
• {HEAD_SHA} – Der End-Commit-SHA für den Diff
• {DESCRIPTION} – Eine kurze Zusammenfassung des Change-Sets (z. B. "Add verification function and tests for user signups")
• {PLAN_REFERENCE} – Ein Verweis auf Ihren Plan oder das Anforderungsdokument

In Ihrem eigenen Tooling füllen Sie diese Platzhalter aus, bevor Sie den superpowers:code-reviewer Subagenten mit dem Task-Tool dispatchen.

Schritt 4: Den code-reviewer Subagent dispatchen

Wenn Git-SHAs und Vorlage ausgefüllt sind:

1. Nutzen Sie das Task Tool Ihrer Orchestrierungsumgebung (wie im superpowers Framework beschrieben) mit dem Typ superpowers:code-reviewer.

2. Übergeben Sie den gerenderten Inhalt von code-reviewer.md, in dem alle Platzhalter durch echte Werte ersetzt wurden.

3. Stellen Sie sicher, dass der Agent auf den Git-Diff für den Range zugreifen kann:

   git diff --stat {BASE_SHA}..{HEAD_SHA}
   git diff {BASE_SHA}..{HEAD_SHA}
   

   Die Vorlage weist auf diese Kommandos hin, damit der Reviewer sich strikt auf die Änderungen zwischen BASE_SHA und HEAD_SHA konzentriert.

Das Design dieser Skill stellt sicher, dass der Review-Agent nur das Arbeitsergebnis sieht (Commits und Diff), nicht Ihren gesamten Sitzungsverlauf oder irrelevanten Kontext.

Schritt 5: Feedback interpretieren und umsetzen

Die code-reviewer.md Vorlage weist den Agenten an, Folgendes zu prüfen:

• Codequalität (Separation of Concerns, Fehlerbehandlung, DRY, Edge Cases)
• Architektur (Design, Skalierbarkeit, Performance, Sicherheit)
• Tests (Abdeckung, Integrationspunkte, Testqualität)
• Anforderungen (Abgleich mit der Spezifikation, kein Scope Creep, dokumentierte Breaking Changes)
• Produktionsreife (Migrationen, Rückwärtskompatibilität, Dokumentation)

Feedback wird kategorisiert in:

• Critical (Must Fix) – Bugs, Sicherheitsprobleme, Risiko von Datenverlust, defekte Funktionalität
• Important (Should Fix) – Architekturprobleme, fehlende Features, schlechte Fehlerbehandlung, Testlücken
• Minor (Nice to Have) – Stil, Optimierungen, Verbesserungen der Dokumentation

Der zugehörige Workflow aus SKILL.md lautet:

• Critical Issues sofort beheben, bevor Sie weitermachen
• Important Issues beheben, bevor Sie weitere Arbeit anschließen oder mergen
• Minor Issues für späteres Cleanup oder Folgetickets notieren
• Widersprechen Sie begründet, wenn der Reviewer falsch liegt oder Kontext fehlt

Mit dieser Triage wird aus AI-Feedback eine konkrete To-do-Liste statt einer vagen Sammlung von Vorschlägen.

Beispiel für ein Nutzungsmuster

Ein typischer Einsatz von requesting-code-review könnte so aussehen:

1. Sie schließen "Task 2: Add verification function" in Ihrem Feature-Branch ab.

2. Sie erfassen die SHAs:

   BASE_SHA=$(git rev-parse origin/main)
   HEAD_SHA=$(git rev-parse HEAD)
   

3. Sie füllen die Platzhalter in code-reviewer.md mit:

   • {WHAT_WAS_IMPLEMENTED} = "Verification function for user email flow"
   • {PLAN_OR_REQUIREMENTS} = Link oder Zusammenfassung des Tickets/der Anforderungen
   • {BASE_SHA} und {HEAD_SHA} = Die Werte aus Git
   • {DESCRIPTION} = "Implement email verification and add tests for edge cases"

4. Sie dispatchen den superpowers:code-reviewer Subagenten über Ihr Task Tool.

5. Sie erhalten strukturiertes Feedback, gruppiert in Critical, Important und Minor.

6. Sie beheben Critical und Important Issues und führen den Prozess optional erneut aus, bevor Sie mergen.

FAQ

Ist requesting-code-review nur für GitHub-Repositories?

Nein. Die requesting-code-review Skill ist Git-basiert, nicht GitHub-spezifisch. Sie stützt sich auf Commit-SHAs und git diff Kommandos und funktioniert daher mit jedem Git-Remote (GitHub, GitLab, Bitbucket oder Self-Hosted), solange Sie BASE_SHA und HEAD_SHA bereitstellen können.

Muss ich meinen gesamten Entwicklungssitzungsverlauf teilen?

Nein. Ein zentrales Designprinzip von requesting-code-review ist, dass der Reviewer nur eng gefassten Kontext erhält: was implementiert wurde, die Anforderungen und den Git-Diff. Ihr allgemeiner Sitzungsverlauf und Ihre Gedanken bleiben privat, während sich der Reviewer auf die tatsächlichen Codeänderungen konzentriert.

Wann sollte ich requesting-code-review in meinem Workflow auslösen?

Verwenden Sie requesting-code-review:

• Nach jeder Aufgabe in subagent-driven Development
• Nach Abschluss eines größeren Features
• Vor dem Merge in Ihren Hauptbranch

Zusätzlich können Sie die Skill auslösen, wenn Sie feststecken, vor größeren Refactorings oder nach komplexen Bugfixes, um versteckte Risiken früh zu erkennen.

Wie fügt sich das in meine bestehenden Pull-Request-Reviews ein?

requesting-code-review ergänzt menschliche PR-Reviews, statt sie zu ersetzen. Sie können:

• Die Skill vor dem Öffnen eines PR ausführen, um offensichtliche Probleme abzufangen
• Sie parallel zu menschlichen Reviewern verwenden, um Abdeckung und Konsistenz zu verbessern
• Die strukturierten Feedback-Kategorien (Critical/Important/Minor) auf Ihre PR-Kommentare übertragen

Da die Skill auf Git-Ranges basiert, fügt sie sich nahtlos in PR-basierte Workflows ein.

Kann ich das Verhalten des code-reviewer Agent anpassen?

Ja. Die Datei code-reviewer.md ist eine Vorlage, die Sie anpassen können:

• Checklisten für Codequalität, Architektur, Tests oder Sicherheit justieren
• Projektspezifische Aspekte ergänzen (z. B. Domänenregeln, Performance-Budgets)
• Das Ausgabeformat verfeinern, wenn Sie andere Schweregrade oder zusätzliche Sektionen möchten

Behalten Sie lediglich die Kernstruktur bei (klarer Auftrag, Git-Range und Schweregrad-Kategorien), damit das Review fokussiert und umsetzbar bleibt.

Was, wenn der Reviewer etwas Falsches vorschlägt?

Die Skill fordert explizit dazu auf, mit Begründung zu widersprechen, wenn der Reviewer falsch liegt oder Kontext fehlt. Behandeln Sie das Review als starke Empfehlung, nicht als unanfechtbares Urteil. Erläutern Sie Randbedingungen, erklären Sie Trade-offs oder aktualisieren Sie Ihren Plan, damit künftige Reviews besser ausgerichtet sind.

Generiert requesting-code-review Tests oder Codeänderungen für mich?

Nein. Diese Skill dreht sich um Review, nicht um Generierung. Sie hilft Ihnen dabei:

• Gezielte Reviews für konkrete Änderungen anzufordern
• Strukturiertes Feedback zu Qualität, Architektur und Tests zu erhalten

Für die Umsetzung der Fixes und das Schreiben von Tests sind weiterhin Sie verantwortlich – Sie können diese Skill aber mit anderen Coding- oder Testgenerierungs-Skills in Ihrer Toolchain kombinieren.

Wie steige ich schnell ein?

1. Installieren Sie die Skill:

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

2. Lesen Sie SKILL.md, um die Review-Checkpoints zu verstehen.

3. Schauen Sie code-reviewer.md durch, um die Checkliste und das Ausgabeformat des Agenten zu sehen.

4. Führen Sie Ihre nächste Aufgabe oder Ihr nächstes Feature aus, erfassen Sie BASE_SHA und HEAD_SHA, und dispatchen Sie den superpowers:code-reviewer Subagenten.

Anschließend können Sie Vorlage und Workflow schrittweise anpassen, bis requesting-code-review optimal zu den Gewohnheiten und Qualitätsstandards Ihres Teams passt.