obra/superpowers: Ein Skills-Framework, das Coding-Agenten zu ingenieurmäßiger Disziplin zwingt

Hintergrund und Problemdefinition

Coding-Agenten können Code schreiben, überspringen aber häufig die Disziplin, die Softwareentwicklung verlangt. Sie beginnen mit der Umsetzung, bevor das Ziel klar ist. Sie erklären eine Aufgabe für erledigt, ohne Tests auszuführen. Sie ändern viele Dateien auf einmal, sodass sich das Ergebnis später kaum prüfen lässt. Das Problem liegt selten in der reinen Leistungsfähigkeit des Modells. Es fehlt eine verbindliche Arbeitsmethode, der der Agent tatsächlich folgt.

obra/superpowers setzt genau hier an. Das Projekt bezeichnet sich selbst als „eine vollständige Methode für die Softwareentwicklung für Ihre Coding-Agenten“. Es besteht aus einer Reihe kombinierbarer Skills und einigen Grundanweisungen, die sicherstellen, dass der Agent sie nutzt. Laut README werden die Skills automatisch ausgelöst, sodass Nutzer keine besonderen Befehle eingeben müssen.

Das Projekt stammt von Jesse Vincent und dem Team bei Prime Radiant. Es steht unter der MIT-Lizenz. Am 3. Oktober 2026 zeigte das GitHub-Repository 294.554 Sterne. Diese Zahl belegt großes Interesse in der Community, sagt aber nichts darüber aus, ob die Methode wirkt. Dieser Artikel stützt sich auf das README und die Struktur des skills-Verzeichnisses. Er enthält keinen unabhängigen Benchmark.

Architektonischer Kern und technische Prinzipien

Das Grundgerüst von Superpowers ist ein Ablauf aus sieben Schritten. Jeder Schritt ist als Skill umgesetzt und wird durch das Ergebnis des vorherigen Schritts aktiviert. Der erste Schritt, brainstorming, läuft, bevor Code entsteht. Er schärft eine grobe Idee durch Rückfragen, vergleicht Alternativen und legt das Design abschnittsweise zur Freigabe vor. Danach speichert er ein Design-Dokument. Nach der Freigabe erstellt using-git-worktrees einen isolierten Arbeitsbereich auf einem neuen Branch, führt die Projekteinrichtung aus und prüft, dass die Test-Basislinie sauber ist. writing-plans zerlegt die Arbeit anschließend in Aufgaben von jeweils zwei bis fünf Minuten. Jede Aufgabe nennt exakte Dateipfade, vollständigen Code und Prüfschritte.

Für die Ausführung gibt es zwei Wege. subagent-driven-development beauftragt für jede Aufgabe einen frischen Subagenten und prüft nach jeder Aufgabe. Das README nennt dies die gründlichste Variante. executing-plans bearbeitet alle Aufgaben inline in einer einzigen Sitzung und prüft den gesamten Branch erst am Ende einmal. Laut README ist das die günstigste Variante. In beiden Fällen erzwingt test-driven-development den Zyklus Rot, Grün, Refactoring: einen fehlschlagenden Test schreiben, das Scheitern beobachten, minimalen Code schreiben, den Erfolg beobachten und committen. Nach dem README wird Code gelöscht, der vor seinem Test entstanden ist. requesting-code-review läuft zwischen den Aufgaben und meldet Probleme nach Schweregrad. Kritische Befunde halten den Fortschritt an. finishing-a-development-branch prüft die Tests, bietet Zusammenführen, Pull Request, Behalten oder Verwerfen an und räumt den Arbeitsbereich auf. Auch der Ort der Vorgaben ist bedeutsam. Die Regeln stehen in Skill-Dateien und nicht in einem einzelnen Satz eines Prompts. Der Agent soll vor jeder Aufgabe prüfen, ob passende Skills existieren. Das README beschreibt sie als verbindliche Abläufe, nicht als Vorschläge. Eine Designentscheidung verdient besondere Beachtung. Die zweistufige Prüfung in subagent-driven-development kontrolliert zuerst die Übereinstimmung mit der Spezifikation und danach die Codequalität. Wer trennt, ob das Richtige gebaut wurde und ob es gut gebaut wurde, verhindert, dass Stilhinweise funktionale Fehler überlagern.

Praktische Bewertung und Anwendungen

Das Skill-Verzeichnis enthält derzeit fünfzehn Skills. Sie lassen sich in vier Gruppen ordnen. Die Testgruppe wird von test-driven-development geprägt. Zur Fehlersuche gehört systematic-debugging, ein vierphasiger Prozess zur Ermittlung der Ursache, ergänzt um Techniken wie Ursachenverfolgung, Verteidigung in der Tiefe und bedingtes Warten. verification-before-completion verlangt den Nachweis, dass ein Problem tatsächlich behoben ist. Die Kollaborationsgruppe umfasst Design, Planung, parallele Verteilung, das Anfordern und Annehmen von Code-Reviews sowie den Abschluss von Branches. Zu den Meta-Skills gehören writing-skills und using-superpowers. Die Installation hängt von der Plattform ab. Claude Code lässt sich über den offiziellen Plugin-Marktplatz von Anthropic oder den Marktplatz von Superpowers installieren. Für Antigravity wird agy plugin install mit der Repository-URL verwendet. Das README nennt mehr als ein Dutzend unterstützter Umgebungen, darunter Cursor, Codex CLI, Gemini CLI, OpenCode und Hermes Agent. Jede Umgebung benötigt eine eigene Installation. Bei der Bewertung ist in drei Punkten Sorgfalt geboten. Erstens zielt der Ablauf auf bekannte Fehlerbilder: übersprungene Tests, große ungeprüfte Änderungen und Erfolgsmeldungen ohne Nachweis. Ob diese Fehler tatsächlich seltener werden, lässt sich nur mit einem kontrollierten Vergleich auf realen Projekten mit und ohne das Framework feststellen. Dieser Artikel enthält keine solchen Daten. Zweitens behauptet das README, Agenten könnten zeitweise zwei Stunden lang selbstständig arbeiten, ohne vom Plan abzuweichen. Das ist eine Beschreibung des Projekts, die dieser Artikel nicht überprüfen kann. Drittens kostet ein schwerfälligerer Prozess mehr Token. subagent-driven-development startet für jede Aufgabe einen neuen Subagenten und ist damit teurer als executing-plans. Teams sollten die Methode an den Umfang der Aufgabe anpassen.

Zwei Grenzen sind ebenfalls wichtig. Das Projekt erklärt, neue Skills grundsätzlich nicht anzunehmen, und verlangt, dass jede Änderung an einem Skill bei allen unterstützten Coding-Agenten funktioniert. Superpowers ist daher eine meinungsstarke Methodik und kein offener Skill-Markt. Außerdem lädt der optionale visuelle Begleiter von brainstorming standardmäßig ein Logo von der Website von Prime Radiant, und diese Anfrage enthält die verwendete Superpowers-Version. Das README betont, dass der Anbieter weder Projektdetails noch Prompts oder Klicks sieht. Mit der Variable SUPERPOWERS_DISABLE_TELEMETRY auf einen wahren Wert lässt sich das abschalten. Organisationen sollten dies vor einem Rollout kennen.

Branchenauswirkungen und Ausblick

Die Bedeutung von Superpowers liegt weniger in einzelnem Code als in dem, was es als verteilbares Paket fasst. Ingenieursdisziplin lebte lange in den Gewohnheiten erfahrener Ingenieure und in Review-Checklisten. Hier werden diese Gewohnheiten als Skills ausgeliefert, zusammen mit dem Agenten installiert und vor jeder Aufgabe geprüft. Die Wirkung betrifft zwei Gruppen. Einzelne Entwickler erhalten Voreinstellungen für Regeln, die sie sonst selbst hätten erzwingen müssen. Teams erhalten einen gemeinsamen Ausgangspunkt, sodass die Agenten der Mitglieder dieselbe Reihenfolge einhalten und Reviews leichter übereinstimmen. Das Projekt wirft außerdem eine Frage auf, die sich über die Zeit beobachten lässt: Bleiben methodische Vorgaben nützlich, wenn Modelle besser werden? Ein heute unverzichtbarer Prozess kann mit einem stärkeren Modell unnötigen Aufwand bedeuten. Umgekehrt benötigen leistungsfähigere Agenten womöglich klarere Grenzen, damit autonome Arbeit beim Plan bleibt. Eine Antwort verlangt fortlaufende Daten, nicht eine einzelne Vorführung.

Die Größe der Community zeigt echten Bedarf. Sie belegt aber keine Qualität. Zu beobachten ist, ob unabhängige Teams die Vorteile in produktiven Repositories reproduzieren, ob die Review-Stufen echte Fehler finden und ob Verhaltensunterschiede zwischen den Umgebungen das Versprechen untergraben, dass eine Methode überall funktioniert. Im Rahmen dieses Artikels ist das Fazit klar. Superpowers bündelt eine gut strukturierte Ingenieursmethode mit expliziten Vorgaben. Die konzeptionelle Begründung ist tragfähig. Der praktische Nutzen muss noch unabhängig gemessen werden.