Die Agent-Skills-Spezifikation verlangt im Metadatenbereich zwei Pflichtfelder: name und description (offizielle Spezifikation). Daraus folgt die wichtigste Entscheidung: Agent Skills ist ein Format für wiederverwendbare Anweisungen; Superpowers ist eine konkrete Sammlung von Skills mit einem auf Softwareentwicklung ausgerichteten Ablauf. Sie sind deshalb keine gleichartigen Ersatzprodukte. Nutzen Sie Agent Skills für portable Fähigkeiten, prüfen Sie Superpowers, wenn Sie zusätzliche Prozessführung für Entwurf, Planung, Tests und Prüfung benötigen, und kombinieren Sie beides nur nach einem Test in Ihrem Coding-Harness.
Für Sie, wenn Sie Skills zwischen Coding-Agenten übertragen oder ein Teamverfahren vereinheitlichen möchten: Der Vergleich grenzt Formatkompatibilität von tatsächlich ausführbaren Arbeitsabläufen ab.
Für Verantwortliche laufender Agent-Aufgaben: Sie erhalten einen Testplan für Skill-Erkennung, Werkzeugzugriff und Prüfergebnisse.
Für die Wahl der Entwicklungsumgebung: Die verlinkten Hinweise helfen Ihnen, Projekttrennung und Umgebungsbetrieb gesondert zu bewerten.
Stand der Prüfung: 25.09.2026. Geprüft anhand der an diesem Stichtag verfügbaren offiziellen Spezifikation, Repository- und Installationsdokumentation sowie der Veröffentlichungsübersicht von Superpowers.
Superpowers vs. Agent Skills: erst die Abstraktionsebene klären
Ein häufiger Auswahlfehler besteht darin, Agent Skills und Superpowers als zwei konkurrierende Produktangebote zu behandeln. Agent Skills beschreibt, wie eine Fähigkeit in einem Verzeichnis samt Anweisungsdatei, Metadaten und möglichen Zusatzressourcen organisiert werden kann. Die Spezifikation legt damit eine Struktur fest; sie schreibt nicht vor, dass ein Agent eine bestimmte Softwareentwicklungsroutine erfolgreich ausführt. Die Details zu Pflichtfeldern, optionalen Metadaten und Verzeichnisaufbau finden Sie in der Agent-Skills-Spezifikation.
Superpowers ist dagegen ein konkretes Entwicklungsprojekt: Es bündelt Skills und beschreibt, wie sie in einem Softwareentwicklungsablauf eingesetzt werden. Das offizielle Repository von Superpowers positioniert das Projekt als Entwicklungsmethode mit zugehörigen Skills. Die Arbeitsablaufbeschreibung im README erläutert den vorgesehenen Ablauf. Die praktische Folge für Ihre Auswahl: Sie vergleichen nicht Format gegen Format, sondern ein allgemeines Verpackungs- und Organisationskonzept mit einer konkreten Implementierung, die dieses Konzept und bestimmte Arbeitsweisen verbindet.
| Entscheidungskriterium | Agent Skills | Superpowers |
|---|---|---|
| Grundlegender Zweck | Skills mit Anweisungen und Ressourcen strukturiert beschreiben | Skills und einen softwarebezogenen Ablauf als konkrete Implementierung bereitstellen |
| Abhängigkeit | Die nutzende Umgebung muss das Format erkennen und ausführen können | Das Harness muss die vorgesehene Integration und benötigte Werkzeuge unterstützen |
| Übertragbarkeit | Hängt von Formatunterstützung, Suchpfad und enthaltenen Ressourcen ab | Muss für jedes Ziel-Harness anhand der Integrationsanleitung geprüft werden |
| Prozessführung | Nicht allein durch das Format garantiert | Umfasst dokumentierte Entwicklungsabläufe, deren Ausführung dennoch von der Umgebung abhängt |
| Geeignet, wenn … | Sie Anweisungen zwischen unterstützenden Agenten teilen möchten | Sie einen bestehenden Softwareentwicklungsablauf ergänzen oder vereinheitlichen möchten |
Die zweite Zeile ist für die Praxis entscheidend: Eine Datei kann dem Format entsprechen und trotzdem in einem bestimmten Harness nicht gefunden oder nicht sinnvoll ausgeführt werden. Umgekehrt beweist ein erfolgreicher Lauf in einer Umgebung nicht, dass jede andere Umgebung denselben Suchpfad, dieselben Metadaten oder die nötigen Werkzeuge unterstützt.
Übertragbarkeit anhand der tatsächlichen Ladewege prüfen
Ein Skill-Verzeichnis ist nicht automatisch ein universelles Installationspaket. Prüfen Sie getrennt, ob das Harness den Ablageort durchsucht, die Skill-Datei einliest, Ressourcen relativ zum Skill-Verzeichnis auflösen kann und Anweisungen bei passender Aufgabe tatsächlich aktiviert. Diese Punkte sind verschiedene Kompatibilitätsschichten. Eine positive Antwort auf die Frage nach dem Dateiformat belegt noch keine positive Antwort auf alle übrigen.
Die offizielle Anleitung zum Portieren von Superpowers auf ein neues Harness macht diesen Unterschied praktisch relevant: Für eine neue Umgebung müssen Such- und Ladeverhalten sowie die Integration betrachtet werden. Behandeln Sie die Anleitung daher als Ausgangspunkt für die konkrete Portierung, nicht als pauschale Bestätigung, dass jede Umgebung bereits unterstützt wird. Wenn Sie mit mehreren Coding-Harness arbeiten, führen Sie pro Umgebung eine eigene Kompatibilitätsnotiz: dokumentierter Pfad, erkannte Skill-Datei, verfügbare Werkzeuge und beobachtetes Ergebnis.
| Prüfschicht | Was Sie verifizieren | Häufige Fehlannahme |
|---|---|---|
| Verzeichnis | Das Harness durchsucht den Ort, an dem Sie den Skill abgelegt haben | „Der Ordner liegt im Projekt, also wird er geladen.“ |
| Metadaten | Pflichtfelder werden erkannt und die Beschreibung ist für die Auswahl geeignet | „Eine gültige Datei wird immer automatisch aktiviert.“ |
| Ressourcen | Skripte und Referenzdateien sind relativ zum erwarteten Pfad erreichbar | „Beigepackte Dateien funktionieren in jeder Umgebung unverändert.“ |
| Werkzeugzugriff | Der Agent darf die nötigen Werkzeuge aufrufen | „Eine Anweisung zum Testen startet den Test von selbst.“ |
| Laufzeitverhalten | Der Agent wählt den Skill bei einer passenden Aufgabe aus und befolgt ihn | „Eine Anzeige in der Skill-Liste belegt eine vollständige Ausführung.“ |
Die Spezifikation hilft bei der Organisation, aber sie ersetzt nicht die Integrationsprüfung. Auch eine Dokumentation, die einen Skill-Aufruf beschreibt, sagt nicht zwingend aus, ob die konkrete Laufzeit Zugriff auf Shell, Repository, Testumgebung oder Unteragenten besitzt. Die Skill-Dokumentation für eine unterstützende Laufzeit ist ein Beispiel dafür, dass ein Format und seine Einbindung in eine konkrete Umgebung jeweils separat betrachtet werden sollten. Leiten Sie daraus keine allgemeine Kompatibilitätszusage für andere Harness ab.
Prozessabdeckung nach Entwicklungsaufgabe bewerten
Superpowers wird interessant, wenn Sie nicht nur Anweisungen speichern, sondern wiederkehrende Arbeitsschritte in einen nachvollziehbaren Ablauf bringen möchten. Die offizielle Workflow-Beschreibung legt Wert auf die Klärung eines Vorhabens, Planung, testorientiertes Arbeiten und Prüfung. Für Ihre Bewertung sollten Sie trotzdem unterscheiden: Ein dokumentierter Schritt ist eine Verfahrensvorgabe, kein Beweis, dass der Agent ihn in Ihrer Umgebung ausführen kann.
Die Brainstorming-Skill-Beschreibung betrifft die Klärung eines Vorhabens und der beabsichtigten Lösung. Die Beschreibung des Planungsskills zeigt, wie Arbeit in einen Plan überführt werden soll. Im Team ist das nützlich, wenn „erst Anforderungen klären, dann Änderungen planen“ nicht nur ein mündlicher Hinweis bleiben soll. Entscheidend ist, ob Sie anhand von Ausgaben erkennen können, dass die Schritte tatsächlich eingehalten wurden.
| Entwicklungsaufgabe | Allgemeine Skills | Superpowers als Ablauf | Was Sie im Harness beobachten sollten |
|---|---|---|---|
| Anforderungen klären | Möglich, wenn Sie passende Anweisungen selbst bereitstellen | Dokumentiert einen eigenen Brainstorming-Schritt | Fragt der Agent nach offenen Anforderungen, bevor er Code ändert? |
| Änderungen planen | Kein automatisch vorgegebener Planungsprozess | Enthält eine Beschreibung zum Schreiben von Plänen | Erhalten Sie konkrete, überprüfbare Arbeitsschritte statt einer pauschalen Zusage? |
| Tests und Änderungen steuern | Hängt von Ihren Anweisungen und Werkzeugen ab | Beschreibt testorientiertes Vorgehen im Projektablauf | Werden Tests wirklich ausgeführt, und passen sie zu den Änderungen? |
| Teilaufgaben delegieren | Das Format allein stellt keine Unteragenten bereit | Der Ablauf kann Zusammenarbeit vorsehen | Sind parallele Aufgaben und ihre Ergebnisse im Harness tatsächlich verfügbar? |
| Änderungen prüfen | Kann als eigener Skill ergänzt werden | Sieht Prüf- und Review-Arbeit als Teil des Ablaufs vor | Werden Diff, Testergebnisse und mögliche Seiteneffekte kontrolliert? |
Dieser Vergleich ist keine Rangliste für jede Codeaufgabe. Für eine kleine, klar umrissene Änderung kann ein schlanker eigener Skill ausreichen. Wenn Anforderungen regelmäßig unvollständig sind oder Teammitglieder die Arbeitsschritte unterschiedlich ausführen, können strukturierte Abläufe den Prozess besser nachvollziehbar machen. Unteragenten und Tests helfen jedoch nur, wenn das Harness entsprechende Fähigkeiten und Berechtigungen bietet; ohne Zugriff auf ein Repository oder eine Testausführung bleibt eine Anweisung dazu lediglich Text.
Pflege und Sicherheitsgrenzen im Team festlegen
Ein geteilter Skill wirkt wie Konfiguration und Code: Er kann Verhalten beeinflussen, Ressourcen referenzieren und – abhängig vom Harness – Werkzeugaufrufe anleiten. Prüfen Sie deshalb Quelle, Inhalt und Berechtigungen vor der Übernahme. Behandeln Sie weder ein öffentliches Repository noch eine intern weitergereichte Skill-Datei als automatisch vertrauenswürdig. Besonders wichtig sind Skripte, externe Referenzen, Anweisungen zum Umgang mit Zugangsdaten und Aufforderungen, Änderungen ohne Prüfung zu übernehmen.
Für den Teamalltag hilft eine klare Trennung zwischen offizieller Unterstützung und eigener Betriebsregel. Offizielle Unterstützung bedeutet, dass die jeweilige Dokumentation einen Integrationsweg oder ein Format beschreibt. Ihre Betriebsregel kann dagegen verlangen, dass eine Version festgelegt, ein Update vor Übernahme geprüft und ein Skill zunächst in einer Testumgebung ausgeführt wird. Diese Sicherungen sind sinnvolle Empfehlungen, aber keine Behauptung, dass ein bestimmtes Projekt sie vollständig für Sie umsetzt.
Praktisch können Sie eine interne Freigabe an nachvollziehbare Fragen knüpfen: Ist die Herkunft des Skills bekannt? Sind Änderungen gegenüber der zuvor freigegebenen Fassung sichtbar? Greift ein Skript auf Dateien außerhalb des Projektbereichs zu? Darf der Agent Netzwerkzugriffe ausführen oder Geheimnisse lesen? Wird ein Testlauf protokolliert, ohne vertrauliche Inhalte in nicht genehmigte Systeme zu kopieren? Die Antworten hängen von Ihrer Umgebung, Ihren Verträgen und Ihren Datenschutzvorgaben ab; eine portable Skill-Struktur beantwortet sie nicht von selbst.
Eine Versionsfixierung ist insbesondere dann sinnvoll, wenn mehrere Personen dasselbe Verfahren nutzen oder ein laufendes Projekt reproduzierbar bleiben muss. Prüfen Sie Aktualisierungen anhand der offiziellen Veröffentlichungsübersicht, vergleichen Sie relevante Änderungen mit Ihrer freigegebenen Fassung und testen Sie die neue Version, bevor sie zum Teamstandard wird. Das ist eine Betriebsempfehlung, keine Aussage über eine bestimmte Arbeitszeitersparnis oder eine garantierte Fehlervermeidung.
Mit einem kleinen Harness-Test eine belastbare Wahl treffen
Vermeiden Sie für die erste Prüfung ein produktionskritisches Repository. Nutzen Sie stattdessen ein kleines, isoliertes Projekt mit einer ungefährlichen Aufgabe, deren erwartetes Ergebnis Sie leicht beurteilen können. So können Sie erkennen, ob das Harness lediglich einen Skill anzeigt oder tatsächlich die vorgesehene Arbeit ausführt. Halten Sie Beobachtungen pro Umgebung fest, damit Sie eine spätere Änderung am Ladepfad nicht mit einer Änderung im Skill-Inhalt verwechseln.
-
Dokumentation und Zielpfad erfassen. Prüfen Sie für das konkrete Harness, wo Skills abgelegt werden müssen und wie die Erkennung laut offizieller Anleitung funktioniert. Notieren Sie den Pfad, statt eine Verzeichnisstruktur aus einer anderen Umgebung zu übernehmen. Bei einer Superpowers-Portierung dient die offizielle Portierungsanleitung als projektspezifischer Bezugspunkt.
-
Datei und Metadaten kontrollieren. Legen Sie eine einzelne, risikoarme Skill-Datei ab. Kontrollieren Sie die geforderten Metadaten und stellen Sie sicher, dass Beschreibung, Referenzen und gegebenenfalls Skriptpfade zum gewählten Aufbau passen. Trennen Sie die Prüfung auf gültige Struktur von der Frage, ob das Harness den Skill tatsächlich findet.
-
Erkennung sichtbar machen. Stellen Sie eine Aufgabe, für die der Skill eindeutig relevant ist, und bitten Sie den Agenten, die verwendete Fähigkeit und ihre maßgebliche Anweisung zu benennen. Erscheint der Skill nicht, prüfen Sie zuerst Suchpfad und Aktivierungsbedingungen. Eine bloße Antwort des Agenten ist noch kein Beleg für korrekte Ausführung; vergleichen Sie sie mit der Datei.
-
Werkzeuge bewusst testen. Fordern Sie eine harmlose Aktion an, die im Skill vorgesehen ist, etwa eine Änderung in einer temporären Datei oder eine einfache lokale Prüfung. Kontrollieren Sie, ob der Agent das Werkzeug tatsächlich aufruft, ob die Berechtigung ausreicht und ob die Wirkung auf das Testprojekt begrenzt bleibt. Dokumentiert der Skill einen Schritt, den das Harness nicht ausführen kann, ist das eine Funktionslücke, kein Formatfehler.
-
Tests und Ergebnisse prüfen. Lassen Sie eine für die Aufgabe passende Prüfung ausführen und sehen Sie sich Ausgabe sowie geänderte Dateien selbst an. Ein vom Agenten formulierter Satz wie „Tests bestanden“ ersetzt weder den Aufruf noch dessen nachvollziehbares Ergebnis. Halten Sie auch fest, wenn der Agent einen Test nicht starten konnte oder eine Rückfrage nötig war.
-
Review und Rückfall festlegen. Prüfen Sie die Änderungen, mögliche Nebeneffekte und die Übereinstimmung mit Ihrem Teamprozess. Wenn Skill-Erkennung, benötigte Werkzeuge oder Prüfung nicht zuverlässig funktionieren, verwenden Sie zunächst nur den tragenden Skill-Teil oder wechseln Sie zu einem anderen Ablauf. Geben Sie die Umgebung erst frei, wenn Sie die beobachteten Grenzen dokumentiert haben.
Auswahl nach Einsatzfall
Nutzen Sie diese Abzweigungen als Entscheidungshilfe, statt ein einziges Werkzeug für alle Situationen festzulegen:
- Wenn Sie eine wiederverwendbare Anweisung zwischen unterstützenden Harness übertragen möchten und keinen umfassenden Entwicklungsablauf benötigen, wählen Sie zunächst Agent Skills. Prüfen Sie Format, Suchpfad und Werkzeugzugriff in jeder Zielumgebung separat.
- Wenn Sie wiederkehrend Anforderungen klären, Änderungen planen, testorientiert arbeiten und Ergebnisse prüfen müssen, evaluieren Sie Superpowers. Übernehmen Sie die Schritte nicht als bloße Konvention, sondern testen Sie, ob Ihr Harness sie mit den verfügbaren Werkzeugen ausführen kann.
- Wenn Ihr Team ein einheitliches Verfahren benötigt und zugleich Fähigkeiten zwischen Umgebungen teilen will, kombinieren Sie beides nur nach einem Pilotlauf. Legen Sie fest, welcher Teil das Format bereitstellt und welcher Teil den Ablauf steuert; prüfen Sie, dass sich Anweisungen nicht widersprechen.
- Wenn Ihr Harness die Skill-Dateien nicht findet oder erforderliche Werkzeuge verweigert, wechseln Sie nicht sofort die Formatdefinition. Klären Sie zuerst Integration und Berechtigungen; andernfalls testen Sie einen unterstützten Ladeweg oder verwenden Sie einen manuellen, prüfbaren Ablauf.
Fallbeispiel: Wechsel zwischen zwei Coding-Harness
Angenommen, Sie pflegen einen Skill, der eine Codeänderung erst nach einer kurzen Anforderungsklärung und einem Testlauf freigibt. Im ersten Harness wird der Skill erkannt und der Test tatsächlich gestartet. Nach dem Wechsel in eine zweite Umgebung liegt dieselbe Datei zwar im Projekt, doch der Agent verwendet sie nicht. Daraus folgt weder, dass das Format nutzlos ist, noch dass die zweite Umgebung grundsätzlich inkompatibel ist. Zuerst prüfen Sie den dokumentierten Suchpfad, dann die Sichtbarkeit der Metadaten und zuletzt die verfügbaren Werkzeuge.
Falls die Datei gefunden wird, aber der Agent keine Tests starten darf, haben Sie eine andere Grenze entdeckt: Der Ladeweg funktioniert, die Prozessausführung aber nicht vollständig. Falls auch die Skillsuche nicht funktioniert, kann die Portierung Anpassungen an der Integration benötigen. Halten Sie diese Ergebnisse getrennt fest; nur so bleibt erkennbar, ob Sie ein Problem mit dem Format, der Harness-Integration oder den Berechtigungen lösen müssen.
Für den Betrieb gehört außerdem die Projektisolation zur Auswahl. Wenn ein Agent an mehreren Repositories arbeitet, sollten Sie Berechtigungen, Dateizugriff und Laufzeit so begrenzen, dass eine versehentliche Änderung nicht ungeprüft auf andere Projekte übergreift. Der Beitrag zur Konfiguration einer Mac-Umgebung ist relevant, wenn Sie dafür eine getrennte Entwicklungsumgebung prüfen. Für Fragen zu Nutzung und Betrieb steht außerdem das Hilfezentrum bereit.
