Claude · Foto: Lachlan Hardy, CC BY 2.0

SkillClaude SkillsLizenz: MITfrei kopierbar

requesting-code-review

Zuletzt aktualisiert: 13. September 2026

⬇ Als Datei laden

⧉ –× kopiert⬇ –× heruntergeladenBewertung:

Typ

Skill

Lizenz

MIT

Quelle

obra/superpowers ↗

Anwendungsfeld

Claude Skills

Entwickler, die jede größere Änderung vor dem Merge prüfen lassen.

Voraussetzungen

Ein Git-Repository, aus dem sich Start- und End-Commit (BASE_SHA, HEAD_SHA) der Änderung ermitteln lassen
Zugriff auf Subagenten in der genutzten Umgebung
Die Vorlage code-reviewer.md für den Reviewer-Prompt

Einordnung

Der Ablauf ist mit Git-SHAs und Vorlage schnell angestoßen, setzt aber ein funktionierendes Subagenten-Setup voraus.

Fordert vor dem Merge ein strukturiertes Code-Review an (inkl. Reviewer-Subagent-Prompt).

Für wen: Entwickler, die jede größere Änderung vor dem Merge prüfen lassen.

Im Detail

Der Skill beschreibt, wie ein Code-Reviewer-Subagent gezielt für ein Review angestoßen wird – mit präzise zusammengestelltem Kontext (u. a. Git-SHAs für Vorher/Nachher-Vergleich), aber ohne die volle Sitzungshistorie. Dadurch bleibt der Reviewer auf das tatsächliche Arbeitsergebnis fokussiert statt auf den Gedankengang, der dazu geführt hat, und der eigene Kontext bleibt für die Weiterarbeit erhalten. Empfohlen wird der Einsatz nach jeder Teilaufgabe in subagentengetriebener Entwicklung, nach größeren Features und vor jedem Merge in den Hauptzweig, optional auch bei Blockaden oder nach komplexen Bugfixes. Praktisch für Workflows mit mehreren Subagenten, die eigenständig Code produzieren.

Schritt für Schritt

Ermitteln Sie BASE_SHA und HEAD_SHA der zu prüfenden Änderung, bevor Sie das Review anstoßen.
Füllen Sie die Vorlage mit einer kurzen Beschreibung der Änderung und den zugrunde liegenden Anforderungen, damit der Reviewer nicht raten muss.
Lassen Sie den Reviewer-Subagenten unabhängig von Ihrer eigenen Session-Historie arbeiten, damit sich die Bewertung auf das Arbeitsergebnis stützt.
Beheben Sie kritische Befunde sofort und wichtige vor dem nächsten Schritt, kleinere können Sie vormerken.
Widersprechen Sie mit technischer Begründung, wenn ein Hinweis des Reviewers auf Ihren Fall nicht zutrifft.

Beispiel aus der Praxis

Nach Abschluss einer Aufgabe aus einem Umsetzungsplan ermitteln Sie BASE_SHA und HEAD_SHA der letzten Commits und lassen einen Reviewer-Subagenten die Änderung gegen die Planvorgaben prüfen. Der Subagent meldet eine fehlende Fehlerbehandlung als „Important“ zurück, die Sie vor dem nächsten Schritt beheben.

Praxis-Tipp

Rufen Sie ihn kurz vor einem Merge auf und geben Sie BASE_SHA an (z. B. git rev-parse HEAD~1 oder origin/main) statt der ganzen Konversation als Kontext.

Stolperfallen

Wird dem Reviewer die eigene Session-Historie statt nur präzise gefasster Angaben mitgegeben, verwässert das die unabhängige Bewertung. Bei sicherheitskritischem oder besonders komplexem Code ersetzt dieses automatisierte Review laut Beschreibung kein menschliches Review.

Siehe auch

Lizenz & Quelle

Lizenz: MIT
Quelle: obra/superpowers

Häufige Fragen.

Ersetzt dieses Review ein menschliches Code-Review?

Nein, laut Beschreibung nicht bei sicherheitskritischem oder besonders komplexem Code — dort bleibt ein menschliches Review nötig.

Muss ich für jede kleine Änderung ein Review anfordern?

Verpflichtend ist es nach jeder Aufgabe in der Subagenten-gesteuerten Entwicklung, nach größeren Features und vor dem Merge in den Hauptzweig; darüber hinaus ist es optional.

Was, wenn ich mit dem Reviewer-Feedback nicht einverstanden bin?

Sie können mit technischer Begründung widersprechen, statt den Vorschlag ungeprüft umzusetzen.

Inhalt ansehen (SKILL.md)

Lade …

Erfahrungen & Kommentare.

Funktioniert der Skill bei Ihnen? Tipps, Stolperfallen, Varianten — teilen Sie es mit der Community.

Lade Kommentare …