Von BMAD über Spec Kit bis GSD: Für Claude Code entstehen gerade ständig neue Entwicklungsframeworks, und es wird immer schwerer, den Überblick zu behalten. Superpowers ist ein sehr leichtgewichtiges Framework und das erste, das ich teste, das primär auf Test-Driven Development setzt. Es werden also zuerst Tests geschrieben, um Fehler von vornherein auszuschließen.
In diesem Artikel erkläre ich dir, was Test-Driven Development ist, wie der Superpowers-Workflow aufgebaut ist, wie du ihn installierst und was ich beim Bau einer echten Finanzplanungs-App gelernt habe. Am Ende ordne ich ein, für wen sich das Framework lohnt.
Warum es Frameworks für Claude Code überhaupt gibt
Frameworks wie Superpowers lösen zwei Probleme: Sie sollen die Qualität der Ergebnisse steigern, und sie kümmern sich um Context Engineering. Gemeint ist damit, dass dein Coding Agent über ein ganzes Projekt hinweg den Überblick behält.
Das zugrunde liegende Problem heißt Context Rot. Claude arbeitet in jeder Session mit einem Kontextfenster. Jede Nachricht, jede Antwort und jede Datei, die gelesen oder bearbeitet wird, füllt diesen Kontext. Irgendwann verdichtet das Modell den Verlauf zu einer Zusammenfassung und arbeitet nur noch damit weiter. Dabei gehen Details verloren, und die Leistung des Agenten nimmt ab.
Das Ziel ist also, dem Agenten zur richtigen Zeit den richtigen Kontext zu geben. Jedes Framework löst das auf seine eigene Art. Superpowers geht dabei einen etwas anderen Weg als die anderen.
Was ist Test-Driven Development?
Ein Leitsatz, der direkt in den Skill-Dateien von Superpowers steht, lautet: „No production code without a failing test first.“ Es gibt also keinen produktiven Code, ohne dass vorher ein Test fehlgeschlagen ist.
Wenn du nicht aus der Entwicklung kommst, klingt das abstrakt. Test-Driven Development (TDD) folgt einem Zyklus aus drei Phasen:
| Phase | Was passiert |
|---|---|
| Red | Der Agent schreibt zuerst einen Test, der beschreibt, was der Code tun soll. Der Test scheitert, weil der Code noch nicht existiert. Das ist Absicht. |
| Green | Der Agent schreibt den minimalen Code, der nötig ist, damit der Test besteht. Nicht mehr und nicht weniger. |
| Refactor | Der Code wird verbessert: besser strukturiert, lesbarer, effizienter. Die Tests müssen dabei weiter funktionieren. |
Dieser Zyklus wiederholt sich für jedes Feature, jede Funktion und jeden Bugfix.
Woher weiß der Agent, was getestet werden soll?
Vor dem ersten Test steht in Superpowers immer eine Spezifikation, also eine Funktionsbeschreibung mit Akzeptanzkriterien. Sie entsteht ganz am Anfang in der Brainstorming-Phase. Der Test ist dann nichts anderes als die maschinenlesbare Übersetzung dieser Akzeptanzkriterien.
Dafür gibt es einen eigenen Begriff: ATDD, Acceptance Test-Driven Development. Die Reihenfolge lautet also: erst die Spezifikation, dann der Test, zum Schluss der Code.
Das ist mehr Aufwand, keine Frage. Dafür weißt du nach jeder Änderung sofort, ob dein Projekt noch funktioniert, und nicht erst, wenn du es manuell durchgeklickt hast. TDD ist seit Jahrzehnten Standard in der professionellen Softwareentwicklung. Superpowers verpackt das in einen AI-Coding-Workflow.
Die „eiserne Regel“ im TDD-Skill
Spannend finde ich, wie konsequent der TDD-Skill den Agenten davon abhält, Code vor den Tests zu schreiben. Neben dem Leitsatz oben (dem „Iron Law“) steht dort sinngemäß: Wurde Code vor dem Test geschrieben, wird er gelöscht, und es wird neu angefangen. Ohne Ausnahmen, auch die Sonderfälle sind explizit ausgeschlossen.
Dazu kommt ein Abschnitt, der erklärt, warum die Reihenfolge so wichtig ist. Und es gibt eine Liste mit den häufigsten Ausreden, die ein Coding Agent finden könnte, um das Schreiben von Tests zu überspringen. Jeder dieser Auswege wird damit von Anfang an verbaut. Wenn du eigene Skills schreibst, kannst du dir von dieser Technik einiges abschauen.
Der Superpowers-Workflow: 5 Phasen
Im Repository findest du 14 einzelne Skill-Dateien. Zusammen ergeben sie einen Workflow in fünf Phasen.
Phase 1: Brainstorming
Hier geht es darum herauszufinden, worum es in deinem Projekt geht und welche Anforderungen du hast. Der Agent stellt dir Fragen, schaut sich aber auch vorhandene Dateien, Dokumentation und die letzten Git-Commits an.
Ein Feature, das ich so noch bei keinem anderen Framework gesehen habe, ist der Visual Companion. Er zeigt dir im Browser visuelle Vorschläge für deine Anwendung und deine Features. Am Ende der Phase hast du ein Spezifikationsdokument mit den Designentscheidungen zur Architektur und den Akzeptanzkriterien.
Phase 2: Git Worktree
Superpowers richtet einen Git Worktree ein. Das ist eine zusätzliche Arbeitskopie deines Projekts auf einem eigenen Branch. Die Entwicklung jedes Features läuft also getrennt vom Hauptstand.
In meinem Test hat das Framework diese Phase allerdings komplett übersprungen und ist direkt vom Brainstorming in die Planung gegangen, ohne mich zu fragen. Ob das an meinen Anforderungen lag, weiß ich nicht. Du kannst die Phase aber jederzeit manuell anstoßen.
Phase 3: Planung
Jetzt wird das Spezifikationsdokument aus dem Brainstorming in konkrete Aufgaben zerlegt. Teilweise sind darin schon vollständige Codeblöcke und konkrete Terminalbefehle hinterlegt. Das hilft den Agenten, die später entwickeln, die Aufgaben auszuführen, ohne Annahmen treffen zu müssen.
Bis hierhin arbeitet das Framework ohne Subagenten. Alles läuft über den Hauptagenten.
Phase 4: Subagent Driven Development
In dieser Phase ändert sich die Arbeitsweise grundlegend. Claude wird zum Orchestrator: Er liest den Plan und koordiniert Subagenten für die Umsetzung. Subagenten sind eigenständige Helfer mit eigenem, frischem Kontextfenster.
Die Subagenten laufen nicht parallel, sondern nacheinander. Im Skill ist Parallelisierung sogar ausdrücklich verboten. Dafür gibt es zwei Gründe: Konflikte in der Codebase werden vermieden, und pro Aufgabe arbeiten ohnehin drei Subagenten hintereinander:
- Implementer: schreibt den Code, automatisch nach Test-Driven Development.
- Spec Reviewer: prüft, ob der Code der Spezifikation entspricht.
- Code Quality Reviewer: prüft, ob der Code sauber geschrieben ist.
Wenn alle Aufgaben erledigt sind, prüft ein finaler Code-Reviewer-Subagent die Gesamtimplementierung noch einmal als Ganzes.
Phase 5: Branch abschließen
Zum Schluss wird der Branch abgeschlossen. Der Agent prüft, ob alle Tests grün sind, und legt dir vier Optionen vor:
- lokal in den Main-Branch mergen,
- einen Pull Request erstellen,
- den Branch so behalten,
- die Arbeit verwerfen.
Superpowers installieren
Ich nutze Superpowers mit Claude Code in VS Code. Es funktioniert aber auch mit anderen Coding Agents. In Claude Code ist die Installation sehr einfach, weil Superpowers im offiziellen Plugin-Marktplatz verfügbar ist. Du kannst im Plugin-Menü nach „Superpowers“ suchen oder den Befehl direkt eingeben:
/plugin install superpowers@claude-plugins-official
Bei der Installation wählst du die Ebene: global für alle Projekte (User-Ebene) oder nur für das aktuelle Projekt. Ich habe für den Test die Projektebene gewählt. Nach einem kurzen Neuladen stehen dir die Skills zur Verfügung, und du startest mit dem Brainstorming.
Den Quellcode und alle Skill-Dateien findest du im Superpowers-Repository auf GitHub.
Praxistest: Eine Finanzplanungs-App mit Lexoffice-Anbindung
Für den Test habe ich mir einen echten Anwendungsfall gesucht: meine Unternehmensfinanzplanung. Die mache ich bisher in Google Sheets, und es ist lästig, alles aktuell zu halten. Ich wollte eine Web-App mit Ist- und Soll-Planung, die in Echtzeit an Lexoffice, mein Buchhaltungstool, angebunden ist. Lexoffice hat eine öffentliche API, über die ich Buchungen und Belege abrufen kann.
Der Start-Prompt
Ich bin mit Superpowers in die Brainstorming-Phase eingestiegen und habe diesen Prompt mitgegeben (sinngemäß):
Baue mir eine Next.js-Webanwendung zur Finanzplanung meines Unternehmens, die ich bisher in Google Sheets gemacht habe.
Anforderungen:
- Tech-Stack: Next.js, keine Authentifizierung. Die App läuft erstmal nur lokal auf meinem Rechner.
- Datenspeicherung vorerst in JSON-Dateien. Eine spätere Migration auf SQLite soll möglich bleiben.
- Lexoffice-Integration: Ausgangsrechnungen, Belege usw. automatisch per API abrufen.
- Ist-Planung mit den tatsächlichen Werten aus Lexoffice.
- Soll-Planung, in der ich meine Ziele eingebe.
- Gehälter berücksichtigen, z.B. ein Geschäftsführergehalt von 5.000 € im Monat. Erweiterbar um weitere Mitarbeitende.
- Steuerliche Berechnung automatisch einbeziehen.
Zusätzlich habe ich eine „Traumplanung“ angelegt, um mit verschiedenen Szenarien und Zahlen zu spielen.
Rückfragen und Lösungsansätze
Claude hat zuerst einen kleinen Plan für die Phase erstellt und dann gefragt, ob ich den Visual Companion nutzen will. Mit dem Hinweis, dass das Feature neu ist und viele Token verbrauchen kann. Ich habe zugestimmt.
Danach kamen Rückfragen, jeweils mit Antwortoptionen:
- Kategorien für Einnahmen und Ausgaben: fest, dynamisch oder hybrid? Ich habe feste Kategorien gewählt, die sich über die Oberfläche erweitern lassen.
- Zeitraum: nur das aktuelle Jahr, Jahresauswahl oder rollierende 12 Monate? Das aktuelle Jahr, aufgeteilt in Monate.
- Eingabe der Soll- und Traumwerte: monatsweise oder als Jahreswert? Monatsweise.
- Zuordnung der Lexoffice-Belege zu Kategorien: manuell oder automatisch? Erstmal manuell.
- Auslösen des Datenabrufs: Automatisch beim Laden der App.
Anschließend hat Claude drei Architekturansätze vorgeschlagen, mit einer Empfehlung: eine Single Page mit Server Actions. Die Alternativen waren API Routes und Client-seitiges Laden der Daten. Ich habe die Empfehlung genommen. Danach hat er mir die Projektstruktur und das Datenmodell im JSON-Format zum Abnicken vorgelegt.
Der Visual Companion im Einsatz
Für das Layout hat Claude einen lokalen Server gestartet und mir im Browser zwei Varianten für die Haupttabelle gezeigt: eine klassisch kompakte Planungstabelle und eine Kombination aus Dashboard und Tabelle. Ich habe die kompakte Variante gewählt.
Danach folgte die Seitenstruktur (Planungstabelle, Zuordnung, Einstellungen mit einfacher Top-Navigation) und noch einmal zwei Layout-Varianten für die Zuordnungsseite. So triffst du Designentscheidungen, bevor eine Zeile Code geschrieben ist.
Spezifikation und Implementierungsplan
Im docs-Ordner lag danach ein Design-Dokument: Überblick, Tech-Stack, Projektstruktur, Datenmodell, Datenschicht, Seiten und Komponenten, Details zur Lexoffice-Integration, Berechnungslogik, Navigation und ein Abschnitt, was nicht zum Umfang gehört. Claude bat mich, es zu prüfen, bevor er den Implementierungsplan erstellt.
Ehrlicher Einschub: Beim Schreiben des Implementierungsplans hing Claude in meinem Live-Durchlauf fest. Auch nach geleertem Kontext, neuen Sessions und Neustart ging es an diesem Schritt nicht weiter. Ich hatte das Projekt aber vorher schon einmal komplett gebaut und bin dort an derselben Stelle wieder eingestiegen.
Der Implementierungsplan enthält das Ziel, die Architektur, den Tech-Stack, die Projektstruktur und dann die Aufgaben in Reihenfolge: Projekt anlegen, Abhängigkeiten, Designbibliothek und Test-Setup installieren, dann die Datenschicht mit den Entitäten, die Steuerberechnung, die JSON-Speicherschicht, den Lexoffice-API-Client und so weiter. Jede Aufgabe ist mit Code-Snippets so weit vorbereitet, dass die Agenten bei der Umsetzung weniger Fehler machen.
Umsetzung mit Subagenten
Nach dem Plan bietet Superpowers zwei Ausführungsoptionen an:
- Subagent Driven: Pro Aufgabe startet ein frischer Subagent, nacheinander. Das ist die Empfehlung.
- Inline Execution: Die Aufgaben werden direkt in der aktuellen Session vom Hauptagenten umgesetzt.
Ich habe die Subagent-Variante gewählt. Claude legt sich eine To-do-Liste an und setzt Implementer, Spec Reviewer und Code Quality Reviewer nacheinander auf jede Aufgabe an. Zwischendurch gibt er kurze Updates und testet laufend. Am Ende folgt das finale Review der gesamten Umsetzung und dann die Abschlussphase mit den vier Optionen für den Branch.
Das Ergebnis
Die fertige App zieht die Daten direkt aus Lexoffice, in meinem Fall Dummy-Daten aus dem Testkonto. Es gibt eine Übersicht mit Einnahmen, Ausgaben und Nettogewinn, die Ist-Planung mit den automatisch übernommenen Positionen, die Soll- und die Traumplanung. Jedes Feld ist editierbar und wird korrekt durchgerechnet. Dazu kommen eine Gehaltsverwaltung, in der ich Mitarbeitende hinzufügen kann, und die Einstellungen mit API-Key und Kategorien.
Meine Learnings aus dem Test
Erfundene API-Endpunkte: Context7 hilft
Claude hat bei der Lexoffice-Anbindung Endpunkte implementiert, die es gar nicht gibt, obwohl er vorher sogar eine Webrecherche gemacht hatte. Höchstwahrscheinlich hat er sie sich aus seinen Trainingsdaten zusammengereimt. Das ist kein Superpowers-spezifisches Problem.
Gelöst habe ich es mit dem Context7 MCP-Server, den du über die Claude-Plugins installieren kannst. Damit bekommt der Agent Zugriff auf aktuelle Dokumentation. Er hat sich die aktuelle Lexoffice-API-Dokumentation gezogen und den Fehler behoben. Mein Tipp: Wenn du externe APIs anbindest, gib dem Agenten immer aktuelle Docs.
Schwaches Tracking und schlanke Dokumentation
Framework-spezifisch ist mir das schwache Tracking von Aufgaben aufgefallen. Ich kenne es so, dass für jedes Feature eine ausführliche Spezifikation mit User Stories, Akzeptanzkriterien und Testdokumentation entsteht. In Superpowers ist das stark vereinfacht: Es gibt einen Plan und ein Design-Dokument, in denen alles steht. Egal, ob deine App 10 oder 200 Features hat.
Bei der Umsetzung bedient sich Claude aus diesen Dokumenten und aus der Git-History. Mir ist das zum einen zu unübersichtlich, weil ich mich in einer riesigen Plandatei bewegen muss. Zum anderen ist es mir nicht ausführlich genug, gerade wenn mehrere Personen an einem größeren Projekt arbeiten.
Das lässt sich anpassen. Wie Spezifikationen und Pläne geschrieben werden, steht in den Skill-Dateien. Du kannst die Arbeitsanleitungen dort an deine Bedürfnisse anpassen.
Superpowers vs. GSD: Wann nimmst du was?
Zum Vergleich habe ich Superpowers dem Framework GSD in Version 1 gegenübergestellt. Version 2 lasse ich bewusst weg, weil sie kein Claude-Code-Framework mehr ist, sondern eine eigene CLI-Anwendung. GSD 1 und Superpowers sind beides Prompt-Frameworks, die in Claude Code leben und mit deinem Abo laufen. Den ausführlichen Praxistest beider GSD-Versionen findest du in meinem Artikel GSD Framework für Claude Code.
| GSD (Version 1) | Superpowers | |
|---|---|---|
| Fokus | Dokumentation und Transparenz | Codequalität durch Test-Driven Development |
| Dokumentation | Ausführlicher Plan, Features in Phasen, mehrere Dokumente pro Feature | Ein Design-Dokument und ein Implementierungsplan |
| Kosten | Läuft mit dem Claude-Code-Abo | Läuft mit dem Claude-Code-Abo |
| Besonderheit | Codebase-Analyse aus mehreren Perspektiven, ein Gegenspieler-Agent prüft die Anforderungen auf Lücken | Erzwungenes TDD, Visual Companion schon in der Anforderungsphase |
| Ideal für | Bestehende Projekte und Teams mit Spec-Driven Development | Solo-Developer, die schnell und mit Fokus auf Codequalität entwickeln wollen |
GSD eignet sich vor allem für Brownfield-Projekte, also bestehende Software. Die Funktion zur Codebase-Analyse untersucht Bestandscode aus Sicht von Tech-Stack, Architektur, Compliance und möglichen Problemstellen. Auch die Anforderungsdokumente entstehen aus mehreren Perspektiven.
Einordnung: Für wen lohnt sich Superpowers?
Superpowers ist ein durchdachtes, leichtgewichtiges Framework. Die konsequente Durchsetzung von Test-Driven Development und die Kette aus Implementer, Spec Reviewer und Code Quality Reviewer heben die Codequalität spürbar. Der Visual Companion hilft, Designentscheidungen früh zu treffen. Ideal ist es aus meiner Sicht für Solo-Founder und Teams von ein bis zwei Personen.
Für größere Teams, die gewohnt sind, jedes Feature ausführlich zu spezifizieren, ist die Dokumentation zu schlank. Und das ist der eigentliche Punkt: Ein Framework ersetzt keinen durchdachten Entwicklungsprozess. Sobald du Software baust, die wachsen oder verkauft werden soll, brauchst du ein System, das jedes Feature nachvollziehbar durch Spezifikation, Architektur, Umsetzung und Prüfung führt. Ob du dafür Superpowers anpasst oder einen eigenen Ablauf baust, hängt von deinem Projekt ab. Welche Befehle dir im Alltag zusätzlich helfen, zeige ich in meinem Artikel über Claude Code Slash Commands.
