Superpowers bringt Claude Code bei, wie ein kleines Team zu arbeiten: erst Design, dann Plan, dann isolierte Umsetzung und ein Review, das nicht vom Autor selbst kommt. Was die Skills wirklich tun, was das Muster in einem echten Release gefunden hat und wann es Overkill ist.
Die meisten Fehler eines Coding-Agenten sind Prozessfehler, keine Intelligenzfehler. Er programmiert los, bevor das Ziel klar ist. Er prüft seine Arbeit im selben Kontext, in dem er sie gebaut hat. Und er meldet „fertig", ohne etwas ausgeführt zu haben. Ein Team fängt das mit Rollen ab: Jemand klärt, jemand plant, jemand baut, jemand anderes reviewt.
Das Open-Source-Framework Superpowers von Jesse Vincent überträgt diese Rollen auf Claude Code. Es ist im offiziellen Claude-Plugin-Marktplatz gelistet; die Plugin-Seite zählt über eine Million Installationen (Stand Oktober 2026). Ich nutze es seit Februar 2026, aktuell in Version 6.4.1.
Was die Skills wirklich tun
Superpowers besteht aus Skills: Markdown-Dateien, die Claude automatisch lädt, wenn die Situation passt. Fünf bilden den Kern-Workflow, so wie sie in den SKILL.md-Dateien stehen:
Claude ordnet die Anfrage zuerst ein: Spike (Machbarkeitsfrage, Code wird weggeworfen), Bounded (klar umrissene Änderung an bestehendem Code) oder Architectural (neues System, neue Schnittstellen). Je nach Pfad reicht ein kurzes Design im Chat, oder es entsteht eine Spec unter docs/superpowers/specs/. Ein hartes Gate verbietet jede Implementierung vor meiner Freigabe. Im Zweifel gilt der schwerere Pfad.
writing-plans schreibt für einen Entwickler ohne Projektkontext und mit „fragwürdigem Geschmack". Jeder Task nennt exakte Dateipfade, Schnittstellen zu den Nachbar-Tasks und Schritte von 2–5 Minuten, beginnend mit einem fehlschlagenden Test. „TBD" gilt als Planfehler. Ein Abschnitt „Review Focus" listet die fünf wahrscheinlichsten Fehlerfälle, die noch kein Test abdeckt.
subagent-driven-development startet pro Task einen frischen Subagenten, der nie die Session-Historie erbt, sondern genau den Kontext bekommt, den er braucht. Nach jedem Task prüft ein Reviewer Spec-Treue und Code-Qualität. Eine Ledger-Datei hält den Fortschritt fest, damit nach einer Kontext-Komprimierung nichts doppelt läuft.
Alternativ: executing-plans. Claude setzt selbst um, reviewt wird erst am Ende. Billiger, aber ohne Zwischen-Gates.
requesting-code-review gibt dem Reviewer präzisen Kontext statt des Gesprächsverlaufs. Critical wird sofort behoben, falsche Einwände werden begründet zurückgewiesen. verification-before-completion verbietet jede Erfolgsmeldung ohne frisch ausgeführten Prüfbefehl. „Der Agent hat Erfolg gemeldet" zählt nicht, der Diff zählt.
finishing-a-development-branch verifiziert die Tests und bietet drei Optionen an: lokal mergen, Pull Request oder Branch behalten. Verworfen wird nur auf ausdrücklichen Wunsch.
RED-GREEN-REFACTOR
test-driven-development formuliert ein eisernes Gesetz: kein Produktivcode ohne vorher fehlschlagenden Test. Code, der vor dem Test entstand, wird gelöscht, nicht als „Referenz" behalten. Ausnahmen wie Wegwerf-Prototypen gibt es nur nach Rückfrage beim Menschen.
Ein echter Lauf: der SEO-Release von waiser.dev
Am 6. Oktober 2026 habe ich dieses Muster an meiner eigenen Website durchgezogen. Anlass war die Google Search Console: Die indexierten Seiten waren von 60 auf 40 gefallen, „Gecrawlt – zurzeit nicht indexiert" von 9 auf 29 gestiegen, dazu kamen 404-Fehler auf merkwürdigen /blog/blog/-URLs.
Zur Einordnung: Ich habe nicht das Superpowers-Plugin laufen lassen, sondern die Workflow-Orchestrierung von Claude Code, die ich schon in früheren Läufen mit mehreren parallelen Agents genutzt habe. Das Muster war dasselbe: planen, Plan prüfen, isoliert umsetzen, Änderungen prüfen. 13 Agent-Läufe:
- Plan-Team (3 + 1): Drei Spezialisten für technisches SEO, On-Page-Hygiene und Static-Site-Engineering schlugen 22 Tasks vor und prüften ihre Behauptungen am Code und im Browser. Ein Lead-Agent machte daraus einen Release mit zwei Arbeitspaketen und zehn Tasks.
- Plan-Review (2): ein Reviewer für Engineering-Risiken, einer als SEO-Skeptiker. Beide: „approve with changes".
- Revision (1): Von 16 Review-Punkten übernahm der Lead 13, einen teilweise, zwei lehnte er begründet ab.
- Umsetzung (2): zwei Implementierer auf strikt getrennten Dateien, also ohne Konflikte.
- Change-Review (3): Plan-Konformität, SEO-Verifikation, Funktion im Browser.
- Fix (1): ein Fixer für die berechtigten Funde.
Live ging alles als ein einziger Release-Commit.
Was die Reviewer gefunden haben (Auswahl)
- Ein Generator, der halbe Arbeit hinterlässt. Ein neues Skript schreibt die Post-Links statisch in die drei Blog-Indexseiten. Beide Plan-Reviewer reproduzierten unabhängig: Fehlte in einer Datei eine Markierung, schrieb es die anderen beiden trotzdem und meldete den Fehler erst danach. Jetzt gilt alles oder nichts. Gefunden, bevor das Skript im Repository lag.
- Ein Release-Skript mit falscher Reihenfolge. Der Generator lief erst, nachdem ein Post schon als „veröffentlicht" markiert war. Schlug er fehl, wäre der Release halb fertig liegen geblieben. Reihenfolge getauscht, Fehlerfall getestet.
- Ein unvollständiger Fix. Die Ursache der
/blog/blog/-404s, ein fehlender Basispfad-Fall für die chinesischen Seiten, hatte ich in der Hauptsession mit Claude gefunden; zwei Planer kamen parallel auf dieselbe Ursache. Die Plan-Reviewer zeigten dann, dass 404-Seiten unter verschachtelten Pfaden weiter auf/blog/blog/verlinkten.<base href="/">schloss die Lücke. - Ein alter Mobile-Bug. Bei 390 px Breite liefen die Footer-Links bis x = 626 px. GitHub, LinkedIn und E-Mail waren abgeschnitten und nicht erreichbar. Der Fehler war älter als der Release, aufgefallen ist er erst dem Funktions-Reviewer.
- Ein vergessener Nebeneffekt. Das Release-Skript erzeugt die Indexseiten neu, hob ihr
lastmodin der Sitemap aber nie an. Behoben, mit der Regel „nie rückwärts".
Der wertvollste Fund war unbequem. Der SEO-Skeptiker widersprach der Kernannahme des Plans: Statische Links würden die Indexierung nicht zurückbringen. 18 der 28 nicht indexierten Post-URLs hatten schon drei oder mehr statische Links; das Muster folgte dem Alter der Posts, nicht ihrer Verlinkung. Der eigentliche Hebel sei eine inhaltliche Prüfung der dünnen älteren Artikel. Auf seiner Liste stand auch dieser hier, damals rund 500 Wörter lang. Der Lead übernahm die Korrektur, lehnte die Content-Prüfung als Agent-Task aber ab: Ob ein Artikel überarbeitet oder zurückgezogen wird, ist eine redaktionelle Entscheidung. Die Frage kam zu mir. Diese Überarbeitung ist meine Antwort.
Auch der Fixer kannte seine Grenzen. Zwei berechtigte Funde ließ er bewusst liegen: eine Textänderung in einem anderen Artikel, die der freigegebene Plan ausgeschlossen hatte, und eine Änderung an der Projekt-Anleitung für Agents, die nur ich freigeben kann. Beide landeten mit Begründung bei mir.
Was sich wirklich ändert
- Getrennter Kontext ist eine echte zweite Meinung. Ein Reviewer, der die Überlegungen des Implementierers nie gesehen hat, teilt auch dessen blinde Flecken nicht.
- Review vor dem Code ist am billigsten. Drei der fünf Fehler oben wurden am Plan und an einem Referenzskript gefunden, nicht im Produktivcode.
- Rollen schlagen Masse. Risiko-Reviewer, Skeptiker und Funktionstester fanden verschiedene Dinge. Dieselbe Idee wie bei Multi-Agent-Teams mit CrewAI.
- Beweise statt Erfolgsmeldungen. Implementierer, Reviewer und Fixer lieferten ihre Prüfbefehle mit: Exit-Codes, Prüfsummen, Messungen im Browser.
- Der Mensch bleibt Owner von Ziel und Wortwahl. Agents liefern Befunde und Optionen. Was veröffentlicht wird, entscheide ich.
„Evidence before claims, always." – Kernprinzip von verification-before-completion
Was es kostet
Laut der Claude-Code-Dokumentation startet jeder Subagent (außer einem Fork) mit frischem Kontext, braucht Zeit zum Einlesen, und seine Anfragen zählen auf dieselben Nutzungslimits wie die Hauptsession. 13 Agent-Läufe heißen: 13-mal den Code neu lesen. Superpowers sagt selbst: Subagent-getrieben kostet einen frischen Kontext pro Task und Review, nativ ist billiger und schneller.
Dazu kommt Review-Rauschen. Zwei Punkte wurden abgelehnt, mehrere waren Kleinigkeiten. Jemand muss jeden Fund bewerten, statt ihn blind umzusetzen. Dafür gibt es den Skill receiving-code-review: erst gegen den Code prüfen, dann umsetzen, Widerspruch technisch begründen statt höflich zuzustimmen. Und Reviewer finden vor allem, wonach sie suchen sollen. Den Footer-Bug fand nur der Reviewer, der im Browser in Mobile-Breite gemessen hat.
Wann es sich lohnt – und wann nicht
Es lohnt sich, wenn ein Fehler teuer ist und öffentlich wird. Meine Website geht direkt von main live; ein halb geschriebenes Skript landet sofort bei allen Besuchern. Ebenso bei Skripten, die später unbeaufsichtigt laufen, und bei Änderungen über viele Dateien.
Es ist Overkill:
- bei einem Ein-Datei-Fix oder einer Textkorrektur. Dafür sieht Superpowers selbst den Bounded-Pfad vor: kurzes Design im Chat, keine Spec, kein Plan.
- bei Machbarkeitsfragen. Der Spike-Pfad liefert eine Antwort, keinen Code, den man behält.
- bei eng gekoppelten Aufgaben. Der Skill empfiehlt Subagenten nur für weitgehend unabhängige Tasks.
- wenn Latenz zählt. Für eine schnelle Rückfrage ist die Hauptsession besser.
- bei redaktionellen Entscheidungen. Die gehören zu einem Menschen.
So setze ich es ein
# Aus dem offiziellen Claude-Marktplatz installieren
/plugin install superpowers@claude-plugins-official
# Alternativ: eigener Marktplatz von Superpowers
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace- Einordnung prüfen. Claude sagt zu Beginn, ob es Spike, Bounded oder Architectural sieht. Stimmt das nicht, sofort korrigieren.
- Spec und Plan wirklich lesen. An den Freigabe-Gates trage ich am meisten bei. Wer sie durchwinkt, bekommt sauber umgesetzte falsche Anforderungen.
- Umsetzungsart bewusst wählen. Viele unabhängige Tasks und teure Fehler: subagent-getrieben. Wenige, gekoppelte Tasks: nativ, mit Review am Ende.
- Reviewern verschiedene Rollen geben. Mindestens einer darf die Grundannahme angreifen.
- Prüfbefehle verlangen. Wie man solche Abschlussbedingungen formuliert, habe ich bei
/goalin Loops statt Prompts beschrieben.
Ich nutze das Muster inzwischen auch in anderen Projekten.
Eigene Skills schreiben
writing-skills behandelt neue Skills als testgetriebene Entwicklung: Erst arbeitet ein Subagent ohne den Skill, und man notiert, mit welchen Ausreden er die Regel umgeht. Dann schreibt man den Skill gegen genau diese Ausreden und prüft erneut. Den Aufbau von Skills beschreibe ich in Anthropics Skills-Blueprint.
Fazit
Superpowers macht ein Modell nicht klüger. Es nimmt ihm die Abkürzungen: kein Code vor dem Design, kein Review im eigenen Kontext, kein „fertig" ohne Beweis. In meinem SEO-Release fanden getrennte Rollen die fünf Fehler oben, drei davon schon im Plan, und legten eine falsche Grundannahme offen. Der Preis sind Zeit, Tokens und die Pflicht, jeden Fund selbst zu bewerten. Für einen Tippfehler lohnt sich das nicht. Für alles, was unbeaufsichtigt läuft oder direkt live geht, schon.
Verwendete Tools:
Interessiert an KI-gestützten Entwicklungsworkflows für dein Team? Schreib mir. Ich helfe bei der Implementierung maßgeschneiderter Lösungen.