Superpowers zähmt Claude Code, aber es hat einen Preis

Superpowers ist ein Plugin für Claude Code von Jesse Vincent, der seit den 1990ern Open-Source-Entwicklertools veröffentlicht. Er hat es im Oktober herausgebracht, und weniger als ein Jahr später steht das Repository bei 280.000 Sternen und 25.000 Forks, mit dem letzten Push zwei Tage vor unserer Aufnahme. Das Projekt ist bereits bei seiner sechsten Major-Version mit 681 Commits auf dem Main-Branch, es handelt sich also nicht um eine Prompt-Sammlung, die jemand nach dem Launch-Hype liegen gelassen hat.

Signal	Wert
GitHub-Sterne	280.000
Forks	25.000
Major-Version	6
Commits auf main	681
Offene Issues	125

Vincents Wette passt in einen Satz: Was Coding-Agents fehlt, ist nicht Fähigkeit, sondern Disziplin. Diese Disziplin wird als schlichte Markdown-Dateien ausgeliefert, die jeder lesen, forken und anpassen kann. Wir haben das Plugin installiert, alle vierzehn Skills Zeile für Zeile gelesen und uns angesehen, was es an vier Fronten verändert: Produktivität, Code-Zuverlässigkeit, Token-Verbrauch und Dokumentation.

Superpowers ist ein kostenloses Open-Source-Plugin für Claude Code. Es liegt auf Anthropics offiziellem Plugin-Marketplace und wird mit einem einzigen Befehl installiert. Dieselbe Methodik gibt es für mehr als ein Dutzend andere Harnesses, darunter Cursor, Codex und Gemini, jeweils mit eigenem Installationsweg.

Der Kern sind vierzehn Skills: Markdown-Anleitungsdateien, die der Agent lädt, sobald eine Situation zu ihnen passt. Brainstorming, Planschreiben, Subagent-getriebene Entwicklung, testgetriebene Entwicklung und systematisches Debugging kodieren jeweils eine komplette Arbeitsweise, mit eigenen Checklisten und Leitplanken. Der Debugging-Skill verbietet jeden Fix-Vorschlag, bevor die Ursache isoliert ist. Ein Verifikations-Skill zwingt den Agent, zu beweisen, dass eine Aufgabe fertig ist, statt es nur zu behaupten. Jeder Skill meldet sich beim Laden, sodass du immer weißt, in welchem Modus der Agent gerade arbeitet.

Ein Hook beim Sessionstart zwingt Claude, vor jeder Aufgabe zu prüfen, ob einer dieser Skills zutrifft. Die Regel steht im Einstiegs-Skill: Besteht auch nur eine Chance von einem Prozent, dass ein Skill relevant ist, muss der Agent ihn laden. Das Ergebnis verhält sich weniger wie ein Werkzeugkasten und mehr wie eine Entwicklungsmethodik, die in den Agent injiziert wird.

Vincent beschreibt die Entstehung auf seinem Blog. Er hat die Skills aus 2.249 Markdown-Dateien mit Lektionen destilliert, die seine eigenen Agents gelernt hatten, und die Entwürfe dann an genau diesen Archiven auf die Probe gestellt. Die Methodik wurde aus echten Agent-Fehlern extrahiert und nicht am Reißbrett entworfen.

Brainstorming ist der Skill, durch den alles geht. Sobald du ein Feature anfragst, lädt Claude ihn und wird für die Dauer des Framing-Gesprächs zum Anforderungsexperten. Die ganze Methode passt in eine lesbare Datei.

Die Datei beginnt mit einer harten Sperre: kein Code, kein Gerüst, kein Implementierungs-Skill irgendeiner Art, bis du eine explizite Absicht abgesegnet hast. Nichts wird auf Verdacht gebaut, und die Sperre gilt für jede Aufgabe, egal wie klein sie aussieht. Anschließend sortiert der Skill jede Anfrage in einen von drei Pfaden.

Pfad	Definition	Ergebnis
Spike	Eine Machbarkeitsfrage	Eine Antwort, kein Code, den du behältst
Bounded	Eine kleine Änderung an einem Ablauf, der im Repo bereits existiert	Eine eng umrissene Änderung
Architektonisch	Alles, was die Struktur des Projekts umbaut	Eine Spec, die du abnimmst, dann ein Implementierungsplan

Der Agent nennt seine Einstufung ausdrücklich, damit du sie überschreiben kannst, und die Ratsche dreht nur in eine Richtung: Versteckte Komplexität, die mitten in einer Aufgabe auftaucht, stuft den Pfad hoch, nie umgekehrt. Die Datei liefert eine Tabelle mit Warnsignalen, Gedanken wie „das ist zu simpel, um ein Design zu brauchen", mit der Gegenrede direkt daneben: Gerade bei simplen Aufgaben kosten ungeprüfte Annahmen am meisten. Selbst ein Spike behält seine Leitplanke. Was der Agent zur Beantwortung der Frage baut, bleibt als Wegwerfcode markiert, und diesen Code zu behalten wird zu einer neuen Anfrage, die einzustufen ist.

Im Dialog stellt der Agent die Fragen, die ein Lead Engineer stellen würde, und präsentiert sein Design in verdaulichen Abschnitten. In unserer eigenen Pipeline hat diese Phase bereits Features gekillt, die wir umsonst gebaut hätten.

Der Skill zum Planschreiben beginnt mit einer Anweisung, die den Ton vorgibt: Schreib den Plan für einen fähigen Entwickler, der null Kontext zu deiner Codebasis hat und, in den Worten der Datei, fragwürdigen Geschmack.

Konkret wird die Arbeit in Aufgaben zerlegt, bei denen jeder Schritt zwei bis fünf Minuten dauert: den fehlschlagenden Test schreiben, ihn laufen lassen, um sicherzugehen, dass er scheitert, den minimalen Code schreiben, der ihn bestehen lässt, die Tests erneut laufen lassen, committen. Eine Aktion, eine Prüfung, und die Arbeit geht in häufigen Commits voran. Das ist der Zyklus der testgetriebenen Entwicklung, erzwungen durch einen weiteren Skill im Plugin, sodass jede Aufgabe ihren eigenen Testzyklus trägt.

Jede Aufgabe listet die exakten Dateien auf, die anzulegen oder anzufassen sind, bis hinunter zur Zeilennummer. Der Plan beginnt mit einem Pflicht-Header: das Ziel in einem Satz, die Architektur in zwei oder drei, der Tech-Stack, ein Link zur Spec und die globalen Projektregeln, wörtlich kopiert. Deckt die Spec mehrere unabhängige Subsysteme ab, verlangt der Skill getrennte Pläne, einen pro Subsystem, von denen jeder für sich testbare Software liefert.

Die Aufgabengröße ist der Kern des Zuverlässigkeitsarguments. Eine kurze Aufgabe bedeutet einen Agent, der seine Arbeit mit einem Context Window beendet, das noch größtenteils leer ist. Er erreicht nie den Moment, in dem die Session überläuft, der Agent den Faden verliert und Funktionen erfindet, die es nicht gibt. Keine Fünf-Minuten-Demo zeigt dieses Problem, aber in einem echten Projekt entscheidet es alles: Die Qualität eines Agents am Ende einer Session hat nichts mit seiner Qualität beim ersten Prompt zu tun. Weniger gesättigter Kontext bedeutet mechanisch weniger Halluzinationen und Code, der tut, was der Plan gesagt hat.

Bei der Ausführung isoliert ein eigener Skill die Arbeit in einem Git-Worktree, einer separaten Arbeitskopie des Repositorys, damit der Plan läuft, ohne dem in die Quere zu kommen, woran du nebenbei arbeitest.

Der ausführende Skill steuert die Entwicklung über Subagents. Sein Prinzip passt in eine Zeile der Datei: ein frischer Subagent pro Aufgabe, ein Review nach jeder Aufgabe und am Ende ein breites Review des gesamten Branches. Deine Hauptsession wird zum Orchestrator. Sie codet nicht mehr, sie verteilt. Jeder Subagent bekommt genau den Kontext, den seine Aufgabe braucht, und nie die History deiner Session, was Kontextverschmutzung vermeidet und dein eigenes Fenster für die Koordination frei hält.

Der Subagent kann vor dem Start Fragen stellen, dann implementiert, testet, committet und reviewt er seine eigene Arbeit. Ist er fertig, führt der Orchestrator ein zweiteiliges Review durch, zuerst Spec-Treue, dann Code-Qualität, mit einem eigenen Reviewer-Platz für jede Aufgabe. Nichts ist improvisiert: Der Skill liefert eine Prompt-Vorlage für jede Rolle (Implementierer, Aufgaben-Reviewer und der Reviewer, der Fixes nachprüft), die der Orchestrator mit dem Kontext der Aufgabe füllt.

Review-Ergebnis	Was passiert
Bestanden	Der Orchestrator trägt den Abschluss in ein Ledger ein und geht im Plan weiter
Gescheitert, Runden 1 bis 3	Der ursprüngliche Implementierer macht weiter, da er den Code und seine eigenen Entscheidungen bereits kennt
Gescheitert, Runde 4	Ein frischer Implementierer wird auf einem stärkeren Modell losgeschickt
Gescheitert, Runde 5	Eine Sicherung fliegt und der Orchestrator entscheidet jeden offenen Befund selbst

Der Skill vermeidet auch das gegenteilige Extrem: Ein Schwung winziger mechanischer Aufgaben geht als ein gebündelter Dispatch raus und wird als eine Einheit reviewt. Nichts wird gemergt, ohne einen Reviewer bestanden zu haben. Das Ergebnis ist, was ein menschliches Team einen Code-Review-Prozess nennt, nur läuft er von selbst, Aufgabe für Aufgabe.

Das Verteilsystem öffnet die Tür zu einem dritten Gewinn: Token-Ökonomie. Der Skill hat einen Abschnitt zur Modellwahl, der mit einer Regel beginnt: Nimm das schwächste Modell, das die jeweilige Rolle bewältigen kann. Der Orchestrator schätzt die Schwierigkeit jeder Aufgabe im Plan ein und weist das passende Modell zu.

Aufgabe	Modellstufe
Klar spezifizierte mechanische Aufgabe an ein oder zwei Dateien, oder ein Plan, der den zu schreibenden Code bereits enthält	Die billigste Stufe (Implementieren wird zu Abtippen plus Testen)
Koordination über mehrere Dateien, Debugging	Ein Standardmodell
Architektur, das finale Branch-Review	Das stärkste verfügbare Modell

Die Datei ergänzt zwei Feinheiten. Erstens: Nenn beim Verteilen immer explizit das Modell. Ein Subagent ohne Angabe erbt das Modell deiner Session, oft das teuerste, was den ganzen Abschnitt still aushebelt. Zweitens: Die Anzahl der Turns schlägt den Token-Preis. Die billigsten Modelle brauchen bei vielschrittiger Arbeit mehr Turns und kosten am Ende insgesamt mehr, weshalb Reviewer und Implementierer, die von Prosa aus arbeiten, eine Stufe höher starten statt beim Billigsten.

Dieses Setup macht etwas Kontraintuitives möglich: Opus oder Fable, die teuersten Modelle im Katalog, auf dem 20-Dollar-Pro-Plan zu fahren. Das teure Modell arbeitet nur an den wenigen Entscheidungen, die es verdienen, und der Rest des Plans läuft auf Modellen, die einen Bruchteil deiner Quota verbrauchen.

Der letzte Gewinn ist der, an den beim Installieren des Plugins niemand denkt. Specs und Pläne sind keine Chat-Nachrichten, die mit dem Ende der Session verschwinden. Es sind Markdown-Dateien, die im Repository gespeichert und zusammen mit der Arbeit committet werden. Der Skill legt den Ort fest: ein datierter Plans-Ordner, eine Datei pro Feature, mit dem Ziel, der Architektur und dem Link zur Spec im Header.

Die Spec reist mit dem Plan, und Konflikte zwischen beiden werden zugunsten der Spec aufgelöst: Das Dokument ist die Autorität, nicht das Gedächtnis des Agents. Die Git-History sagt dir nicht mehr nur, was sich geändert hat. Sie sagt dir, warum, und was der Agent damals entschieden hatte. Sechs Monate später reicht es, die Plan-Datei in einem Prompt zu erwähnen, und der Agent nimmt den Kontext des ursprünglichen Features sofort wieder auf, und ein neues Feature im selben Subsystem baut auf der bestehenden Spec auf, statt das Terrain neu zu entdecken.

Es gibt keine unverfolgte Aufgabe mehr: Alles, was ein Agent an der Codebasis gemacht hat, hat ein Dokument hinterlassen, vom ersten Brainstorm bis zum letzten Commit. Das Projekt fasst seine Philosophie in zwei Prinzipien zusammen: systematisch statt ad hoc und Belege statt Behauptungen. Dokumentation fällt von selbst aus dem Prozess.

Die Grenze ist real, und das Repository wirbt nicht damit: All diese Disziplin hat einen Fixpreis, und dieser Preis schaltet sich nie ab. Der Einstiegs-Skill ist deutlich. Beim kleinsten Zweifel muss der Agent den Skill laden, und die Brainstorming-Datei stellt klar, dass die Zeremonie mit der Aufgabe skaliert, die menschliche Freigabe aber nie.

Bei einem Fix von zwei Zeilen heißt das: Framing-Fragen beantworten, ein Design aus zwei Sätzen absegnen und dann den vollen Zyklus abwarten, bevor du den Fix siehst. Bei einem Tippfehler in einer Config-Datei ist der komplette Prozess schlicht langsamer, als ihn selbst zu beheben. Die Orchestrierung selbst verbraucht Tokens: Dispatch-Briefings, zwei Reviews pro Aufgabe und das Ledger werden jedes einzelne Mal bezahlt, und das spürst du am stärksten bei den kleinsten Aufgaben.

Es gibt auch das umgekehrte Symptom, und es beantwortet die Reddit-Frage direkt. Zeigt deine Nutzungsstatistik das Plugin bei ein paar Prozent, lösen deine Anfragen fast nie die Skills aus, du zahlst also jede Session den Einstiegs-Check, ohne je an die Gewinne zu kommen. Eine Fix-Schleife über die vollen fünf Runden sind fünf Diffs, fünf weitere Reviews und ein Schiedsspruch, für eine Aufgabe, die Minuten dauern sollte. Das Projekt steht außerdem nie still: Es ging in unter einem Jahr von einer ersten Version zu einer sechsten und hat noch 125 offene Issues, die Skills, die du heute liest, werden beim nächsten Update also anders sein.

Das Plugin plant seinen eigenen Ausstieg. Seine Anweisungen stellen deine Vorgaben über die Skills, du kannst dem Agent also explizit sagen, den Prozess zu überspringen. Unsere Regel: Superpowers standardmäßig an für jede Feature-Arbeit und ein bewusster Skip für winzige Fixes.

Deine Nutzung von Claude Code	Urteil
Features, die Stunden dauern	Installieren: Das Framing hält dich davon ab, das Falsche zu implementieren, kurze Aufgaben halten den Agent von der Kontextsättigung fern, die Modellwahl streckt deine Quota, und du erbst Dokumentation, die du selbst nie geschrieben hättest
Wegwerf-Skripte und kleine Fixes	Weitergehen: Du würdest den Fixpreis des Prozesses für Aufgaben zahlen, die ihn nicht brauchen
Dazwischen	Installieren und lernen, Skip zu sagen: Ein Satz in deinem Prompt gibt dir die Kontrolle zurück

Wenn du es testen willst, ohne alles zu übernehmen, lass nur den Brainstorming-Skill ein paar Tage laufen. Er bringt den Großteil des Gewinns, und die anderen Skills docken danach ganz natürlich an. Das Plugin hält seine vier Versprechen, solange du ihm Features gibst, die seine Zeremonie wert sind. Es läuft jetzt auf unseren eigenen Projekten, und die Brainstorming-Phase ist die, die wir nicht mehr abschalten würden. Das Repository ist kostenlos und Open Source, mit 280.000 Leuten vor dir in der Schlange.