subagent-driven-development

Überblick

Was ist subagent-driven-development?

subagent-driven-development ist ein Orchestrierungs-Skill, mit dem Sie einen Implementierungsplan als Sequenz unabhängiger Aufgaben ausführen, die jeweils von einem frischen Subagent bearbeitet werden. Für jede Aufgabe gehen Sie so vor:

1. Einen dedizierten Implementer-Subagent starten.
2. Einen Spec-Compliance-Reviewer-Subagent ausführen.
3. Einen Code-Quality-Reviewer-Subagent ausführen.

Alle drei arbeiten in einem streng begrenzten Kontext, sodass sie sich ausschließlich auf die aktuelle Aufgabe konzentrieren, während Ihre Hauptsession für Koordination und Entscheidungen frei bleibt.

Für wen ist dieses Skill gedacht?

subagent-driven-development richtet sich an Entwickler:innen und Teams, die:

• AI-Coding-Assistenten (z. B. Claude / claude-code) nutzen und verlässlichere Ergebnisse möchten.
• Von einem schriftlichen Implementierungsplan mit klar abgegrenzten Aufgaben ausgehen.
• Einen strukturierten, reproduzierbaren Weg brauchen, um Code in einer einzigen AI-Session implementieren und reviewen zu lassen.
• Sowohl auf Spezifikationskorrektheit als auch auf Code-Qualität Wert legen – nicht nur auf „irgendetwas, das funktioniert“.

Besonders gut passt es in GitHub-zentrierte Workflows, in denen Sie SHAs, Plan-Dateien und Diffs an Subagents übergeben können.

Welche Probleme löst es?

Dieses Skill adressiert typische Probleme, wenn ein einzelner AI-Agent für End-to-End-Entwicklung genutzt wird:

• Context bloat: Ein Agent sammelt zu viel Historie an und verliert den Fokus.
• Spec drift: Implementierungen entfernen sich nach und nach vom ursprünglichen Plan oder den Anforderungen.
• Schwache Reviews: Derselbe Kontext, der den Code geschrieben hat, soll ihn auch reviewen – Fehler bleiben leicht unentdeckt.

subagent-driven-development erzwingt ein klares Muster: frischer Agent pro Aufgabe, strenger Kontext und ein zweistufiges Review (zuerst Spec, dann Qualität). Das erhöht die Korrektheit, hält Änderungen klar begrenzt und erleichtert es, jeden Schritt Ihres Implementierungsplans nachzuvollziehen.

Wann ist subagent-driven-development sinnvoll?

Nutzen Sie dieses Skill, wenn:

• Sie bereits einen Implementierungsplan mit in Aufgaben heruntergebrochenen Schritten haben.
• Die Aufgaben weitgehend unabhängig sind – also keine ständige Abstimmung über Aufgaben hinweg benötigen.
• Sie den Plan in der aktuellen Session abschließen möchten und ihn nicht über mehrere Tage strecken.

Wenn Sie noch keinen Plan haben oder die Aufgaben stark gekoppelt und in schneller Entwicklung sind, sollten Sie zuerst:

• Den Plan mit anderen Skills oder manuell entwerfen und ausarbeiten.
• Für explorative Arbeiten einen freieren Single-Agent-Workflow verwenden.

Verwendung

Installation

1. Skill zu Ihrer Umgebung hinzufügen

Installieren Sie das subagent-driven-development Skill aus dem obra/superpowers Repository:

npx skills add https://github.com/obra/superpowers --skill subagent-driven-development

Dadurch werden die Skill-Definition und unterstützende Prompt-Templates in Ihre Skills-fähige Umgebung geladen, sodass Sie Subagents für jede Aufgabe in Ihrem Plan orchestrieren können.

2. Die zentralen Dateien prüfen

Öffnen Sie nach der Installation das Skill-Verzeichnis im Repository (oder über Ihren Skills-Browser) und sehen Sie sich Folgendes an:

• SKILL.md – überblicksartige Beschreibung, Einsatzszenarien und Core-Workflow.
• implementer-prompt.md – Template für Ihren Implementer-Subagent.
• spec-reviewer-prompt.md – Template für Ihren Spec-Compliance-Reviewer-Subagent.
• code-quality-reviewer-prompt.md – Template für Ihren Code-Quality-Reviewer-Subagent.

Betrachten Sie diese Dateien als Vorlagen, die Sie in Ihre eigene Automatisierung oder Tool-Verkabelung kopieren oder anpassen können.

Ihren Implementierungsplan vorbereiten

1. Aufgabenliste erstellen oder verfeinern

Bevor Sie subagent-driven-development verwenden, erstellen Sie einen Implementierungsplan mit Aufgaben, die:

• klar abgegrenzt und testbar sind,
• weitgehend unabhängig voneinander sind,
• so detailliert beschrieben sind, dass ein Implementer-Subagent ohne Raten handeln kann.

Jede Aufgabe sollte so formuliert sein, dass sie sich als „FULL TEXT of task from plan“ in den Implementer-Prompt kopieren lässt.

2. Working Directory und Git-Strategie festlegen

Die Prompt-Templates gehen von einem Git-basierten Workflow und einem konkreten Working Directory aus:

• Wählen Sie ein directory, in dem der Implementer arbeiten soll.
• Legen Sie fest, wie Sie Änderungen nachverfolgen (z. B. BASE_SHA und HEAD_SHA pro Aufgabe).

Diese Werte geben Sie in die Spec- und Code-Quality-Reviewer-Prompts ein, um präzise Reviews zu ermöglichen.

Workflow pro Aufgabe ausführen

1. Einen Implementer-Subagent starten

Für jede Aufgabe N erstellen Sie einen neuen Implementer-Subagent auf Basis des Templates in implementer-prompt.md.

Wichtige Punkte aus dem Template:

• Dem Implementer wird explizit gesagt: “You are implementing Task N: [task name]”.
• Sie fügen den vollständigen Aufgabentext in den Abschnitt ## Task Description ein.
• Sie ergänzen:
  • Context – wie die Aufgabe in Ihr System eingebettet ist.
  • directory – wo Änderungen vorzunehmen sind.

Der Implementer wird angewiesen:

1. Bei Unklarheiten vorab Rückfragen zu stellen.
2. Genau das umzusetzen, was in der Aufgabe spezifiziert ist.
3. Tests zu schreiben und auszuführen, sofern sinnvoll.
4. Die Implementierung zu verifizieren.
5. Die Arbeit zu committen.
6. Einen klaren Report darüber zu erstellen, was erledigt wurde.

Da Sie für jede Aufgabe einen frischen Subagent erzeugen, sieht dieser nur den von Ihnen bereitgestellten Kontext und erbt keine irrelevante Historie aus Ihrer Hauptsession.

2. Spec-Compliance-Review ausführen

Sobald der Implementer fertig ist und Bericht erstattet hat, starten Sie einen Spec-Compliance-Reviewer-Subagent mit spec-reviewer-prompt.md.

In dieses Template:

• fügen Sie die Aufgabenanforderungen in ## What Was Requested ein,
• und den Report des Implementers in ## What Implementer Claims They Built.

Der Spec-Reviewer wird ausdrücklich angewiesen, dem Report des Implementers nicht zu vertrauen und muss:

• den tatsächlichen Code lesen,
• ihn Zeile für Zeile mit den Anforderungen vergleichen,
• fehlende Anforderungen, ungewollte Extras und Missverständnisse identifizieren.

Wenn der Spec-Reviewer Probleme findet, gehen Sie zurück zum Implementer (denselben oder einen neuen Subagent), um die Lücken zu schließen, bevor Sie fortfahren.

3. Code-Quality-Review ausführen

Nachdem die Spec-Compliance bestanden ist, starten Sie einen Code-Quality-Reviewer-Subagent mit code-quality-reviewer-prompt.md.

Das Template erwartet eine Aufgabenbeschreibung im Code-Review-Stil, zum Beispiel:

Task tool (superpowers:code-reviewer):
  Use template at requesting-code-review/code-reviewer.md

  WHAT_WAS_IMPLEMENTED: [from implementer's report]
  PLAN_OR_REQUIREMENTS: Task N from [plan-file]
  BASE_SHA: [commit before task]
  HEAD_SHA: [current commit]
  DESCRIPTION: [task summary]

Der Reviewer prüft:

• Sauberkeit und Wartbarkeit der Implementierung,
• Verantwortlichkeiten und Schnittstellen der Dateien (wo möglich eine klare Verantwortung pro Datei),
• ob neue oder geänderte Dateien angemessen zugeschnitten und strukturiert sind,
• Testabdeckung sowie Verständlichkeit und Testbarkeit einzelner Einheiten.

Er liefert strukturiertes Feedback: Stärken, Issues (Critical / Important / Minor) und eine Gesamtbewertung.

Anschließend entscheiden Sie, ob Sie:

• die Änderung so akzeptieren oder
• den Implementer um nachgelagerte Refactorings bitten.

Den Workflow an Ihre Umgebung anpassen

1. Prompts für Ihren Stack anpassen

Die Templates in implementer-prompt.md, spec-reviewer-prompt.md und code-quality-reviewer-prompt.md sind bewusst generisch gehalten. Passen Sie sie an Ihre:

• Programmiersprachen und Frameworks,
• Testkonventionen (z. B. pytest, Jest, Go test),
• Repository-Struktur und Namensgebung an.

Behalten Sie die Kernstruktur bei – frischer Subagent, klare Abschnitte, explizite Jobbeschreibung – auch wenn Sie Details anpassen.

2. Wiederkehrende Schritte automatisieren

Sobald Sie mit dem Muster vertraut sind, können Sie es skripten oder in Tools gießen:

• Fassen Sie die drei Subagent-Aufrufe (Implementer → Spec Reviewer → Code-Quality-Reviewer) zu einem einzigen Befehl pro Aufgabe zusammen.
• Generieren Sie aufgabenbezogene Prompts automatisch aus einer Plan-Datei.
• Füllen Sie BASE_SHA und HEAD_SHA automatisch, indem Sie Git-Metadaten auslesen.

So wird subagent-driven-development zu einem wiederholbaren Workflow-Automatisierungsbaustein für Ihr Team.

3. Wann dieses Skill nicht gut passt

Ein anderer Ansatz ist sinnvoll, wenn:

• Aufgaben stark voneinander abhängen und sich nicht sauber isolieren lassen,
• Sie noch keinen klaren Implementierungsplan haben,
• Sie langlaufende, sessionsübergreifende Arbeit benötigen, bei der Kontext über Tage erhalten bleiben muss.

Nutzen Sie in solchen Fällen Skills oder Prozesse, die auf Planung, Architektur oder Long-Running-Agents ausgerichtet sind, und kehren Sie zu subagent-driven-development zurück, sobald Sie klar abgegrenzte Aufgaben ausführen möchten.

FAQ

Was bedeutet „subagent-driven-development“ in der Praxis?

In der Praxis bedeutet subagent-driven-development, dass Sie nicht einen allwissenden Agent bitten, alles zu planen, zu coden und zu reviewen. Stattdessen:

• behalten Sie Koordination und Gesamtüberblick in Ihrer Hauptsession,
• erstellen Sie für jede Aufgabe einen frischen Subagent mit nur den Informationen, die er benötigt,
• lassen Sie diesen Subagent die Aufgabe implementieren und anschließend zwei weitere Subagents das Ergebnis reviewen.

So trennen Sie Verantwortlichkeiten, halten den Kontext überschaubar und erhöhen die Zuverlässigkeit in jedem Schritt Ihres Implementierungsplans.

Worin unterscheidet sich das von einer normalen Single-Agent-Coding-Session?

In einer Single-Agent-Session sammeln sich frühere Konversationen und Code-Änderungen in einem einzigen Kontext an. Das kann zu Folgendem führen:

• Verwechslung alter und neuer Anforderungen,
• Wiederverwendung derselben Denkfehler in Implementierung und Review.

subagent-driven-development hingegen:

• nutzt separate Prompts und Rollen für Implementierung und Review,
• startet jeden Subagent mit kuratetem Kontext statt dem gesamten Session-Verlauf,
• erzwingt die Reihenfolge zuerst Spec-Review, dann Qualitäts-Review.

Das führt typischerweise zu präziseren Implementierungen und ehrlicheren Reviews.

Muss ich die Templates exakt befolgen?

Nein. Die Templates im Repository sind Beispiele dafür, wie Sie Prompts für Implementer, Spec-Reviewer und Code-Quality-Reviewer strukturieren können. Sie sollten:

• das Grundmuster beibehalten: Implementer → Spec-Review → Quality-Review,
• zentrale Verhaltensweisen erhalten (z. B. der Spec-Reviewer muss den echten Code lesen und darf dem Report nicht blind vertrauen).

Innerhalb dieses Rahmens können Sie Formulierungen anpassen, projektspezifische Hinweise ergänzen und Ihre Tools und Konventionen integrieren.

Kann ich subagent-driven-development ohne Git nutzen?

Das Code-Quality-Reviewer-Template geht von Feldern wie BASE_SHA und HEAD_SHA aus, die in einem Git-Workflow naheliegen. Wenn Sie Git nicht verwenden:

• können Sie die Kernideen – frische Subagents und zweistufiges Review – trotzdem anwenden,
• ersetzen Sie SHAs durch Ihre eigene Art, Vorher-/Nachher-Zustände zu referenzieren (z. B. Archiv-IDs oder Snapshot-Pfade).

Das Skill setzt Git nicht voraus; es liefert lediglich Git-orientierte Beispiele.

Ist dieses Skill an ein bestimmtes AI-Modell gebunden?

Das Repository schreibt kein spezifisches Modell hart vor, ist aber eindeutig auf moderne, allgemeine Coding-Modelle wie Anthropics Claude / claude-code ausgerichtet. Sie sollten:

• ein Modell nutzen, das Code und Tests lesen und nachvollziehen kann,
• sicherstellen, dass Ihre Umgebung das Starten mehrerer Subagents mit eigenen Prompts unterstützt.

Wenn Ihr Stack Agent-Tools oder Task-Runner unterstützt, können Sie diese Templates dort einbinden.

Woran erkenne ich, ob ich subagent-driven-development oder ein anderes superpowers Skill nutzen sollte?

Die Datei SKILL.md beschreibt Entscheidungskriterien: Verwenden Sie subagent-driven-development, wenn Sie einen Implementierungsplan haben, Ihre Aufgaben weitgehend unabhängig sind und Sie in der aktuellen Session bleiben. Wenn dies nicht zutrifft, können Sie:

• zuerst Planning- oder Brainstorming-Skills einsetzen, um den Plan zu erarbeiten,
• andere Ausführungs- oder Planungsmuster für eng gekoppelte, sessionsübergreifende Arbeit nutzen.

Wo sollte ich im Repository beginnen?

Wenn Sie prüfen möchten, ob Sie dieses Skill installieren oder übernehmen sollten, starten Sie mit:

1. SKILL.md – für die Begründung und den High-Level-Workflow.
2. implementer-prompt.md – um zu sehen, wie Implementer-Subagents gerahmt werden.
3. spec-reviewer-prompt.md – um die Spec-Compliance-Prüfungen zu verstehen.
4. code-quality-reviewer-prompt.md – für einen Überblick über zusätzliche Qualitäts- und Strukturchecks.

Von dort aus können Sie diese Templates in Ihre eigene Agent-Orchestrierung oder Workflow-Automatisierung übernehmen und subagent-driven-development voll ausschöpfen.