subagent-driven-development

Überblick über die Fähigkeit subagent-driven-development

Was subagent-driven-development tatsächlich leistet

Die Fähigkeit subagent-driven-development beschreibt einen Workflow, mit dem ein Implementierungsplan zuverlässig umgesetzt wird: Die Arbeit wird in unabhängige Aufgaben zerlegt, jede Aufgabe an einen frischen Subagenten übergeben, und jedes Ergebnis wird in zwei Durchläufen geprüft – zuerst auf Spezifikationskonformität, danach auf Codequalität. Der eigentliche Mehrwert von subagent-driven-development ist nicht einfach „mehr Agenten einsetzen“, sondern Kontext bewusst zu isolieren, damit jeder Bearbeiter nur die Aufgabe, Anforderungen und den lokalen Code-Kontext erhält, die er wirklich braucht.

Für wen sich diese Fähigkeit am besten eignet

Diese Fähigkeit subagent-driven-development ist ideal für alle, die bereits einen Plan haben und ihn in der aktuellen Session in eine verlässliche Implementierung überführen wollen. Sie passt besonders gut, wenn:

• Aufgaben weitgehend unabhängig voneinander sind
• der koordinierende Agent auf Orchestrierung fokussiert bleiben soll
• es wichtig ist, sowohl Anforderungsdrift als auch schlampigen Code früh zu erkennen
• ein wiederholbarer Review-Loop gewünscht ist statt eines einmaligen Coding-Prompts

Welches Problem damit gelöst wird

Nutzer setzen subagent-driven-development for Agent Orchestration ein, wenn ein normales Prompt wie „implement this plan“ regelmäßig auf vorhersehbare Weise scheitert: Der Agent vermischt Aufgaben, vergisst Randbedingungen, baut zu viel oder liefert Code, der plausibel aussieht, die Spezifikation aber verfehlt. Diese Fähigkeit etabliert ein diszipliniertes Übergabe- und Review-Muster, das genau diese Fehler reduziert.

Was den Unterschied zu einem generischen Prompt ausmacht

Die entscheidenden Unterschiede sind ganz praktisch:

• Frischer Subagent pro Aufgabe statt eines lang laufenden Agenten mit immer lauterer Historie
• Explizite Task-Pakete mit vollständig eingefügtem Aufgabentext, statt vom Bearbeiter zu erwarten, Anforderungen aus verstreuten Dateien zusammenzusuchen
• Verpflichtende Rückfragen vor dem Coding, damit Unklarheiten früh sichtbar werden
• Zweistufiges Review, bei dem „entspricht das der Spezifikation?“ klar von „ist der Code gut?“ getrennt wird

Diese Trennung ist wichtig. Viele Teams prüfen zuerst die Qualität und erst danach den Umfang. Dadurch werden überladene oder unvollständige Implementierungen schwerer erkennbar.

Wann subagent-driven-development die falsche Wahl ist

Beginne nicht mit subagent-driven-development, wenn noch kein konkreter Implementierungsplan existiert, wenn Aufgaben eng gekoppelt sind oder wenn die Arbeit eher in einen separaten parallelen Ausführungsfluss als in diese Session gehört. In solchen Fällen sind Planung oder eine andere Ausführungsfähigkeit meist der bessere erste Schritt.

So nutzt du die Fähigkeit subagent-driven-development

Fähigkeit subagent-driven-development installieren

Wenn du Fähigkeiten aus diesem Repository über die Skills CLI installierst, verwende:

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

Öffne danach vor dem ersten Einsatz die installierte Fähigkeit und die dazugehörigen Prompt-Templates.

Diese Dateien zuerst lesen

Für einen schnellen Einstieg lies die Dateien in dieser Reihenfolge:

1. SKILL.md
2. implementer-prompt.md
3. spec-reviewer-prompt.md
4. code-quality-reviewer-prompt.md

So verstehst du zuerst den Workflow und danach die genaue Form der Prompts für Implementierer und beide Review-Stufen.

Das Aufrufmuster von subagent-driven-development vorab verstehen

In der Praxis ist subagent-driven-development usage kein einzelner Zauberbefehl. Du nutzt es, indem du als Koordinator agierst:

1. eine Aufgabe aus dem Plan auswählen
2. einen frischen Implementierer-Subagenten mit einem eng gefassten Prompt losschicken
3. einen Bericht zurückfordern
4. einen Spec-Reviewer gegen den tatsächlichen Code laufen lassen
5. nur wenn die Spezifikation erfüllt ist, einen Code-Quality-Reviewer starten
6. akzeptieren, überarbeiten oder neu delegieren

Wenn du diese Review-Gates überspringst, nutzt du die Fähigkeit faktisch nicht mehr so, wie sie gedacht ist.

Welche Eingaben die Fähigkeit braucht

Bereite vor dem Dispatch eines Subagenten folgende Inputs vor:

• den exakten Aufgabentext aus deinem Plan
• Akzeptanzkriterien oder Anforderungen
• relevanten Architekturkontext
• Working Directory oder Repo-Scope
• Hinweise zu Abhängigkeiten oder Reihenfolge
• den Basis-Commit bzw. SHA für Review-Diffs
• Aufgabennummer und Aufgabenname zur Nachverfolgbarkeit

Die Vorlagen im Repository legen sehr klar nahe, dass du die vollständige Aufgabe in den Prompt einfügen solltest, statt dem Subagenten einfach zu sagen, er solle „die Plan-Datei lesen“.

Aus einem groben Ziel einen starken Implementierer-Prompt machen

Ein schwacher Prompt lautet:

• „Implement task 4 from the plan.“

Ein stärkerer Prompt im Stil eines subagent-driven-development guide enthält:

• Aufgabentitel und Aufgabennummer
• Den vollständigen Aufgabentext
• Warum diese Aufgabe existiert
• Wo im Repo gearbeitet werden soll
• Vorgaben zur Dateistruktur
• Ob Tests erforderlich sind
• Was zu tun ist, wenn Annahmen nötig werden
• Die ausdrückliche Anweisung, vor dem Coding Fragen zu stellen

Diese Struktur ist wichtig, weil die Fähigkeit auf kontrolliertem Kontext basiert – nicht auf autonomer, repoweiter Interpretation.

Beispiel für ein besseres Task-Paket

Verwende beim Dispatch an den Implementierer eine Struktur wie diese:

• Task N: [name]
• FULL TEXT of task from plan
• Context: where this fits, dependencies, architecture
• Work from: [directory]
• Requirements: implement exactly what is specified
• If anything is unclear, ask before starting
• Write tests if required by task
• Commit, self-review, and report back

Das ist verlässlicher, als den Bearbeiter breit explorieren zu lassen, denn bei dieser Fähigkeit liegt die Verantwortung für ein sauberes Assignment ausdrücklich beim Koordinator.

Warum das Spec-Review vor dem Quality-Review kommt

Das ist einer der wertvollsten Punkte bei einer subagent-driven-development install-Entscheidung: Die Reihenfolge ist bewusst gewählt.

Lass zuerst den Spec-Reviewer laufen, um zu klären:

• hat der Code wirklich das implementiert, was angefordert wurde?
• wurden Anforderungen ausgelassen?
• wurde zusätzliche, nicht angeforderte Arbeit eingebaut?
• wurde die Aufgabe missverstanden?

Erst danach sollte der Code-Quality-Reviewer folgen, der Wartbarkeit, Zerlegung, Dateiverantwortung und Form der Änderungen prüft. Wenn du die Reihenfolge umdrehst, kann gut aussehender Code Scope-Fehler kaschieren.

So nutzt du den Spec-Reviewer in subagent-driven-development sinnvoll

Das Template spec-reviewer-prompt.md ist ungewöhnlich direkt: Es fordert den Reviewer auf, dem Bericht des Implementierers nicht zu vertrauen und stattdessen den tatsächlichen Code Zeile für Zeile zu prüfen. Bewahre diesen Ton, wenn du es anpasst. Der Reviewer braucht:

• den vollständigen Anforderungstext
• das vom Implementierer behauptete Ergebnis
• Zugriff auf den geänderten Code

Es geht hier um unabhängige Verifikation, nicht um höfliche Bestätigung.

So nutzt du den Code-Quality-Reviewer sinnvoll

Das Code-Quality-Review ist hier kein generisches Style-Policing. In dieser Fähigkeit liegt der Fokus auf:

• einer klaren Verantwortlichkeit pro Datei
• sauber definierten Schnittstellen
• einer Zerlegung in verständliche Einheiten
• der Einhaltung der geplanten Dateistruktur
• der Frage, ob diese Aufgabe übergroße neue Dateien erzeugt oder bestehende Dateien unnötig aufgebläht hat

Gerade der letzte Punkt ist nützlich, weil Subagenten Aufgaben oft lösen, indem sie zu viel in eine einzige Änderung packen.

Empfohlener Workflow in einem echten Repo

Ein praktischer subagent-driven-development usage-Loop sieht so aus:

1. die nächste unabhängige Aufgabe auswählen
2. den aktuellen Commit als Basis festhalten
3. den Implementierer mit dem vollständigen Aufgabentext losschicken
4. seine Zusammenfassung und die geänderten Dateien einsammeln
5. das Spec-Review gegen Anforderungen und Code durchführen
6. bei fehlgeschlagener Spezifikation konkrete Lücken an den Implementierer zurückgeben
7. wenn die Spezifikation passt, das Code-Quality-Review starten
8. bei Qualitätsmängeln gezielte Überarbeitung anfordern
9. mergen oder zur nächsten Aufgabe übergehen

So behält der Koordinator die Kontrolle über Reihenfolge und Abnahme.

Einschränkungen, die die Ergebnisqualität beeinflussen

Die Fähigkeit funktioniert am besten, wenn du ihre Grenzen respektierst:

• unabhängige Aufgaben funktionieren besser als verhedderte Aufgaben
• explizite Anforderungen funktionieren besser als nur erschlossene Anforderungen
• ein enger Repo-Scope ist besser als „schau dich um und entscheide selbst“
• kurze Task-Loops sind besser als große Multi-Feature-Batches
• klare Eskalationsregeln sind besser als stilles Raten

Wenn du merkst, dass ein Subagent viele bewegliche Teile über die gesamte Codebasis hinweg zusammenführen muss, ist die Aufgabe für diesen Workflow wahrscheinlich zu breit.

Häufiger Einführungsfehler

Der größte Fehler besteht darin, die Fähigkeit subagent-driven-development nur als Label zu verwenden, aber weiterhin lockere Prompts zu schreiben. Der Workflow bringt nur dann echten Nutzen, wenn du den Kontext sauber paketierst und die Review-Reihenfolge konsequent durchsetzt. Andernfalls hast du den Aufwand der Orchestrierung ohne die Qualitätsgewinne.

FAQ zur Fähigkeit subagent-driven-development

Ist subagent-driven-development gut für Einsteiger?

Ja, sofern du bereits verstehst, was konkret gebaut werden soll. Der Workflow ist explizit, und die bereitgestellten Prompt-Templates verringern den Rätselanteil. Er ersetzt aber keine Planung. Einsteiger ohne klaren Implementierungsplan werden oft Schwierigkeiten haben, weil die Fähigkeit voraussetzt, dass die Aufgaben bereits definiert sind.

Wann sollte ich subagent-driven-development nicht verwenden?

Lass subagent-driven-development aus, wenn:

• du das Problem noch explorierst
• Aufgaben stark voneinander abhängen
• Anforderungen instabil sind
• ein Mensch oder ein einzelner Agent das Gesamtsystem durchgängig im Blick behalten muss

Es ist ein Ausführungsmuster, kein Discovery-Muster.

Worin unterscheidet sich das davon, einfach einen Agenten alles coden zu lassen?

Ein einzelner langer Prompt vermischt oft Planung, Implementierung, Validierung und Review in einem einzigen Kontextfenster. Diese Fähigkeit trennt diese Rollen. Das verbessert in der Regel den Fokus, macht Anforderungsdrift leichter erkennbar und bewahrt den Kontext des Koordinators für Orchestrierung statt für Codegenerierung.

Braucht die Fähigkeit spezielle Tools?

Nein. In diesem Skill-Ordner sind keine speziellen Skripte gebündelt. Das Repository liefert Markdown-Prompt-Templates statt Automatisierungscode. Du kannst das Muster überall einsetzen, wo du Subagenten dispatchen und Code-Review-Aufgaben ausführen kannst.

Ist subagent-driven-development nur für große Projekte gedacht?

Nein. Es kann auch bei kleinen Änderungen sinnvoll sein, den größten Nutzen bringt es aber meist dann, wenn ein Plan mehrere unabhängige Aufgaben enthält und die Kosten verpasster Anforderungen hoch genug sind, um den zusätzlichen Review-Aufwand zu rechtfertigen.

Welche Hinweise im Repository sind vor der Installation am wichtigsten?

Für diese Fähigkeit liegt der wichtigste Beleg in der Workflow-Struktur in SKILL.md und in den drei Prompt-Templates. Es gibt keine Helper-Skripte oder Resource-Ordner, die im Hintergrund versteckte Arbeit übernehmen. Deine Installationsentscheidung sollte sich daher daran orientieren, ob Prompt-Struktur und Review-Disziplin zu deiner Art passen, Code auszuliefern.

So verbesserst du die Fähigkeit subagent-driven-development

Für subagent-driven-development bessere Task-Pakete geben, nicht längere Prompts

Um die Ergebnisse der Fähigkeit subagent-driven-development zu verbessern, erhöhe lieber die Präzision als die Länge. Besonders hilfreich sind:

• exakte Akzeptanzkriterien
• explizite Nicht-Ziele
• Architekturhinweise, die nur für diese Aufgabe relevant sind
• Datei- oder Verzeichnisgrenzen
• Beispiele für das erwartete Verhalten
• Test-Erwartungen

So bleibt der Implementierer fokussiert, und der Spec-Reviewer erkennt Drift leichter.

Aufgaben schärfer abgrenzen

Viele Fehler entstehen durch schlecht geschnittene Arbeitspakete. Wenn ein Subagent gleichzeitig mehrere bewegliche Teile koordinieren, Architektur entscheiden und Anforderungen erschließen muss, teile die Aufgabe weiter auf. Gute Aufgaben sind so eng gefasst, dass sich „genau das Gewünschte implementiert“ leicht überprüfen lässt.

Den Schritt „erst Fragen stellen“ beibehalten

Das Implementierer-Template sagt ausdrücklich, dass der Bearbeiter vor dem Start Fragen stellen soll – und später erneut, falls während der Implementierung Überraschungen auftauchen. Behalte dieses Verhalten bei. Rückfragen zu unterdrücken erzeugt zwar schnelle, aber unzuverlässige Ergebnisse und unterläuft damit den Zweck der Fähigkeit.

Review-Qualität mit stärkeren Vergleichsgrundlagen verbessern

Für den Spec-Reviewer solltest du bereitstellen:

• den vollständigen Anforderungstext
• den Bericht des Implementierers
• die geänderten Dateien oder den Diff-Scope
• alle expliziten Ausschlüsse

Für den Code-Quality-Reviewer solltest du bereitstellen:

• BASE_SHA
• HEAD_SHA
• eine Task-Zusammenfassung
• den relevanten Abschnitt aus dem Plan

Mit diesen konkreten Vergleichsankern wird aus dem Review mehr als bloße Meinung.

Auf diese typischen Fehlerbilder achten

Die häufigsten Probleme bei subagent-driven-development for Agent Orchestration sind:

• der Implementierer leitet zusätzliche Features her
• im Task-Paket fehlt eine wichtige Einschränkung
• der Reviewer vertraut der Implementierer-Zusammenfassung zu stark
• das Code-Quality-Review läuft vor dem Spec-Review
• Aufgaben sind zu groß, um sauber überprüft zu werden
• Dateiwachstum bleibt unkontrolliert

Jeder dieser Punkte lässt sich mit besserer Aufgabenpaketierung und strengeren Gates vermeiden.

Nach der ersten Ausgabe gezielt iterieren

Wenn der erste Durchlauf schwach ist, starte nicht sofort komplett neu. Prüfe zuerst, auf welcher Ebene das Problem lag:

• Spec-Fehler: Anforderungen waren unklar, unvollständig oder übererfüllt
• Qualitätsfehler: Probleme bei Zerlegung, Wartbarkeit oder Dateistruktur
• Koordinationsfehler: Task-Schnitt oder Kontextpaketierung waren falsch

Überarbeite dann nur diese Ebene. So bleibt der Workflow effizient.

Vorgaben zur Dateistruktur präzisieren

Ein nützliches Detail aus dem Quality-Template ist die Prüfung, ob die Implementierung der geplanten Dateistruktur gefolgt ist und ob neu angelegte Dateien bereits zu groß geraten. Wenn dir Wartbarkeit wichtig ist, gib die gewünschten Dateigrenzen schon im Task-Paket vor, statt darauf zu hoffen, dass Reviewer es später korrigieren.

Eine wiederverwendbare lokale Checkliste anlegen

Wenn du subagent-driven-development häufiger einsetzen willst, halte eine kurze Koordinator-Checkliste bereit:

• Plan existiert
• Aufgabe ist unabhängig
• vollständige Aufgabe eingefügt
• Einschränkungen enthalten
• Baseline-SHA erfasst
• Implementierer wurde aufgefordert, vor dem Coding Rückfragen zu stellen
• Spec-Review abgeschlossen
• Quality-Review abgeschlossen

Diese kleine Gewohnheit verbessert die Konsistenz mehr als noch längere Prompts.

Die Fähigkeit an den eigenen Workflow anpassen

Die Basisfähigkeit ist bewusst leichtgewichtig gehalten. Um sie in deiner Umgebung wirksamer zu machen, passe die Prompt-Templates an deinen Stack und deine Review-Standards an:

• ergänze deine Test-Kommandos
• ergänze repo-spezifische Architekturregeln
• definiere, was bei euch als Over-Engineering gilt
• lege dein bevorzugtes Berichtsformat fest
• füge typische Fehlerbilder aus eurer Codebasis hinzu

Solches lokales Fine-Tuning verbessert subagent-driven-development usage in der Praxis meist stärker als noch mehr Theorie.