Superpowers: Multi-Agent-Entwicklung hängt? Umgebungsprüfung 2026

Die Fähigkeit wird geladen, aber der Teilagent startet nicht – oder die Aufgabe endet ohne verwertbares Ergebnis.

Schnellste Lösung: Prüfen Sie zuerst, ob Ihr aktuelles Coding-Harness beim Sitzungsstart Fähigkeiten einbindet und Datei-, Shell- sowie Aufgabenübergabe-Werkzeuge bereitstellt. Kontrollieren Sie danach Plugin-Status und Aufgabenbeschreibung. Fehlt ein benötigtes Werkzeug, wechseln Sie zu einem unterstützten Ablauf oder arbeiten Sie die Aufgabe manuell Schritt für Schritt ab, statt wiederholt neu zu installieren.

Dieser Leitfaden ist für Sie, wenn Sie Superpowers bereits eingerichtet haben, aber eine Fähigkeit nicht ausgelöst wird oder ein Multi-Agent-Ablauf abbricht.
Er hilft Ihnen auch beim Wechsel zwischen Coding-Harnesses und beim Aufbau eines reproduzierbaren Prüfpfads für entfernte Entwicklungsumgebungen.

Erst den Fehlerort bestimmen, dann die Installation prüfen

„Superpowers funktioniert nicht“ beschreibt noch keine Ursache. Entscheidend ist, an welcher Stelle das Verhalten von dem abweicht, was Sie erwarten. Ein Plugin, das gar nicht geladen wurde, braucht eine andere Korrektur als eine Aufgabe, die gestartet, aber nicht zurückgemeldet wird.

Halten Sie für einen ersten Test fest, ob der Fehler beim Sitzungsstart, beim Aufruf der Fähigkeit, bei der Werkzeugausführung oder bei der Rückgabe des Teilauftrags auftritt. Führen Sie dann dieselbe kleine, klar begrenzte Aufgabe erneut aus. Ein geeignetes Beispiel ist: „Lies diese einzelne Datei, fasse die relevanten Funktionen zusammen und gib die Zusammenfassung an den Hauptablauf zurück.“ Die Aufgabe sollte keine Änderungen an fremden Dateien, externen Diensten oder produktiven Daten voraussetzen.

Warum wird eine Superpowers-Fähigkeit nicht ausgelöst?
Prüfen Sie zunächst, ob die aktuelle Sitzung die Fähigkeit überhaupt kennt. Ein Eintrag in einem Plugin-Verzeichnis beweist nicht, dass er aktiviert wurde oder beim Sitzungsstart in den Arbeitskontext gelangt ist. Die offizielle Beschreibung der using-superpowers-Fähigkeit erklärt deren vorgesehene Verwendung. Vergleichen Sie diese mit dem tatsächlichen Sitzungsverhalten, statt aus einer fehlenden Reaktion sofort auf eine fehlerhafte Installation zu schließen.

Notieren Sie den Auslöser und die sichtbare Ausgabe. Achten Sie besonders darauf, ob die Fähigkeit im verfügbaren Kontext auftaucht, ob das Harness eine Ablehnung anzeigt und ob überhaupt ein Werkzeugaufruf erfolgt. Fehlt jeder Hinweis auf einen Aufruf, liegt der erste Prüfpunkt vor der Werkzeugausführung. Wird dagegen ein Aufruf protokolliert und abgelehnt, ist die Berechtigungs- oder Richtlinienprüfung naheliegender.

Eine kleine Wiederholung unterscheidet außerdem einen stabilen Fehler von einer einmaligen Unterbrechung. Ändern Sie dabei nicht gleichzeitig Plugin-Version, Harness, Prompt und Berechtigungen. Sonst können Sie nachher nicht erkennen, welche Änderung den Unterschied verursacht hat.

Sitzungsstart oder Harness: Was ist tatsächlich aktiv?

Superpowers’ Fähigkeiten allein erzeugen noch keinen vollständigen Arbeitsablauf. Die Umgebung muss sie verfügbar machen und passende Werkzeuge bereitstellen. Die offizielle README und der Leitfaden zur Anpassung an ein neues Harness sind deshalb die maßgeblichen Bezugspunkte, wenn Sie feststellen möchten, welche Integrationsschritte dokumentiert sind.

Unterscheiden Sie zwischen einer ausdrücklich dokumentierten Integrationsmethode und einer eigenen Anpassung. Wenn Ihr Harness in einer Anleitung beschrieben wird, folgen Sie diesem Verfahren und prüfen Sie die einzelnen Voraussetzungen. Haben Sie die Fähigkeiten selbst in ein anderes System übertragen, behandeln Sie diese Integration zunächst als Ihre eigene Implementierung. Eine ähnliche Oberfläche oder ein vergleichbarer Agentenbegriff belegt nicht, dass Sitzungsinjektion und Werkzeugübergabe gleich funktionieren.

Beobachtung	Wahrscheinlicher Prüfbereich	Nächster sinnvoller Test
Fähigkeit fehlt in einer frisch gestarteten Sitzung	Installation, Aktivierung oder Sitzungsinjektion	Plugin-Status kontrollieren und neue Sitzung mit unverändertem Setup öffnen
Fähigkeit ist sichtbar, wird aber nicht ausgeführt	Aufrufbedingung, Aufgabenformulierung oder Richtlinie	Klare, eng begrenzte Aufforderung ohne Nebenaufgaben verwenden
Shell- oder Dateiaufruf wird abgewiesen	Werkzeugberechtigung oder Ausführungsrichtlinie	Ablehnungsgrund und erlaubte Werkzeugaktionen prüfen
Teilaufgabe startet, aber es kommt keine Rückmeldung	Aufgabenübergabe, Rückkanal oder Sitzungszustand	Auftragsstatus und Protokolle vor und nach dem Übergabepunkt vergleichen
Bericht behauptet einen Abschluss ohne Testergebnis	Verifikation oder unvollständige Rückmeldung	Tatsächliche Befehlsausgabe getrennt vom Abschlussbericht erfassen

Was muss nach einem Wechsel des Coding-Harness geprüft werden?
Vergleichen Sie nicht nur, ob beide Umgebungen ein Plugin-Menü anbieten. Prüfen Sie, ob Fähigkeiten beim Sitzungsstart verfügbar werden, ob die Umgebung Datei- und Shell-Aktionen zulässt und ob ein Teilauftrag mit seinem Ergebnis an den Hauptablauf zurückgegeben werden kann. Der Leitfaden zur Harness-Anpassung beschreibt den Anpassungsweg. Ein eigener Adapter kann davon abweichen; halten Sie diese Abweichungen fest und bezeichnen Sie sie nicht als offiziell zugesicherte Unterstützung.

Wenn eine Sitzung nach einer Einstellungsänderung weiterläuft, prüfen Sie ausdrücklich, ob die Änderung bereits in dieser Sitzung wirksam ist. Eine Konfiguration kann für neu gestartete Sitzungen gelten, während ein laufender Kontext weiterhin den vorherigen Zustand verwendet. Starten Sie deshalb bei einem kontrollierten Test eine frische Sitzung, ohne weitere Einstellungen zu ändern. So sehen Sie, ob die Ursache am veralteten Sitzungszustand lag.

Werkzeugrechte und Aufgabenübergabe auseinanderhalten

Ein Multi-Agent-Ablauf braucht mehr als einen Agentennamen. Die Umgebung muss die Aktionen erlauben, die die Aufgabe verlangt. Dazu können das Lesen und Schreiben von Dateien, Shell-Befehle oder das Anlegen und Überwachen eines Teilauftrags gehören. Fehlt eine dieser Fähigkeiten, kann die Aufgabe an genau dieser Grenze stecken bleiben.

Prüfen Sie, ob die benötigte Aktion in der Werkzeugliste Ihrer Umgebung tatsächlich existiert. Wenn Sie kein Werkzeug für das Starten von Teilaufgaben sehen, raten Sie keine Werkzeugnamen und probieren Sie nicht wahllos ähnlich klingende Befehle. Ein nicht verfügbares Werkzeug wird durch eine andere Schreibweise nicht verfügbar. Wechseln Sie stattdessen zu einem Ablauf, den das Harness ausdrücklich unterstützt, oder erledigen Sie die Teilaufgaben nacheinander.

Die Dokumentation zu Werkzeugfreigaben und Genehmigungen in einer Kommandozeilenumgebung erläutert, dass erlaubte Aktionen und Freigaben vom jeweiligen Betriebsmodus abhängen. Die Dokumentation zu Genehmigungsstatus und Schutzregeln behandelt ebenfalls die Trennung zwischen einer angeforderten Aktion und ihrer Freigabe. Diese Beschreibungen helfen beim Verständnis der Mechanismen, sind aber kein Beleg dafür, dass Ihr eigenes Harness dieselben Werkzeuge oder Abläufe bereitstellt.

Kann Superpowers ohne Teilagenten-Werkzeug noch verwendet werden?
Ja, sofern Ihr Harness die benötigten Fähigkeiten und Werkzeuge für den jeweils gewählten Ablauf verfügbar macht. Ohne Werkzeug zur Aufgabenübergabe können Sie Aufgaben weiterhin selbst in klar abgegrenzte Schritte teilen, die Ergebnisse prüfen und nacheinander in den Hauptablauf übernehmen. Sie sollten diesen Ablauf jedoch nicht als automatische Multi-Agent-Ausführung behandeln. Die Beschreibung der teilagentengestützten Entwicklung ist der passende Bezugspunkt, um Anforderungen des vorgesehenen Vorgehens mit den tatsächlich vorhandenen Werkzeugen abzugleichen.

Entscheidung nach den vorhandenen Funktionen:

Wenn das Harness Fähigkeiten beim Sitzungsstart einbindet, Datei- und Shell-Aktionen erlaubt und Teilaufträge samt Ergebnisübergabe unterstützt, dann testen Sie den Multi-Agent-Ablauf mit einer kleinen, eigenständigen Aufgabe.
Wenn die Fähigkeit geladen wird und Datei- sowie Shell-Werkzeuge vorhanden sind, aber kein Teilagenten-Werkzeug existiert, dann verwenden Sie einen explizit manuellen, seriellen Ablauf.
Wenn Fähigkeiten nach einem Harness-Wechsel nicht erscheinen, dann prüfen Sie zuerst Integration, Aktivierung und Sitzungsstart; installieren Sie nicht wiederholt dieselbe Komponente ohne neue Erkenntnis.
Wenn Aktionen durch eine Richtlinie abgewiesen werden, dann klären Sie, ob die Richtlinie angepasst werden darf. Umgehen Sie eine Sperre nicht durch erfundene Werkzeugnamen oder undokumentierte Aufrufe.
Wenn weder die erforderlichen Werkzeuge noch eine dokumentierte Integrationsmöglichkeit verfügbar sind, dann wählen Sie ein geeignetes Harness oder führen Sie die Arbeit manuell aus.

Für entfernte Entwicklungsplätze kommt eine weitere Grenze hinzu: Eine Verbindung kann verfügbar sein, während der Arbeitsbereich oder die Sitzung nicht im erwarteten Zustand ist. Prüfen Sie, ob Sie im richtigen Projektverzeichnis arbeiten, ob die relevanten Dateien sichtbar sind und ob Ihr Zugriff Änderungen erlaubt. Legen Sie keine Zugangsdaten in Aufgabenbeschreibungen oder Diagnoseprotokollen ab. Wenn Sie Betriebsdetails oder verfügbare Unterstützungswege klären müssen, verwenden Sie das Hashvps-Hilfezentrum; teilen Sie dabei keine Projektinhalte oder vertraulichen Sitzungsausgaben.

Teilaufgaben ohne Ergebnis und verlorenen Kontext lokalisieren

Startet ein Teilauftrag, bleibt aber ohne verwertbare Rückgabe, prüfen Sie die Übergabepunkte einzeln. Ist der Auftrag in der Umgebung sichtbar? Gibt es eine Ausgabe oder einen Status? Wurde das Ergebnis in den Hauptablauf zurückgeschrieben? Eine fehlende Antwort beweist nicht, dass der Agent intern an einer bestimmten Stelle „nachgedacht“ oder „aufgegeben“ hat. Leiten Sie nur aus sichtbaren Protokollen, Statusangaben und Dateien ab, was passiert ist.

Formulieren Sie Teilaufträge so, dass sie unabhängig verständlich sind. Geben Sie Ziel, relevante Dateien oder Eingaben, erwartetes Ergebnis und Grenzen an. Eine Anweisung wie „Mach mit dem Rest weiter“ hängt an nicht näher benanntem Kontext. Eine Anweisung wie „Prüfe die angegebene Funktion, ändere keine Dateien und gib Fundstelle sowie Begründung zurück“ lässt sich leichter ausführen und kontrollieren.

Suchen Sie den letzten belegbaren Übergabepunkt: Auftrag erstellt, Werkzeug gestartet, Prozess beendet, Ergebnis zurückgegeben oder Hauptablauf fortgesetzt. Wenn Ihr Harness diese Ereignisse protokolliert, sichern Sie die relevanten Ausschnitte mit Zeitbezug und entfernen Sie vorher sensible Inhalte. Fehlt ein Ereignis im Protokoll, benennen Sie das als fehlenden Nachweis. Ersetzen Sie es nicht durch eine Vermutung über Modellverhalten.

Lange Sitzungen und Sitzungsneustarts können außerdem dazu führen, dass frühere Arbeitsinformationen nicht mehr im aktuellen Kontext liegen. Vergleichen Sie deshalb den tatsächlichen Aufgabenstatus und die gespeicherten Ergebnisse mit der letzten Zusammenfassung. Wurde die Sitzung neu gestartet, prüfen Sie, ob der offene Auftrag und sein erwarteter Rückkanal weiterhin verfügbar sind. Bewerten Sie nicht allein anhand einer Gesprächsformulierung, ob eine Aufgabe noch läuft.

Verifikation: Fehler, fehlendes Werkzeug und ungeprüfte Arbeit trennen

Ein Abschlussbericht ist kein Testergebnis. Trennen Sie den Testbefehl, seine tatsächliche Ausgabe, den Rückgabestatus und die anschließende Prüfung voneinander. Wenn ein Befehl nicht ausgeführt werden konnte, weil die Shell-Funktion fehlte oder keine Freigabe vorlag, ist das kein fehlgeschlagener Test. Es ist ein nicht ausgeführter Test. Wenn der Test tatsächlich lief und einen Fehler meldete, erfassen Sie den Fehler als Testergebnis.

Nachweis	Was Sie festhalten	Wie Sie den Befund einordnen
Testbefehl	Den tatsächlich verwendeten Befehl oder Prüfweg	Macht nachvollziehbar, was geprüft werden sollte
Ausgabe	Unveränderte relevante Meldung, gegebenenfalls datenschutzgerecht bereinigt	Zeigt, ob der Test lief und was er zurückgab
Werkzeugstatus	Gestartet, abgewiesen, nicht verfügbar oder abgebrochen	Trennt Ausführungsprobleme vom Testergebnis
Aufgabenstatus	Offen, abgeschlossen oder ohne bestätigte Rückmeldung	Zeigt, ob der Hauptablauf einen Abschluss belegen kann
Prüfung des Ergebnisses	Geprüfte Änderung, Datei oder fachliche Rückmeldung	Verhindert, dass eine unbelegte Abschlussbehauptung als Erfolg gilt

Wenn die Ausführung durch eine Freigabeentscheidung unterbrochen wurde, halten Sie genau diese Grenze fest. Eine abgewiesene Aktion darf nicht im Bericht als ausgeführt erscheinen. Ebenso sollten Sie einen erfolgreichen Befehl nicht mit einer bestandenen fachlichen Prüfung gleichsetzen, wenn diese Prüfung gar nicht vorgenommen wurde. So bleiben reale Fehler, fehlende Werkzeuge und ungeprüfte Ergebnisse voneinander unterscheidbar.

Aus einem Einzelfehler eine wiederholbare Prüfung machen

Ein guter Fehlerbericht hilft Ihnen beim nächsten Harness-Wechsel und bei der Wartung entfernter Sitzungen. Erfassen Sie für jeden Vorfall die Umgebung, den aktuellen Harness- und Plugin-Stand, den Aktivierungsstatus, den Sitzungsstart, verfügbare Werkzeuge, die kleinste reproduzierbare Aufgabe und das beobachtete Ergebnis. Ergänzen Sie, welche Änderung Sie vorgenommen haben und ob derselbe Test anschließend erfolgreich war. Verzichten Sie auf Projektinhalte, Schlüssel und personenbezogene Sitzungsdaten.

Verändern Sie beim Reparaturversuch möglichst nur einen Einflussfaktor. Wenn Sie gleichzeitig das Plugin neu installieren, Berechtigungen ändern und eine andere Aufgabe testen, bleibt die Ursache unklar. Wiederholen Sie stattdessen den gleichen Minimaltest und ändern Sie gezielt die vermutete Fehlerquelle. Nach einer Änderung am Harness oder an dessen Integration führen Sie dieselbe Prüfung erneut aus. Nur so können Sie ein verändertes Ergebnis der Änderung zuordnen.

Wenn Sie eine Umgebung ersetzen oder neu aufsetzen, gleichen Sie die angebotenen Optionen und Betriebsbedingungen mit Ihren Anforderungen ab. Die Übersicht der Hashvps-Angebote kann dabei als Einstieg dienen. Entscheidend ist nicht ein abstrakter Vergleich, sondern ob die benötigte Entwicklungsumgebung, Zugriffsmethode und Werkzeugnutzung zu Ihrem Arbeitsablauf passen.

Was gehört in einen belastbaren Reparaturvermerk?
Notieren Sie die Fehlerstelle, Harness- und Plugin-Informationen, Aktivierungszustand, verfügbare Aktionen, den Minimaltest, die sichtbaren Protokolle und die konkrete Reparatur. Vermerken Sie außerdem, ob Sie den Fehler nach der Änderung mit demselben Test erneut geprüft haben. Kennzeichnen Sie Vermutungen ausdrücklich als Vermutungen; ein fehlender Protokolleintrag darf nicht als Beweis für ein internes Verhalten ausgegeben werden.

Wenn ein Wechsel sinnvoller ist als weitere Installationsversuche

Eine lokale Umgebung ist oft passend, wenn Sie dauerhaft dieselben Werkzeuge und direkten Zugriff auf Ihre Arbeitsdateien benötigen. Ein anderes Harness kann sinnvoll sein, wenn die aktuelle Umgebung keine dokumentierte Möglichkeit zur benötigten Aufgabenübergabe bietet. Ein entfernter Entwicklungsplatz wiederum kann helfen, wenn Sie eine getrennte Arbeitsumgebung für Tests benötigen, löst aber weder eine ungeklärte Berechtigungsregel noch eine fehlerhafte Aufgabenbeschreibung automatisch.

Wiederholte Installationen sind keine geeignete Standardmaßnahme, wenn Fähigkeiten bereits sichtbar sind, ein Werkzeugaufruf aber abgewiesen wird. Sie beheben auch keinen fehlenden Rückkanal und keinen Auftrag, der für einen Teilagenten zu unbestimmt formuliert ist. In solchen Fällen sind eine korrigierte Freigabe, ein präziserer Auftrag oder ein serieller Ersatzablauf die direkteren Maßnahmen.

Für die Entscheidung gilt: Bleiben Sie bei Ihrem aktuellen Harness, wenn es die benötigten Fähigkeiten und Aktionen nachweislich bereitstellt und der Minimaltest durchläuft. Wählen Sie einen manuellen Ablauf, wenn die Werkzeuge für Teilaufträge fehlen, die übrige Arbeit aber ausführbar und überprüfbar ist. Prüfen Sie eine andere Umgebung, wenn die benötigte Integration dort dokumentiert ist und Ihr Team die Wechselkosten tragen kann. Wenn Sie für eine klar begrenzte Entwicklungsaufgabe einen entfernten Mac benötigen, kann die Miete bei Hashvps eine Alternative zum Aufbau eines eigenen Testsystems sein. Sie ersetzt keine dauerhafte Hardware, wenn Sie kontinuierliche lokale Verfügbarkeit oder physische Anschlüsse brauchen; vergleichen Sie daher den konkreten Betriebsbedarf, bevor Sie wechseln.

Der sinnvolle nächste Schritt ist nicht, Superpowers pauschal neu zu installieren. Sichern Sie den Befund, ordnen Sie ihn Plugin, Werkzeugrechten oder Sitzung zu und wiederholen Sie genau den Test, der den Fehler sichtbar gemacht hat. So erkennen Sie, ob eine Konfigurationskorrektur genügt oder ob der Ablauf an eine Umgebung gebunden ist, die Ihre benötigten Werkzeuge nicht bereitstellt.