Wie arbeitet Superpowers tatsächlich mit Claude Code zusammen? Ein vollständiger Entwicklungsablauf von Anforderungen über Implementierung bis Tests

Superpowers erweitert Claude Code nicht einfach um mehr Codeausgabe, sondern kann den Entwicklungsablauf durch Skills für Anforderungsklärung, Entwurf, Planung, Implementierung und Verifikation strukturieren. Nutzen Sie den vollständigen Ablauf für mehrstufige Aufgaben mit unklaren Anforderungen oder Änderungen über mehrere Dateien; bei einer kleinen, gut rückgängig zu machenden Korrektur dürfen Sie ihn an den tatsächlichen Bedarf anpassen. Die endgültige Prüfung von Code und Testergebnissen bleibt Aufgabe des Entwicklungsteams.

Dieser Leitfaden richtet sich an Entwickler, die Claude Code regelmäßig für Änderungen an mehreren Dateien einsetzen und dafür nachvollziehbare Prüfpunkte benötigen.
Technische Verantwortliche können beurteilen, ob ein gemeinsamer KI-Coding-Ablauf zu den Teamregeln passt.
Wer nur eine klar eingegrenzte Einzelkorrektur erledigen möchte, kann direkt zu den Entscheidungskriterien für einen verkürzten Ablauf springen.

Zuletzt geprüft am 26.09.2026 anhand der offiziellen Superpowers-Dokumentation und der Claude-Code-Dokumentation zu Plugins. Da sich Plugin-Versionen und Projektkonfigurationen ändern können, prüfen Sie Installationsweg und verfügbare Skills vor dem Einsatz erneut.

Superpowers und Claude Code im Entwicklungsablauf

Claude Code führt die eigentliche Arbeit im Projektkontext aus. Superpowers stellt dazu Skills mit Prozessbeschreibungen bereit, die bestimmte Tätigkeiten anleiten können: zum Beispiel Anforderungen zu klären, einen Plan auszuarbeiten oder Tests vor einer Fertigmeldung zu verifizieren. Die Unterscheidung ist wichtig: Ein Skill ist eine Anleitung für das Verhalten des Agenten, keine eigenständige Garantie für korrekten Code, vollständige Testabdeckung oder die Einhaltung sämtlicher Teamvorgaben.

Der offizielle Installations- und Projektüberblick von Superpowers beschreibt, wie die Skills verfügbar gemacht werden. Welche Befehle oder Plugin-Einstiegspunkte im konkreten Setup gelten, hängt vom aktuellen Installationsweg ab. Die Claude-Code-Plugin-Dokumentation erläutert die Plugin-Verwaltung. Prüfen Sie daher vor einer Team-Einführung beide Anleitungen und gleichen Sie die Schritte mit der installierten Version ab, statt ältere Kommandozeilenanweisungen ungeprüft in Ihre Projektdokumentation zu kopieren.

Für die Zusammenarbeit sind drei Ebenen auseinanderzuhalten:

• Werkzeug: Claude Code liest und bearbeitet Projektdateien, soweit es seine verfügbaren Berechtigungen und die Umgebung erlauben.
• Skill: Superpowers gibt Hinweise, welche Arbeitsschritte für eine Aufgabe passen und wie sie strukturiert werden können.
• Menschliche Entscheidung: Entwickler bestätigen Anforderungen, beurteilen Architektur und Risiken und entscheiden, ob Testergebnisse für eine Freigabe genügen.

Die Skills können nicht aus eigener Kraft fehlende Produktanforderungen, nicht zugängliche Dienste oder teaminterne Konventionen ergänzen. Wenn Sie etwa eine Datenbankmigration verlangen, ohne Zielversion oder Rückrollstrategie anzugeben, muss diese Unklarheit vor der Implementierung sichtbar werden. Andernfalls kann ein formal sauber formulierter Plan dennoch an der tatsächlichen Anwendung vorbeigehen.

Unklare Anforderungen in einen bestätigten Entwurf überführen

Der Ablauf sollte mit dem gewünschten Verhalten beginnen, nicht mit einem vorschnellen Codeauftrag. Die Brainstorming-Skillbeschreibung beschreibt, wie eine Idee zunächst durch Rückfragen und Designüberlegungen präzisiert werden kann. Für den praktischen Einsatz ist entscheidend, dass offene Punkte ausdrücklich benannt werden, bevor Claude Code Dateien ändert.

Angenommen, eine bestehende Anwendung soll eine Exportfunktion erhalten. Die Formulierung „Export hinzufügen“ legt weder das Format noch die Datenmenge oder den Umgang mit Fehlern fest. Ein prüfbarer Entwurf sollte die offenen Dimensionen getrennt aufführen:

• Ziel: Welche Daten sollen Benutzer exportieren, und wofür werden sie anschließend verwendet?
• Umfang: Ist eine einzelne Ansicht betroffen oder eine vollständige Sammlung von Datensätzen?
• Einschränkungen: Welche Berechtigungen, vorhandenen Datenmodelle oder Projektkonventionen müssen berücksichtigt werden?
• Offene Entscheidungen: Welches Ausgabeformat ist erforderlich, wie wird mit leeren Ergebnissen umgegangen, und soll der Export synchron oder im Hintergrund erfolgen?
• Abnahme: Woran lässt sich nach der Implementierung erkennen, dass der Export die erwarteten Daten enthält und bei fehlenden Berechtigungen nicht ungewollt Daten offenlegt?

Das ist ein Demonstrationsbeispiel, keine festgelegte Ausgabe von Superpowers. Je nach Aufgabe und Kontext können die Rückfragen, Entwurfsstruktur und benötigten Entscheidungen anders aussehen. Die Entwickler müssen unzutreffende Annahmen korrigieren und den Entwurf prüfen, bevor er als Grundlage für einen Plan dient. So sinkt das Risiko, dass ein Agent zwar eine plausible Funktion implementiert, aber die falsche Nutzerentscheidung zugrunde legt.

Ein häufiger Fehler ist, eine allgemeine Zielbeschreibung als ausreichende Spezifikation zu behandeln. Auch ein höflich formuliertes „Soll ich fortfahren?“ ist kein Ersatz für eine Entscheidung darüber, welche Daten einbezogen werden oder welches Verhalten bei einem Fehler erwartet wird. Halten Sie deshalb bestätigte Anforderungen und noch offene Punkte getrennt fest. Solange eine offene Frage Architektur oder Datensicherheit beeinflusst, sollte die Umsetzung darauf nicht stillschweigend eine Annahme aufbauen.

Den Plan in überprüfbare Arbeitsschritte zerlegen

Nach dem bestätigten Entwurf folgt die Planung. Die Skillbeschreibung zum Schreiben von Plänen sieht kleinteilige Aufgaben mit konkretem Umfang und prüfbarem Ergebnis vor; sie nennt für einzelne Arbeitsschritte als Richtwert eine Größenordnung von 2–5 Minuten. Das ist eine Orientierung aus der Skillbeschreibung, keine allgemeingültige Schätzung für jedes Projekt und kein Versprechen, dass die Umsetzung tatsächlich so lange dauert.

Ein brauchbarer Plan macht sichtbar, was Claude Code ändern soll und wie das Ergebnis kontrolliert werden kann. Für die beispielhafte Exportfunktion könnte ein Plan etwa so aufgebaut sein:

• Vorhandene Export- oder Downloadpfade und relevante Datenmodelle untersuchen; Ergebnis: betroffene Dateien und vorhandene Konventionen sind benannt.
• Eine Exportfunktion für den bestätigten Umfang ergänzen; Ergebnis: nur die im Entwurf festgelegten Datensätze werden verarbeitet.
• Fehler- und Berechtigungsfälle behandeln; Ergebnis: fehlende Berechtigung und leere Datenmenge lassen sich getrennt prüfen.
• Tests für regulären Export und definierte Grenzfälle ergänzen; Ergebnis: die Tests decken die vereinbarten Abnahmekriterien ab.
• Tests ausführen und den Diff kontrollieren; Ergebnis: Befehle, Ausgaben und verbleibende Einschränkungen sind dokumentiert.

Die Qualität eines Plans hängt vom Projektkontext ab. Fehlen Informationen zu Testbefehlen, Modulgrenzen, generiertem Code oder Datenzugriffen, kann auch ein kleinteiliger Plan die falsche Datei oder einen unpassenden Prüfweg vorsehen. Geben Sie Claude Code daher relevante Projektanweisungen und prüfen Sie, ob die vorgeschlagenen Dateien tatsächlich zum bestätigten Entwurf passen.

Ein Plan wird außerdem nicht automatisch sicher, nur weil jede Aufgabe klein ist. Änderungen an Konfiguration, Zugangsdaten, Migrationen oder Berechtigungen benötigen zusätzliche Prüfung, selbst wenn sie sich in wenigen Zeilen Code ausdrücken. Markieren Sie solche Punkte als eigene Kontrollschritte, anstatt sie zwischen Routineaufgaben zu verstecken.

Die Umsetzung an Skills und Projektkonventionen ausrichten

Bei der Implementierung kann Claude Code den verfügbaren Skills entsprechend dem Aufgabenkontext folgen. Daraus folgt nicht, dass jede Anfrage stets dieselbe Reihenfolge durchläuft oder jeder Skill in jeder Sitzung aktiviert wird. Verfügbarkeit, Projektkonfiguration, Version und konkrete Aufgabe beeinflussen, welche Anleitung herangezogen wird. Beschreiben Sie deshalb im Auftrag die bestätigte Anforderung, den vereinbarten Plan und relevante lokale Regeln, statt sich allein auf einen impliziten Ablauf zu verlassen.

Beim testgetriebenen Vorgehen beschreibt die TDD-Skilldatei den bekannten Dreischritt aus fehlgeschlagenem Test, minimaler Implementierung und anschließender Bereinigung. Dieser Ablauf hilft, eine Änderung an beobachtbare Erwartungen zu binden. Er beweist jedoch nicht, dass die Tests alle Risiken abdecken: Ein Test kann die falsche Erwartung festschreiben, einen Grenzfall auslassen oder in einer anderen Umgebung ein anderes Verhalten zeigen.

Bei der Exportfunktion sollte deshalb zunächst ein Test das gewünschte Verhalten für den bestätigten Fall ausdrücken. Danach folgt die minimale Änderung, die diesen Test erfüllt. Eine anschließende Bereinigung darf die Lesbarkeit verbessern, sollte aber das beobachtete Verhalten nicht unbemerkt verändern. Falls der Agent den vorgesehenen Test nicht ausführen kann, muss das als Einschränkung dokumentiert werden, nicht als erfolgreich abgeschlossener Prüfschritt.

Achten Sie außerdem auf die Differenz zwischen Skill-Anleitung und tatsächlich ausgeführter Arbeit. Ein Agent kann einen Plan zusammenfassen, ohne jede darin genannte Datei zu bearbeiten; er kann auch zusätzliche Änderungen vornehmen, die im Plan nicht standen. Prüfen Sie deshalb regelmäßig, ob der aktuelle Diff noch innerhalb des freigegebenen Umfangs liegt. Wenn eine neue Architekturentscheidung auftaucht, sollte Claude Code den Plan nicht stillschweigend erweitern, sondern die Entscheidung sichtbar machen.

Testergebnisse als Belege prüfen

Eine Fertigmeldung ist noch kein Testergebnis. Die Skillbeschreibung zur Verifikation vor dem Abschluss fordert dazu auf, Aussagen über den Abschluss mit aktueller Verifikation zu stützen. Für Entwickler heißt das: Der tatsächlich ausgeführte Befehl, seine Ausgabe und der dazugehörige Codezustand müssen nachvollziehbar sein.

Notieren Sie bei der Prüfung mindestens:

• den verwendeten Test- oder Build-Befehl und den betroffenen Projektbereich;
• ob der Befehl vollständig ausgeführt wurde oder vorzeitig abbrach;
• die beobachtete Ausgabe einschließlich fehlgeschlagener Tests;
• Umgebungsbedingungen, die die Ausführung verhindert oder eingeschränkt haben;
• den Status der noch offenen Abnahmekriterien.

Trennen Sie anschließend drei Arten von Befunden, statt sie unter „Tests fehlgeschlagen“ zusammenzufassen:

• Umgebungsproblem: Ein erforderlicher Dienst, eine Berechtigung oder eine Abhängigkeit ist nicht verfügbar. Daraus lässt sich noch nicht ableiten, ob die Änderung korrekt ist.
• Testfehler: Ein automatisierter Test schlägt reproduzierbar fehl. Das muss untersucht werden; der Fehler kann auf eine Regression, einen veralteten Test oder eine falsche Annahme hinweisen.
• Produktfehler: Das beobachtete Verhalten widerspricht der bestätigten Anforderung. Ein bestandener Test schließt diesen Fehler nicht aus, wenn der Test das Verhalten nicht abbildet.

Wenn ein Test nicht ausgeführt wurde, formulieren Sie den Abschluss entsprechend: „nicht verifiziert“ ist genauer als „funktioniert“. Die Systematic-Debugging-Skillbeschreibung bietet einen strukturierten Ansatz für die Fehlersuche. Lassen Sie den Agenten Ursache und beobachtete Symptome auseinanderhalten und verlangen Sie reproduzierbare Hinweise, bevor eine Korrektur als abgeschlossen gilt.

Häufige Fragen zur Zusammenarbeit

Wie setzen Sie Superpowers gemeinsam mit Claude Code ein?

Superpowers wird als Plugin beziehungsweise über den im offiziellen Repository beschriebenen Installationsweg verfügbar gemacht. Claude Code kann dann passende Fähigkeiten im jeweiligen Aufgabenkontext heranziehen. Prüfen Sie zuerst die aktuelle Installationsanleitung und die verfügbaren Skills; behandeln Sie einen beschriebenen Ablauf nicht als Garantie, dass jede Anfrage automatisch dieselben Schritte auslöst.

Wie werden aus einer unklaren Idee ein Entwurf und ein Arbeitsplan?

Die Brainstorming-Fähigkeit hilft, Ziel, Umfang, Einschränkungen und offene Entscheidungen zu klären. Erst wenn der Entwurf geprüft und bestätigt ist, sollte daraus ein Plan mit konkreten Aufgaben, betroffenen Dateien und überprüfbaren Abnahmekriterien entstehen. Die Qualität hängt weiterhin davon ab, ob Claude Code genügend Projektkontext erhält und ob die Vorgaben tatsächlich stimmen.

Müssen Sie den Code nach der Arbeit mit Superpowers noch selbst testen?

Ja. Ein Skill kann dazu anleiten, Tests auszuführen und Belege vor einer Fertigmeldung zu prüfen, ersetzt aber weder die Ausführung in der passenden Umgebung noch Ihre Bewertung der Ergebnisse. Kontrollieren Sie den tatsächlich ausgeführten Befehl, die Ausgabe und den Code-Diff. Ein nicht verfügbarer Dienst, ein fehlschlagender Test und ein reproduzierbarer Produktfehler sind unterschiedliche Befunde.

Eignet sich Superpowers eher für kleine Korrekturen oder größere Funktionen?

Bei einer eng begrenzten, leicht rückgängig zu machenden Korrektur können Sie den Ablauf verkürzen, sofern Ursache und gewünschtes Verhalten eindeutig sind. Bei Änderungen über mehrere Dateien, unsicheren Anforderungen oder schwer erkennbaren Nebenwirkungen lohnt sich die vollständige Klärung mit Entwurf, Plan und Verifikation. Maßgeblich bleiben Projektregeln, Risikoeinschätzung und die installierte Version.

Den Diff vor Übergabe oder Zusammenführung prüfen

Auch wenn Tests erfolgreich laufen, kann der Code außerhalb des vereinbarten Umfangs liegen oder eine wichtige Ausnahmebehandlung übersehen. Vor einer Zusammenführung oder Übergabe sollte deshalb eine Person den tatsächlichen Diff lesen. Der Skill zum Anfordern einer Codeprüfung kann beim Vorbereiten einer Prüfung unterstützen; er ersetzt nicht die im Team geltenden Freigabe- und Review-Regeln.

Eine manuelle Prüfliste hilft, die Kontrolle konkret zu halten:

• [ ] Stimmen alle geänderten Dateien mit dem bestätigten Entwurf und Plan überein?
• [ ] Ist jede wesentliche Änderung im Diff verständlich und begründet?
• [ ] Sind Fehlerpfade, leere Eingaben, Berechtigungen und relevante Grenzfälle berücksichtigt?
• [ ] Entsprechen Tests und tatsächliche Ausführung den vereinbarten Abnahmekriterien?
• [ ] Sind fehlgeschlagene oder nicht ausführbare Prüfungen ausdrücklich dokumentiert?
• [ ] Bleiben Änderungen an Konfiguration, Datenformaten und Schnittstellen innerhalb der Teamvorgaben?
• [ ] Wurde die vorgeschriebene menschliche Prüfung vor Zusammenführung oder Auslieferung eingehalten?

Bei einem größeren Diff reicht es nicht, nur die vom Agenten hervorgehobenen Dateien zu lesen. Suchen Sie nach Änderungen, die im Plan nicht vorkommen, und prüfen Sie, ob die Implementierung das bestätigte Verhalten tatsächlich abbildet. Wenn ein Review eine neue Anforderung aufdeckt, ist das ein Anlass, den Entwurf zu aktualisieren und betroffene Tests nachzuziehen, nicht bloß einen weiteren Patch ohne erneute Prüfung anzuhängen.

Den Ablauf nach Risiko und Rückrollbarkeit wählen

Superpowers muss nicht für jede Änderung mit derselben Tiefe eingesetzt werden. Entscheidend sind das Risiko eines Fehlers, der Änderungsumfang und die Möglichkeit, die Änderung schnell und sicher zurückzunehmen. Verwenden Sie die folgenden Verzweigungen als Entscheidungshilfe:

• Wenn die Ursache klar, die Änderung eng begrenzt und der Rückweg einfach ist, dann können Sie Anforderungsklärung und Planung kurz halten; prüfen Sie trotzdem den Diff und führen Sie die passenden Tests aus. Andernfalls klären Sie zunächst, welches Verhalten erwartet wird.
• Wenn die Änderung mehrere Module, Schnittstellen oder Datenflüsse betrifft, dann nutzen Sie den vollständigen Weg über Entwurf, Aufgabenplan, Umsetzung und Verifikation. Andernfalls genügt möglicherweise ein schlanker Plan mit klarer Abnahme.
• Wenn eine Fehlentscheidung Datenverlust, Sicherheitsprobleme oder schwer rückgängig zu machende Änderungen verursachen könnte, dann verlangen Sie zusätzliche menschliche Freigabe und geeignete Prüfungen. Andernfalls können Sie den Umfang der formellen Kontrolle an das tatsächliche Risiko anpassen.
• Wenn Projektkontext oder Testumgebung fehlen, dann ergänzen Sie diese Informationen oder dokumentieren Sie die Verifikationsgrenze. Andernfalls droht eine scheinbar vollständige Fertigmeldung ohne belastbare Grundlage.

Diese Regeln sind eine Entscheidungshilfe, keine Sicherheitszertifizierung. Prüfen Sie die installierte Plugin-Version und die geltenden Projektvorgaben, bevor Sie daraus verbindliche Teamstandards machen. Auch ein sauber befolgter Skill kann falsche Anforderungen nicht korrigieren und keine fehlenden Berechtigungen oder nicht vorhandenen Tests ersetzen.

Eine passende Entwicklungsumgebung für längere Aufgaben wählen

Bei einer kurzen Änderung ist eine lokale Entwicklungsumgebung oft ausreichend, sofern Projektabhängigkeiten und Tests dort verfügbar sind. Bei längeren Agent-Sitzungen kann dagegen ein gemeinsam erreichbarer, konsistenter Arbeitsbereich organisatorisch sinnvoll sein: Das Team muss dann festlegen, wer Zugriff hat, wie Änderungen isoliert werden und wie Zugangsdaten geschützt bleiben. Eine entfernte Umgebung löst diese Fragen nicht von selbst; Datenschutz, Zugriffsrechte, Sitzungsdauer und die Ablage vertraulicher Projektdaten müssen weiterhin nach den geltenden Sicherheits- und Datenschutzvorgaben geprüft werden.

Wenn eine Aufgabe nur kurz dauert und keine gemeinsame Umgebung voraussetzt, ist die lokale Entwicklung häufig die einfachere Wahl. Sie vermeiden dabei zusätzliche Bereitstellung und müssen keine Remote-Zugriffe organisieren. Für wiederkehrende Arbeit kann ein eigener Rechner planbarer sein, sofern er dauerhaft verfügbar ist und die laufenden Kosten sowie Wartung zum tatsächlichen Bedarf passen. Eine gemietete Mac-Umgebung kann interessant sein, wenn ein Team vorübergehend einen gemeinsam erreichbaren Entwicklungsplatz benötigt, ohne dafür sofort einen Rechner dauerhaft zu beschaffen; sie ist aber kein Ersatz für Versionskontrolle, Zugriffskontrollen oder Code-Reviews.

Für den Fall, dass eine entfernte Mac-Umgebung zur Arbeitsweise passt, können Sie zunächst die Bestellübersicht für Mac-Umgebungen prüfen. Wenn der Standort für Latenz oder Teamzugriff relevant ist, vergleichen Sie die dort verfügbaren Angaben, statt aus einer Regionsbezeichnung auf Datenschutz oder Eignung zu schließen; als konkrete Beispiele lassen sich die Informationen zu Mac-Umgebungen an der US-Ostküste und an der US-Westküste heranziehen.

Für die Umsetzung von Claude-Code-Aufgaben bleibt der entscheidende Unterschied: Eine lokale Lösung hängt an der Verfügbarkeit und Konfiguration des jeweiligen Entwicklerrechners, während ein gemeinsam genutzter Remote-Arbeitsplatz zusätzliche Zugriffs- und Umgebungsverwaltung verlangt. Wenn Sie nur gelegentlich eine entfernte Entwicklungsumgebung benötigen, kann die Miete über nuvcloud gegenüber einer sofortigen Anschaffung die passendere Option sein. Für dauerhaft hohe Auslastung, spezielle physische Schnittstellen oder Anforderungen an vollständige lokale Kontrolle ist ein eigener Mac möglicherweise die bessere Entscheidung.

FAQ

Wie setzen Sie Superpowers gemeinsam mit Claude Code ein?

Superpowers wird als Plugin beziehungsweise über den im offiziellen Repository beschriebenen Installationsweg verfügbar gemacht. Claude Code kann dann passende Fähigkeiten im jeweiligen Aufgabenkontext heranziehen. Prüfen Sie zuerst die aktuelle Installationsanleitung und die verfügbaren Skills; behandeln Sie einen beschriebenen Ablauf nicht als Garantie, dass jede Anfrage automatisch dieselben Schritte auslöst.

Wie werden aus einer unklaren Idee ein Entwurf und ein Arbeitsplan?

Die Brainstorming-Fähigkeit hilft, Ziel, Umfang, Einschränkungen und offene Entscheidungen zu klären. Erst wenn der Entwurf geprüft und bestätigt ist, sollte daraus ein Plan mit konkreten Aufgaben, betroffenen Dateien und überprüfbaren Abnahmekriterien entstehen. Die Qualität hängt weiterhin davon ab, ob Claude Code genügend Projektkontext erhält und ob die Vorgaben tatsächlich stimmen.

Müssen Sie den Code nach der Arbeit mit Superpowers noch selbst testen?

Ja. Ein Skill kann dazu anleiten, Tests auszuführen und Belege vor einer Fertigmeldung zu prüfen, ersetzt aber weder die Ausführung in der passenden Umgebung noch Ihre Bewertung der Ergebnisse. Kontrollieren Sie den tatsächlich ausgeführten Befehl, die Ausgabe und den Code-Diff. Ein nicht verfügbarer Dienst, ein fehlschlagender Test und ein reproduzierbarer Produktfehler sind unterschiedliche Befunde.

Eignet sich Superpowers eher für kleine Korrekturen oder größere Funktionen?

Bei einer eng begrenzten, leicht rückgängig zu machenden Korrektur können Sie den Ablauf verkürzen, sofern Ursache und gewünschtes Verhalten eindeutig sind. Bei Änderungen über mehrere Dateien, unsicheren Anforderungen oder schwer erkennbaren Nebenwirkungen lohnt sich die vollständige Klärung mit Entwurf, Plan und Verifikation. Maßgeblich bleiben Projektregeln, Risikoeinschätzung und die installierte Version.