Claude Code Skills mit Superpowers: Einrichtung und Praxis

Was steckt hinter Claude Superpowers?

Superpowers ist Jesse Vincents Sammlung von Skills für die Softwareentwicklung samt Anweisungen, die einen Coding-Agenten zu ihrer Nutzung anhalten. In Anthropics Claude Code, dem Programmierassistenten, der mit dem eigenen Repository arbeitet, liefert sie Abläufe zum Klären von Anforderungen, Planen von Änderungen, Testen, Debuggen, Delegieren und Abschließen eines Entwicklungsbranches. Das lässt sich mit dem Betriebshandbuch einer Werkstatt vergleichen: Die Werkzeuge sind vorhanden; das Handbuch legt fest, in welcher Reihenfolge gearbeitet und was vor der Übergabe geprüft wird. README von Superpowers

Geprüft am 18. Oktober 2026: Das Manifest im Quellcode nennt Version 7.0.0. Das Repository enthält 15 Skill-Verzeichnisse auf der obersten Ebene, jeweils mit einer Datei namens SKILL.md. Diese Angaben beziehen sich auf den für diesen Artikel geprüften Quellstand. Welche Revision der gewählte Marketplace installiert, muss gesondert geprüft werden. Plugin-Manifest, Skill-Verzeichnis

Der praktische Nutzen liegt in einer nachvollziehbaren Abfolge von Entscheidungen. Bevor Claude ein Feature ändert, kann es dessen gewünschtes Verhalten klären. Bevor es die Arbeit für abgeschlossen erklärt, kann es ein frisches Testergebnis verlangen. Diese Anweisungen liefern konkrete Prüfpunkte. Sie belegen allerdings noch nicht, dass Anforderungen oder Tests richtig sind.

Wie lässt sich Superpowers in Claude installieren?

Die Installation erfolgt innerhalb von Claude Code über einen der Wege aus der Projekt-README. Die folgenden Befehle sind unverändert aus deren Abschnitt zu Claude Code übernommen. Es handelt sich um interaktive Slash-Befehle, nicht um Befehle für eine gewöhnliche Shell. Installationsanleitung in der README

Claude Superpowers über den offiziellen Marketplace installieren

/plugin install superpowers@claude-plugins-official

Der Entwickler dokumentiert außerdem einen eigenen Marketplace. Für diesen Installationsweg wird er zunächst registriert und anschließend das Plugin installiert:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Sinnvoll ist eine Quelle, deren Stand sich im Blick behalten lässt. Beide Wege als aufeinanderfolgende Einrichtungsschritte für dasselbe Plugin zu nutzen, bringt keinen Vorteil.

Nach der Installation wird eine neue Claude-Code-Sitzung gestartet, damit der Start-Hook ausgeführt wird. Als erste Aufgabe eignet sich eine klar begrenzte Feature-Anfrage, etwa ein zusätzlicher Filter für eine vorhandene Aufgabenliste. Beobachten lässt sich dann, ob Claude einen passenden Skill ankündigt und dessen Vorgaben befolgt. Ein erfolgreich abgeschlossener Installationsbefehl zeigt etwas anderes als ein Workflow, der sich tatsächlich wie erwartet verhält.

Was ändert sich nach der Installation in einer Sitzung?

Zuerst ändert sich der Kontext: Ein Start-Hook fügt die Nutzungsanweisungen von Superpowers in die Unterhaltung ein. Der konfigurierte Matcher für SessionStart erfasst startup, clear und compact. Sein Skript liest using-superpowers, fügt den Text ein und weist Claude an, weitere Skills über das Tool Skill zu laden. Es kopiert also nicht den vollständigen Inhalt sämtlicher Skills in die Startnachricht. Hook-Konfiguration, Startskript

Wie wählt Claude einen Superpowers-Skill aus?

Claude gleicht die Aufgabe mit den Skill-Beschreibungen ab und liest anschließend die passenden Anweisungen. Laut Autorenleitfaden des Plugins sollen die Beschreibungen erkennen lassen, wann ein Skill zum Einsatz kommt. Die Startanweisung verlangt vom Agenten, dies vor einer Antwort oder Aktion zu prüfen, den Skill anzukündigen und Prozess-Skills vor Implementierungs-Skills anzuwenden. Hinweise zur Skill-Auswahl

Eine Aufforderung, etwas zu entwickeln, verweist damit auf brainstorming; ein fehlgeschlagener Test auf systematic-debugging. Anschließend kann ein fachspezifischer Skill die Umsetzung anleiten. Ein Skill lässt sich auch ausdrücklich beim Namen anfordern, etwa: „Nutze superpowers:systematic-debugging, um diesen Fehler zu untersuchen, bevor du eine Korrektur vorschlägst.“ Nutzungsanweisungen

Die automatische Auswahl ist eine Anweisung an das Modell, kein deterministischer Schalter für Schlüsselwörter. Der Hook liefert den Starttext; der Agent muss die Situation weiterhin erkennen und die ausgewählten Anweisungen befolgen. Wählt er den falschen Workflow, hilft es, den Aufgabenumfang klarzustellen oder den passenden Skill direkt anzufordern.

Claude Code Skills: Wann greifen welche Superpowers-Skills?

Die Sammlung deckt den gesamten Entwicklungszyklus ab. Eine Sitzung sollte jedoch die Skills laden, die zur anstehenden Arbeit passen. Die Namen in der folgenden Tabelle entsprechen exakt den geprüften Dateien. Die Einsatzfälle fassen deren Beschreibungen und Anweisungen sinngemäß zusammen. Sie sind keine Zusage, dass ein bestimmter Satz immer einen bestimmten Skill-Aufruf auslöst. Aktuelles Skill-Verzeichnis

Die Liste muss niemand auswendig kennen. Bei gewöhnlicher Feature-Arbeit zählen die Übergänge: verstandene Anforderung, bei Bedarf ein konkreter Plan, getestete Implementierung, geprüfte Änderung und Integrationsentscheidung. Bei einem Fehler ist die Untersuchung der sinnvolle Einstieg, nicht ein Entwurfsgespräch über ein neues Feature.

Wie ergänzt Superpowers den Planungsmodus und eigene Skills?

Superpowers gibt der Planung einen Ablauf vor. Sein Skill writing-plans ist etwas anderes als der native Planungsmodus von Claude Code. Die aktuelle Startanweisung verlangt ausdrücklich, vor dem Wechsel in den Planungsmodus brainstorming aufzurufen, sofern das noch nicht geschehen ist. Sie legt damit eine Reihenfolge fest, statt den nativen Modus und den eigenen Skill zum Schreiben von Plänen als austauschbar zu behandeln. Aktuelle Planungsanweisung

writing-plans erstellt ein Dokument im Repository, üblicherweise unter docs/superpowers/plans/, das Umsetzungsentscheidungen und Prüfungen festhält. Bei der Übergabe fordert der Skill dazu auf, den Plan zu prüfen und eine Vorgehensweise für die Umsetzung zu wählen, sofern diese nicht bereits vorgegeben wurde. Allein die Auswahl eines Modus liefert weder dieses Dokument noch die darin enthaltenen Arbeitsanweisungen. Die Steuerelemente und das Verhalten der Plattform beschreibt der separate Leitfaden zum Planungsmodus von Claude Code.

Eigene Skills bleiben Teil des Systems. Die Datei writing-skills des Plugins nennt ~/.claude/skills/ als Verzeichnis für persönliche Skills in Claude Code. Die Startanweisung stellt Nutzeranweisungen, einschließlich CLAUDE.md und direkter Aufforderungen, ausdrücklich über Skill-Anweisungen. Ein projektspezifischer Skill kann deshalb die eigenen Konventionen festhalten, während Superpowers den Entwicklungsprozess liefert. Wenn beide Vorgaben für Tests oder Reviews machen, sollte die Zuständigkeit klar geregelt sein. Datei zum Verfassen von Skills, Rangfolge der Anweisungen

Das zugrunde liegende Konzept solcher Anweisungsdateien erklärt der Artikel über Agent Skills. Superpowers ist eine darauf aufbauende Sammlung mit klaren Vorstellungen vom Arbeitsablauf.

Superpowers in Claude Code: Ein Feature von der Idee bis zum Merge

Ein Schalter „Erledigte ausblenden“ reicht aus, um den gesamten Ablauf zu zeigen. Das folgende Beispiel ist aus den Skill-Dateien abgeleitet und keine aufgezeichnete Testsitzung. Dateinamen, Abnahmefälle und Ergebnis sind hypothetisch.

Ausgangspunkt ist eine vorhandene Aufgabenlisten-App mit Tests. Gewünscht ist ein Schalter, der erledigte Einträge ausblendet, ohne sie zu löschen. Für dieses Beispiel verlangt der Nutzer ausdrücklich einen schriftlichen Plan und Aufgaben-Reviews durch Subagenten. Eine so kleine Änderung käme andernfalls für den kürzeren Weg infrage, bei dem die Abstimmung im Chat bleibt.

Das Verhalten klären: brainstorming

Die zentrale Frage lautet: Betrifft „Ausblenden“ nur die aktuelle Ansicht oder verändert es die gespeicherten Aufgaben? Im Beispiel wird ein reiner Ansichtsfilter vereinbart. Der Schalter ist anfangs aus; nach dem Ausschalten erscheinen erledigte Einträge wieder. Bleibt die gefilterte Liste leer, zeigt sie an, dass keine offenen Aufgaben vorhanden sind.

Claude fasst diesen Umfang zusammen und holt die Zustimmung ein. Weil der Nutzer den schriftlichen Weg gewählt hat, wird der Entwurf in einem Dokument unter docs/superpowers/specs/ festgehalten und vor der Übergabe aus Umsetzungssicht geprüft. Beim üblichen Weg für kleine Änderungen erlaubt der Skill, Beschreibung und Einigung im Chat zu belassen. Brainstorming-Regeln

Entscheidend ist die Vereinbarung über das Verhalten. Tauchen darin unbemerkt gespeicherte Einstellungen oder Änderungen an der Aufgabenspeicherung auf, ist der Funktionsumfang bereits gewachsen, bevor die Implementierung überhaupt beginnt.

Die Arbeit prüfbar machen: writing-plans

Der Plan zerlegt das Feature in unabhängig prüfbare Ergebnisse. Eine Aufgabe implementiert eine Filterfunktion in der beispielhaften Datei src/tasks/filterTasks.ts, samt Tests für gemischte, leere und vollständig erledigte Listen. Eine weitere bindet einen barrierefreien Schalter in src/tasks/TaskList.tsx ein, verwendet dabei die vereinbarte Funktionsschnittstelle und testet das sichtbare Ergebnis.

Der Plan benennt Dateien, Schnittstellen, Testaussagen, die Testbefehle des Projekts und die erwarteten Ergebnisse. Er hält außerdem fest, dass die zugrunde liegende Aufgabensammlung beim Filtern unverändert bleiben muss. Der Nutzer prüft den Plan und bestätigt die Umsetzung mit Subagenten. Aus einer vagen Anweisung wird damit eine Grundlage, über die sich Implementierer und Reviewer präzise verständigen können, auch wenn sie zu unterschiedlichen Einschätzungen kommen. Anweisungen zum Schreiben von Plänen

Den Arbeitsbereich einrichten: using-git-worktrees

Zu Beginn der Umsetzung prüft Claude, ob die Arbeit bereits isoliert erfolgt. Ein Git-Worktree ist ein weiteres Arbeitsverzeichnis für das Repository, meist auf einem eigenen Branch. Der Skill bevorzugt den nativen Worktree-Mechanismus der Plattform und berücksichtigt bereits geäußerte Nutzerpräferenzen. Andernfalls fragt er vor dem Anlegen nach.

Im Beispiel stimmt der Nutzer einem Worktree für das Feature zu. Claude führt darin die vorhandenen Projekttests aus, bevor es die Anwendung ändert. Schlagen bereits diese Tests fehl, muss zunächst der Ausgangszustand geklärt werden. Erst dann lassen sich spätere Fehler dem neuen Schalter zuordnen. Anweisungen zum Arbeitsbereich

Die Aufgaben umsetzen: subagent-driven-development und test-driven-development

Der steuernde Agent setzt einen neuen Implementierungsagenten für die Filteraufgabe ein und veranlasst anschließend deren Review. Erst nach diesem Prüfpunkt folgt die UI-Aufgabe. Der aktuelle Subagenten-Skill prüft im Aufgaben-Review sowohl die Einhaltung der Spezifikation als auch die Codequalität. Danach verlangt er ein umfassenderes Review des fertiggestellten Branches. Fortschritt und Entscheidungen hält er zudem in einem zum jeweiligen Plan gehörenden Protokoll fest. Subagenten-Workflow

Innerhalb der Implementierung liefert test-driven-development den Rot-Grün-Refactoring-Zyklus. Hier zeigt zunächst ein Test, dass die angeforderte gefilterte Ansicht weiterhin eine erledigte Aufgabe zurückgibt. Erst nachdem dieses Fehlschlagen beobachtet wurde, ergänzt der Implementierer das Filterverhalten, führt den Test erneut aus und räumt den Code auf, während die Tests erfolgreich bleiben. TDD-Anweisungen

Bei der UI-Aufgabe muss die aussagekräftige Prüfung erfassen, was nach Betätigung des Schalters sichtbar ist. Ein Test, der lediglich den Aufruf einer Funktion prüft, würde das sichtbare Verhalten des Features nicht belegen.

Die Alternative heißt executing-plans: Claude setzt den Plan selbst in der laufenden Sitzung um. Sind Subagenten verfügbar, übernimmt am Ende ein neuer Reviewer die Prüfung des gesamten Branches. Dieser Weg eignet sich, wenn Übergaben nach jeder einzelnen Aufgabe nicht zur gewünschten Review-Struktur passen. Anweisungen zur Umsetzung in der laufenden Sitzung

Befunde bearbeiten: Review-Skills und systematic-debugging

Beim abschließenden Branch-Review regelt requesting-code-review die Übergabe an den Reviewer. Angenommen, dieser stellt fest, dass erledigte Aufgaben nach dem Ausschalten des Schalters nicht wieder erscheinen. Dann verlangt receiving-code-review, den Befund zuerst anhand des Codes und des beabsichtigten Verhaltens zu prüfen, bevor etwas geändert wird. Review anfordern, Feedback entgegennehmen

Lässt sich der Fehler reproduzieren, führt systematic-debugging durch die Untersuchung. Die Phasen reichen von der Ursachenanalyse über die Musteranalyse und das Prüfen von Hypothesen bis zur Implementierung. Im Beispiel könnte die Hypothese lauten, dass der Code die ursprüngliche Sammlung durch die gefilterte ersetzt hat. Dann gilt es, diesen Datenfluss zu untersuchen, den Verlust zu reproduzieren, die Ursache zu beheben und die Korrektur mit einem Regressionstest abzusichern. Nur die Anzeige des Schalters zu korrigieren, würde nicht genügen. Debugging-Anweisungen

Den Abschluss belegen und über den Merge entscheiden

verification-before-completion verlangt aktuelle Befehlsausgaben, bevor Erfolg gemeldet wird. Für dieses Feature bedeutet das Belege zum Filterverhalten, zur Bedienung des Schalters und zu den relevanten Projektprüfungen. Offene Fehler müssen klar benannt werden. Verifikationsanweisungen

Anschließend prüft finishing-a-development-branch die vollständige Testsuite und stellt die Integrationsmöglichkeiten vor. Bei einem gewöhnlichen benannten Branch bietet die aktuelle Datei einen lokalen Merge, das Pushen samt Erstellen eines Pull Requests oder das Beibehalten des Branches an. Sie wartet auf die Entscheidung des Nutzers. Ein bestandenes Review berechtigt nicht stillschweigend zum Merge.

Zum Abschluss dieses Beispiels entscheidet sich der Nutzer für einen lokalen Merge in den bestätigten Basisbranch. Claude führt den Merge aus, testet das zusammengeführte Ergebnis und entfernt den Feature-Worktree samt Branch erst nach erfolgreicher Prüfung. Bei einem Pull Request würde die Arbeit dagegen noch auf den Merge-Prozess des Repositorys warten. Anweisungen zum Abschluss

Wann braucht eine kleine Aufgabe weniger Prozess?

Der Prozess wird zum unnötigen Aufwand, wenn er immer wieder Entscheidungen abfragt, die durch die Anforderung bereits getroffen sind. Eine sichtbare Beschriftung durch einen exakt vorgegebenen Text zu ersetzen, sollte nicht dieselbe Vorbereitung erfordern wie eine Änderung der Speicherung von Aufgabenzuständen. Das ist eine Einschätzung des zusätzlichen Arbeitsaufwands, keine gemessene Aussage über die benötigte Zeit.

Die aktuelle Datei brainstorming unterscheidet drei Größenordnungen:

• Schnelle, klare Aufgabe: Die Anfrage enthält bereits die nötige Beschreibung; direkt erledigen.
• Kleine Änderung: Die Beschreibung im Chat abstimmen und anschließend über den normalen Workflow umsetzen.
• Projekt: Einen schriftlichen Entwurf freigeben und danach einen vollständigen Plan zur Softwareimplementierung erstellen.

Dieselbe Datei erlaubt dem Nutzer, ausdrücklich auf die Rückfragen zu verzichten und damit diese Brainstorming-Freigabe zu beenden. Dieser Verzicht hebt die übrigen Test- oder Verifikationsanweisungen nicht automatisch auf. Regeln zur Umfangseinschätzung und zum Verzicht auf Rückfragen

Eine hilfreiche Anweisung lautet: „Das ist eine kleine Änderung. Halte die Beschreibung im Chat, nutze die vorhandene Testumgebung und erweitere den Funktionsumfang nicht.“ Bei einer bereits entschiedenen Textkorrektur sollten der genaue Wortlaut und der Umfang genannt werden. Das sind Aufgabenbedingungen, die die Rangfolge der Plugin-Anweisungen anerkennt, keine geheimen Umgehungsbefehle.

Die konkrete Grenze ist der Prozessaufwand: Zusätzliche Gespräche, Planungsdokumente, Agentenbeauftragungen und Reviews können in keinem angemessenen Verhältnis zu den verbleibenden offenen Fragen stehen. Der Quellcode dokumentiert diese Schritte; er sagt nicht, wie viele Minuten eine bestimmte Änderung dauern wird. Ignoriert die Sitzung wiederholt den festgelegten Umfang, stellt das Repository mit diagnosing-superpowers einen Skill bereit, der den Ablauf anhand von Gesprächsprotokollen untersucht. Skill zur Sitzungsdiagnose

Wo wird Superpowers überschätzt?

Ein vorgeschriebener Ablauf beweist weder korrekte Software noch einen Geschwindigkeitsgewinn. Ein fehlschlagender Test kann die falsche Anforderung abbilden, ein Plan eine Integrationsbedingung übersehen und ein Review-Agent einen Fehler verpassen. Entscheidend sind die Testaussagen und der Diff, nicht die Selbstsicherheit der Abschlussmeldung.

Arbeit mit Subagenten bedeutet außerdem nicht, dass alle Implementierungsaufgaben gleichzeitig laufen. Der aktuelle Skill verbietet in diesem Workflow ausdrücklich parallele Implementierungsagenten, um Konflikte zu vermeiden. dispatching-parallel-agents ist ein separater Skill für unabhängige Probleme. Regeln zur Beauftragung von Implementierungsagenten

Auch nach der Installation bleibt die Verantwortung für Aufgabenumfang und Integration beim Nutzer. Das Abschlussverfahren des Plugins überlässt ihm ausdrücklich die Merge-Entscheidung. Das stärkste Versprechen von Superpowers betrifft den Ablauf: Es sagt Claude, was es prüfen und welche Belege es vorlegen soll. Ob das hilft, hängt von der Aufgabe ab und davon, ob der Agent die Anweisungen befolgt.

Für wen lohnt sich die Installation, und was ist ein guter erster Versuch?

Die Installation lohnt sich, wenn wichtige Entwicklungsentscheidungen regelmäßig übersprungen werden. Wer allein entwickelt und erlebt, dass der Agent über Anforderungen hinweggeht, kann mit einem begrenzten Feature beginnen, das einen aussagekräftigen Fehlerfall enthält. Dann lässt sich prüfen, ob die Sitzung das Verhalten vor der Implementierung klärt und anschließend Belege liefert.

Ein eingespieltes Entwicklungsteam sollte zuerst seine Konventionen für Planung, Tests und Reviews mit den Plugin-Anweisungen abgleichen. Bilden die vorhandenen Skills den gewünschten Prozess bereits ab, kann ein zusätzlicher allgemeiner Workflow ihn nur noch verdoppeln. Besteht die Arbeit überwiegend aus winzigen, vollständig spezifizierten Änderungen, gibt es weniger Anlass, allein dafür die gesamte Methode einzuführen.

Für Montag bietet sich ein konkreter Versuch an: eine klar begrenzte Änderung auswählen und ihre Abnahmekriterien aufschreiben. Dann Superpowers einsetzen, die gewählten Skills prüfen, den abschließenden Diff durchsehen und beurteilen, ob jedes zusätzliche Dokument oder Zwischenergebnis bei einer Entscheidung geholfen hat. Der Workflow verdient seinen Platz durch nützliche Prüfungen, nicht durch die Länge des erzeugten Plans.

Weitere Tools für andere Aufgaben stellt die Übersicht der besten Claude Code Plugins vor.

Häufige Fragen zu Claude Superpowers

Praktische Tipps zur Entwicklung mit KI gibt es im Newsletter.