Superpowers: zdyscyplinowany proces tworzenia oprogramowania z agentami
Superpowers to opiniowany proces tworzenia oprogramowania dla agentów programistycznych. Skłania agenta do doprecyzowania problemu, uzgodnienia projektu, odizolowania pracy, napisania wykonywalnego planu, implementacji z testami, poproszenia o review oraz przedstawienia świeżych dowodów weryfikacji, zanim ogłosi zakończenie.
To rozróżnienie jest istotne. Superpowers nie jest modelem, serwerem MCP ani jedynie katalogiem promptów. Czternaście skilli to przenośne instrukcje w Markdownie, lecz dopiero bootstrap pluginu i adaptery środowisk sprawiają, że agent sprawdza i stosuje je we właściwym momencie. Samo skopiowanie plików skilli nie zawsze jest więc równoważne instalacji kompletnego pluginu.
W skrócie
Dział zatytułowany „W skrócie”- Superpowers daje najwięcej przy niejednoznacznych, wieloplikowych i testowalnych zadaniach, w których zbudowanie niewłaściwej rzeczy jest kosztowne.
- Domyślna ścieżka to: brainstorming → zatwierdzony projekt → odizolowany worktree → szczegółowy plan → implementacja zadanie po zadaniu z TDD i review → końcowa weryfikacja → merge albo PR.
- Aktualne stabilne wydanie zawiera 14 skilli i dokumentuje dziesięć celów instalacji: Claude Code, Codex App, Codex CLI, Cursor oraz sześć innych hostów.
- Projekt steruje probabilistycznym zachowaniem modelu, lecz nie tworzy twardej granicy polityki. Agent nadal może pominąć test, źle zrozumieć regułę albo zachowywać się inaczej po aktualizacji modelu lub hosta.
- Publiczne dowody wyglądają obiecująco dla zgodności z procesem, zwłaszcza weryfikacji, ale nie istnieje duży niezależny benchmark potwierdzający, że cały zestaw zawsze poprawia jakość kodu lub koszt.
- Pełny proces ma realny narzut. Wdrażaj go świadomie, mierz na własnych zadaniach i zachowaj zatwierdzenia człowieka, CI oraz code review.
Czym naprawdę jest Superpowers
Dział zatytułowany „Czym naprawdę jest Superpowers”Superpowers opublikowali Jesse Vincent i Prime Radiant w październiku 2025 roku. Repozytorium jest objęte licencją MIT. W migawce z 11 lipca 2026 miało około 252 000 gwiazdek GitHub i 22 500 forków. Liczby te pokazują nadzwyczajne zainteresowanie, a nie zweryfikowaną liczbę aktywnych użytkowników ani skuteczność.
System ma trzy warstwy:
- Skille definiują wielokrotnego użytku procedury, między innymi brainstorming, TDD, systematyczne debugowanie i weryfikację.
using-superpowersjest bootstrapem. Nakazuje agentowi sprawdzić, czy istnieje właściwy skill, zanim odpowie, zada pytanie, przejrzy repozytorium lub podejmie działanie.- Adaptery środowisk mapują abstrakcyjne akcje — czytanie plików, uruchamianie subagentów czy start sesji — na Claude Code, Codex, Cursor i inne hosty.
Upstreamowy przewodnik portowania wprost wyjaśnia, dlaczego druga i trzecia warstwa są ważne: pliki skilli leżące na dysku pozostają bezczynne, jeśli host ich nie odkryje, a agent nie wywoła ich we właściwym momencie.
Superpowers stosuje ścisłą hierarchię pierwszeństwa:
- bezpośrednie instrukcje użytkownika;
- instrukcje repozytorium i projektu;
- pasujące skille Superpowers;
- domyślne zachowanie agenta.
W obrębie warstwy skilli procedury procesu mają pierwszeństwo przed instrukcjami implementacyjnymi. Jeżeli istnieje choć niewielka szansa, że skill pasuje do zadania, bootstrap nakazuje najpierw go załadować. Dlatego plugin przypomina bardziej procedurę operacyjną tworzenia oprogramowania niż opcjonalną bibliotekę promptów.
Aktualna wersja i rozjazd kanałów dystrybucji
Dział zatytułowany „Aktualna wersja i rozjazd kanałów dystrybucji”W chwili weryfikacji upstreamowy branch main odpowiadał tagowi v6.1.1 i commitowi d884ae0. Nie wszystkie kanały dystrybucji miały tę samą wersję:
| Kanał | Stan zaobserwowany 11 lipca 2026 | Znaczenie |
|---|---|---|
| Repozytorium upstream | 6.1.1 | Implementacja referencyjna opisana w tym przewodniku |
| Oficjalny marketplace Claude | Przypięty do commita v6.1.1 | Aktualna stabilna treść upstream |
| Repozytorium pluginów OpenAI Codex | Manifest raportował 5.1.3 | Codex Marketplace mógł instalować starsze zachowanie |
| Strona Cursor Marketplace | Nadal pokazywała usunięte komendy i nazwanego agenta-reviewera | Listing lub pakiet był starszy niż bieżący upstream |
skills.sh | Indeksował 14 osobnych plików skilli | Przydatne do odkrywania skilli i orientacyjnej adopcji, nie dowodzi pełnej integracji pluginu |
Przed diagnozowaniem zachowania sprawdź manifest pluginu OpenAI, manifest marketplace’u Claude i lokalnie zainstalowany manifest. Strona marketingowa marketplace’u może być starsza niż jego pakiet — albo odwrotnie.
To również wyjaśnia sprzeczną dokumentację w sieci. Strona pluginu Claude i listing Cursora nadal wspominają slash commands takie jak /brainstorming oraz nazwanego code-reviewer. Upstream usunął stare komendy i nazwanego reviewera w v5.1.0. Aktualne skille powinny uruchamiać się na podstawie zadania i procesu, a nie tych wycofanych komend.
Instalacja
Dział zatytułowany „Instalacja”Preferuj natywny mechanizm pluginów danego środowiska. Instaluje on bootstrap i adapter obok wspólnych skilli.
Użyj oficjalnego marketplace’u Claude:
/plugin install superpowers@claude-plugins-officialMożesz też dodać marketplace upstream i zainstalować plugin z niego:
/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplaceOtwórz Plugins w panelu bocznym, znajdź Superpowers i wybierz przycisk z plusem. Następnie sprawdź numer zainstalowanej wersji, ponieważ marketplace OpenAI może pozostawać za upstreamem.
Otwórz przeglądarkę pluginów:
/pluginsWyszukaj superpowers i zainstaluj plugin. Aktualna integracja upstream dla Codex celowo korzysta z natywnego wykrywania skilli i deklaruje pusty zestaw hooków; v6.1.1 naprawiło przypadkowe wykrywanie hooka sesji Claude.
Zainstaluj z interfejsu pluginów Cursora:
/add-plugin superpowersPo instalacji porównaj lokalny manifest i dostępne skille z upstreamem. Publiczny listing marketplace’u był nieaktualny w chwili researchu.
Stabilne v6.1.1 dokumentuje również te hosty:
| Środowisko | Upstreamowa ścieżka instalacji |
|---|---|
| Antigravity | agy plugin install https://github.com/obra/superpowers |
| Factory Droid | Dodaj marketplace Superpowers, następnie zainstaluj superpowers@superpowers |
| GitHub Copilot CLI | Dodaj obra/superpowers-marketplace, następnie zainstaluj plugin |
| Kimi Code | Interfejs pluginów albo /plugins install https://github.com/obra/superpowers |
| OpenCode | Wykonaj instrukcję instalacji OpenCode z repozytorium |
| Pi | pi install git:github.com/obra/superpowers |
Przed skopiowaniem komendy sprawdź aktualną macierz instalacji upstream.
Dlaczego npx skills add nie zawsze jest równoważne
Dział zatytułowany „Dlaczego npx skills add nie zawsze jest równoważne”Poniższa ogólna komenda może skopiować 14 przenośnych skilli do hosta rozumiejącego format Agent Skills:
npx skills add obra/superpowersMoże to być przydatne, gdy chcesz tylko wybrane pliki skilli, ale instalacja może pominąć manifest pluginu, bootstrap sesji, hooki, mapowanie narzędzi lub ponowne uruchomienie bootstrapu po kompaktowaniu kontekstu. Dokładna różnica zależy od hosta. Użyj natywnego pluginu, jeżeli chcesz kompletny proces Superpowers; instalatora skilli używaj świadomie, gdy potrzebujesz wyłącznie przenośnych instrukcji.
Domyślny cykl pracy
Dział zatytułowany „Domyślny cykl pracy”- Odkryj problem i zaprojektuj rozwiązanie z
brainstorming. Agent przegląda kontekst, zadaje po jednym pytaniu, przedstawia dwa lub trzy podejścia z kompromisami i uzyskuje zatwierdzenie sekcja po sekcji. Zapisuje zaakceptowany projekt wdocs/superpowers/specs/YYYY-MM-DD-<temat>-design.mdi przegląda dokument przed przejściem dalej. - Odizoluj pracę przez
using-git-worktrees. Agent najpierw wykrywa, czy środowisko utworzyło już odizolowany workspace. W przeciwnym razie stosuje preferencje repozytorium, pyta przed utworzeniem nowego worktree, sprawdza ignorowanie jego katalogu, instaluje zależności i uruchamia testy bazowe. - Napisz wykonywalny plan z
writing-plans. Plan zapisuje globalne ograniczenia, interfejsy, dokładne ścieżki plików, kompletne fragmenty testów i implementacji, komendy, oczekiwane wyniki oraz małe zadania na dwie do pięciu minut. Trafia dodocs/superpowers/plans/. - Wybierz sposób wykonania.
subagent-driven-developmentpozostaje w bieżącej sesji, gdy host potrafi tworzyć subagentów. Świeży implementer realizuje każde zadanie sekwencyjnie, po czym pracę sprawdza reviewer tylko do odczytu.executing-planswykonuje zapisany plan w osobnej sesji z checkpointami review. - Stosuj rygorystyczne TDD. Przy zmianach zachowania
test-driven-developmentwymaga zaobserwowania testu, który nie przechodzi z właściwego powodu, wykonania najmniejszej zmiany prowadzącej do sukcesu i refaktoryzacji na zielono. Kod produkcyjny napisany przed testem powinien zostać odrzucony, chyba że człowiek jawnie dopuści wyjątek. - Przeglądaj każde zadanie i cały branch. Aktualne
v6używa jednego reviewera zadania, który zwraca dwa werdykty — zgodność ze specyfikacją i jakość kodu — a następnie uruchamia finalny review całego brancha. Ważne uwagi muszą zostać poprawione i sprawdzone ponownie. - Przedstaw świeże dowody.
verification-before-completionwymaga faktycznego wyniku właściwej komendy testu, buildu, type-checkingu lub lintu przed jakimkolwiek stwierdzeniem sukcesu. - Zakończ świadomie.
finishing-a-development-branchponownie uruchamia testy, wykrywa, czy praca odbywa się w worktree, i proponuje wyraźne opcje: lokalny merge, push i otwarcie PR, pozostawienie brancha albo jego odrzucenie. Destrukcyjne sprzątanie wymaga potwierdzenia.
Proces celowo ponosi większy koszt na początku. Przed powstaniem kodu ogranicza niejednoznaczność, a po jego napisaniu redukuje fałszywą pewność przez pętle testów i review.
Konkretny przykład: od niejasnego żądania do PR
Dział zatytułowany „Konkretny przykład: od niejasnego żądania do PR”Załóżmy, że początkowe żądanie brzmi:
Dodaj klucze API na poziomie organizacji, ich rotację i historię audytową.
Poprawnie działająca sesja Superpowers powinna wytworzyć obserwowalne artefakty i checkpointy:
| Etap | Oczekiwany rezultat | Checkpoint człowieka |
|---|---|---|
| Brainstorming | Pytania o właściciela, widoczność klucza, unieważnianie, uprawnienia, retencję i migrację; dwa lub trzy warianty projektu | Zatwierdź zachowanie i model zagrożeń |
| Projekt | docs/superpowers/specs/2026-07-11-organization-api-keys-design.md | Przejrzyj trwałą specyfikację |
| Izolacja | Czysty worktree z przechodzącym baseline’em | Zdecyduj, czy zaakceptować istniejący błąd testów |
| Plan | Dokładne zadania dla schematu, API, UI, testów, migracji i dokumentacji w docs/superpowers/plans/… | Zatwierdź zakres i strategię implementacji |
| Wykonanie | Nieprzechodzący test, minimalna implementacja, przechodzący test, commit i raport review dla każdego zadania | Rozstrzygnij pytania produktowe i ważne uwagi |
| Finalny review | Werdykty zgodności i jakości całego brancha | Zdecyduj, czy branch jest gotowy |
| Weryfikacja | Świeży wynik migracji, testów, type-checkingu, lintu i buildu | Potwierdź dowody gotowości |
| Zakończenie | Merge, PR, pozostawienie lub odrzucenie | Wybierz ścieżkę integracji |
Wartością nie jest samo to, że agent „zrobił plan”. Projekt, plan, wyniki testów i uwagi review pozostają możliwe do sprawdzenia po skompaktowaniu rozmowy albo przekazaniu pracy innej osobie.
Czternaście skilli
Dział zatytułowany „Czternaście skilli”| Skill | Moment użycia i odpowiedzialność |
|---|---|
using-superpowers | Bootstrap sesji; sprawdza właściwe skille przed merytoryczną odpowiedzią lub działaniem |
brainstorming | Nowe zachowanie lub twórcza praca; zamienia pomysł w zatwierdzony projekt |
using-git-worktrees | Rozpoczyna implementację w odizolowanym workspace ze zweryfikowanym baseline’em |
writing-plans | Zamienia zatwierdzony projekt w małe, wykonywalne zadania |
subagent-driven-development | Wykonuje zadania planu przez świeżych implementerów, review zadań i finalny review |
executing-plans | Realizuje zapisany plan w osobnej sesji z checkpointami review |
test-driven-development | Wymaga zaobserwowanego RED → minimalnego GREEN → REFACTOR przy zmianach zachowania |
systematic-debugging | Diagnozuje przyczynę źródłową przed zaproponowaniem poprawki |
dispatching-parallel-agents | Równolegle prowadzi niezależne badania bez wspólnego modyfikowalnego stanu |
requesting-code-review | Przekazuje świeżemu reviewerowi opis zmiany, wymagania i zakres commitów |
receiving-code-review | Technicznie weryfikuje feedback przed jego przyjęciem lub odrzuceniem |
verification-before-completion | Blokuje twierdzenia bez dowodów, takie jak „testy przechodzą” czy „naprawione” |
finishing-a-development-branch | Po zweryfikowanej implementacji przedstawia bezpieczne opcje integracji i sprzątania |
writing-skills | Stosuje test-driven development do samych instrukcji sterujących agentem |
Systematyczne debugowanie w czterech fazach
Dział zatytułowany „Systematyczne debugowanie w czterech fazach”Skill debugowania ma powstrzymywać pętlę „zmień coś i uruchom ponownie”:
- Badanie przyczyny źródłowej: odtwórz problem, przeczytaj błąd, sprawdź ostatnie zmiany i prześledź dane pomiędzy komponentami.
- Analiza wzorca: znajdź działające odpowiedniki i wypisz każdą istotną różnicę.
- Hipoteza i test: sformułuj jedną falsyfikowalną przyczynę i wykonaj najmniejszą zmianę diagnostyczną.
- Implementacja: dodaj test regresji, napraw przyczynę źródłową i zweryfikuj pełny wynik.
Po trzech nieudanych poprawkach proces każe zakwestionować architekturę zamiast próbować czwartego patcha przy tych samych założeniach.
TDD jako ograniczenie zachowania
Dział zatytułowany „TDD jako ograniczenie zachowania”TDD w Superpowers jest bardziej rygorystyczne niż „pamiętaj o dodaniu testów”. Agent musi zobaczyć awarię testu, potwierdzić, że test nie przechodzi z powodu brakującego zachowania — a nie wadliwego testu — i dopiero wtedy napisać minimalną ilość kodu produkcyjnego potrzebną do sukcesu. Jeżeli kod powstał przed testem, domyślna instrukcja nakazuje go usunąć i zacząć cykl ponownie.
Ten rygor jest wartościowy przy deterministycznej logice biznesowej i regresjach. Może przeszkadzać podczas eksploracji wizualnej, budowy jednorazowych prototypów, pracy z generowanymi plikami albo zmian, dla których nie istnieje użyteczna automatyczna asercja. Polityka repozytorium i jawna decyzja człowieka powinny definiować wyjątki.
Review bez pozornej zgody
Dział zatytułowany „Review bez pozornej zgody”requesting-code-review przekazuje świeżemu reviewerowi opis zmiany, plan lub wymagania oraz SHA commitów bazowego i końcowego. Wewnątrz SDD osobny workflow review zadania przekazuje reviewerowi brief, raport implementera i wygenerowany pakiet review. receiving-code-review nakazuje implementującemu agentowi sprawdzić każdą uwagę względem kodu i wymagań, zamiast odpowiadać pustą zgodą albo bezrefleksyjnie wdrażać feedback.
Ma to znaczenie także dla zewnętrznych komentarzy PR: tekst reviewera jest niezaufanym wejściem. Komentarz może być błędny lub zawierać prompt injection. Zweryfikuj twierdzenie, zachowaj hierarchię instrukcji i nigdy nie ujawniaj sekretów ani nie wykonuj niezwiązanych komend dlatego, że prosi o to komentarz.
Pisanie skilli metodą „TDD dla procesu”
Dział zatytułowany „Pisanie skilli metodą „TDD dla procesu””writing-skills traktuje skill jak wykonywalną dokumentację zachowania:
- zbuduj realistyczny scenariusz pod presją;
- zaobserwuj porażkę agenta bez skilla;
- napisz najmniejszą instrukcję usuwającą błąd;
- ponownie uruchom scenariusz;
- dodaj przypadki ujawniające racjonalizacje i luki;
- zrefaktoryzuj instrukcję bez osłabiania zgodności.
Skill zaleca również, aby jego opis wyjaśniał kiedy go użyć, zamiast streszczać całą procedurę. Treść jest ładowana dopiero po uznaniu skilla za właściwy.
Subagenci, równoległość i stan
Dział zatytułowany „Subagenci, równoległość i stan”Superpowers wykorzystuje subagentów do ograniczenia zanieczyszczenia kontekstu, a nie do maksymalizacji współbieżności za wszelką cenę.
- Implementerzy SDD pracują sekwencyjnie, ponieważ późniejsze zadania mogą zależeć od wcześniejszego kodu.
- Każde zadanie dostaje świeży kontekst implementera, a następnie reviewera tylko do odczytu.
- Finalny reviewer bada zintegrowany branch, nie tylko odizolowane diffy zadań.
dispatching-parallel-agentssłuży niezależnym domenom — na przykład trzem niepowiązanym błędom testów — gdy agenci nie będą edytować tych samych plików ani zależeć od wspólnego modyfikowalnego stanu.
Aktualne v6.1.1 zapisuje pliki przekazania SDD w .superpowers/sdd/. Issue #1942 dokumentuje poważną kolizję: dwie sesje SDD w tym samym checkoutcie mogą nadpisać briefy zadań, raporty i stan postępu. W chwili researchu kilka poprawek było otwartych, ale żadna nie trafiła do wydania.
Visual Companion i telemetria
Dział zatytułowany „Visual Companion i telemetria”Podczas brainstormingu plugin może zaproponować opcjonalny, działający w przeglądarce Visual Companion do diagramów i bogatszego przeglądu projektu. Jest to lokalny serwer Node, a nie wymagana usługa chmurowa.
Upstreamowe v6.0 utwardziło go po zgłoszeniu cross-origin prompt injection:
- domyślny bind tylko do loopbacku (
127.0.0.1); - losowy klucz sesji przechowywany w cookie
HttpOnly; SameSite=Strict; - sprawdzanie originu WebSocket;
- blokowanie path traversal, symlinków i dotfiles;
- nagłówki no-store i chroniące przed osadzaniem;
- uprawnienia tylko dla właściciela przy wrażliwych plikach;
- automatyczne wyłączenie po okresie bezczynności;
- jawna zgoda przed otwarciem przeglądarki.
Bind do 0.0.0.0 w celu zdalnego dostępu poszerza granicę zaufania. Używaj go tylko wtedy, gdy to konieczne, i chroń klucz sesji.
Companion domyślnie pobiera logo Prime Radiant z numerem wersji Superpowers w adresie. Projekt deklaruje, że nie wysyła treści projektu, promptów, tożsamości agenta ani zdarzeń interakcji. Wyłącz żądanie, jeżeli wymaga tego polityka:
export SUPERPOWERS_DISABLE_TELEMETRY=trueObsługiwane są również DISABLE_TELEMETRY i CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. Zobacz upstreamowy opis telemetrii.
Co zmieniło się ostatnio
Dział zatytułowany „Co zmieniło się ostatnio”| Wydanie | Istotna zmiana |
|---|---|
v5.1.0 | Usunięto stare slash commands i nazwanego agenta-reviewera; dodano zgodę oraz wykrywanie natywnego worktree |
v6.0.0 | Połączono dwóch reviewerów zadania w jednego reviewera z dwoma werdyktami; dodano finalny review brancha, przekazania oparte na plikach, jawny wybór modelu, nowe hosty i utwardzenie Visual Companion |
v6.0.3 | Przeniesiono przekazania SDD z chronionych wnętrz Git do .superpowers/sdd/, co później ujawniło kolizję równoległych sesji |
v6.1.0 | Skrócono instrukcje bootstrapu, dodano manifest marketplace’u Codex i natywną ścieżkę instalacji, usunięto hook sesji Codex i wycofano Gemini ze stabilnego wsparcia |
v6.1.1 | Zadeklarowano puste hooki Codex, aby uniknąć wykrycia hooka Claude, i udeterministyczniono pakowanie Codex |
Wydanie v6 deklarowało podobną jakość procesu przy mniej więcej dwukrotnie większej szybkości i niemal połowie tokenów dla Claude Code i Codex w scenariuszach projektu. Szczegółowy dziennik eksperymentów kosztowych ostrzega, że wariancja pomiędzy przebiegami jest duża, różnice poniżej około 20% mogą być szumem przy pojedynczych uruchomieniach, a przygotowane fixture plans potrafią zniekształcić koszt bezwzględny. Traktuj nagłówek jako wewnętrzny wynik v6 wobec wcześniejszego Superpowers, nie jako gwarancję w porównaniu z agentem bez pluginu.
Dowody: co wiemy, a czego nie
Dział zatytułowany „Dowody: co wiemy, a czego nie”Ewaluacje prowadzone przez projekt
Dział zatytułowany „Ewaluacje prowadzone przez projekt”Quorum / superpowers-evals uruchamia rzeczywiste CLI agentów w scenariuszach sprawdzających triggering skilli, worktrees, TDD, subagentów, review, weryfikację i koszt. Najlepiej rozumieć je jako laboratorium zgodności z procesem, a nie ogólny benchmark programowania.
Eksperyment pełnego zestawu na pięciu agentach raportował następujące bezwzględne wskaźniki zaliczenia na migawce gałęzi deweloperskiej:
| Środowisko | Raportowany wynik |
|---|---|
| Claude | 84% |
| Codex | 78% |
| Pi | 76% |
| Kimi | 74% |
| OpenCode | 71% |
W całym zestawie odnotowano 189 zaliczeń, 57 porażek i 6 wyników nierozstrzygniętych. Błędy skupiały się wokół kosztu, nadmiernego uruchamiania skilli i rozumienia specyfikacji. Nie było grupy kontrolnej bez pluginu, więc liczby porównują zgodność hostów z testowanym workflow, a nie poprawę wywołaną przez Superpowers.
Komendy live evaluations uruchamiają agentów w szeroko uprawnionych lub „niebezpiecznych” trybach wewnątrz tymczasowego HOME. Repozytorium wyraźnie zaznacza, że nie jest to pełny sandbox; publiczne CI uruchamia testy infrastruktury i statyczne kontrole, a nie każdy eksperyment z żywym agentem.
Niezależne ewaluacje
Dział zatytułowany „Niezależne ewaluacje”Najbardziej ustrukturyzowane zewnętrzne dowody dostępne w chwili researchu pochodziły z Tessl:
verification-before-completionosiągnął średnio 1,22× wyniku bazowego i 92% w trzech scenariuszach, głównie dzięki przedstawianiu rzeczywistego outputu komend i wiązaniu twierdzeń z dowodami.brainstormingosiągnął średnio tylko 1,05× w trzech scenariuszach; jeden poprawił się wyraźnie, dwa uzyskały gorszy wynik, a scenariusz Visual Companion dostał zero. Strona wskazuje commit896224c, czyli inną migawkę deweloperską niż stabilnev6.1.1.
Trzy scenariusze na skill to mała próba, a Tessl nie opublikował testów wpływu na zachowanie dla większości pozostałych 12 skilli. Wyniki mocniej wspierają celowaną weryfikację niż cały proces.
Mały eksperyment Nate’a Herka obejmujący 12 przebiegów raportował o 9% niższy koszt, o 14% mniej tokenów, mniejszą wariancję i lepszą strukturę z Superpowers, ale również około 8% narzutu przy prostych zadaniach oraz brak poprawy wiedzy domenowej i zgodności ze specyfikacją. Testował trzy małe zadania na wersji sprzed v6; autor określił wynik jako kierunkowy, nie rozstrzygający.
Praktyczne porównania są mieszane:
- AI Unleashed otrzymało podobne aplikacje po około 25 minutach z Superpowers i 10 minutach bez niego; oba warianty pominęły wymaganie, natomiast reviewer Superpowers wykrył rzeczywisty błąd logiczny.
- Chase AI zaobserwował około 60 minut i 250 tys. tokenów dla Superpowers wobec 20 minut i 200 tys. bez pluginu w pojedynczym teście aplikacji, lecz wynik Superpowers działał przy pierwszej próbie.
- Przepisanie
chardet7 jest imponującym realnym przypadkiem: maintainer używał Superpowers i Opus przez cztery dni przed wydaniem raportującym duże wzrosty wydajności. Nie był to test A/B, a późniejszy spór o licencje i pochodzenie kodu pokazuje, dlaczego nadal konieczny jest ludzki przegląd prawny i utrzymaniowy.
Niezależny benchmark akademicki SWE-Skills-Bench nie testował Superpowers z nazwy. Wśród 49 innych skilli programistycznych średnia poprawa wyniosła tylko 1,2%, 39 nie przyniosło wzrostu pass rate, narzut tokenów sięgał 451%, a niezgodności wersji czasem pogarszały wynik. Uprawniony wniosek jest ogólny: efekty skilli zależą od modelu, hosta, wersji i zadania. Nie jest to dowód ani za, ani przeciw konkretnie Superpowers.
Raporty społeczności
Dział zatytułowany „Raporty społeczności”Doświadczenia społeczności powtarzają ten sam kompromis. Evan Schwartz chwalił iteracyjne pytania, jawne alternatywy, trwałe dokumenty projektowe i świeżych reviewerów. Duża mieszana dyskusja na Reddicie obejmuje użytkowników ceniących spójność, takich, którzy zachowali tylko brainstorming, oraz osoby uznające współczesne natywne tryby planowania za wystarczające. Dyskusja Hacker News o v6 podobnie łączy pochwały TDD i opublikowanych ewaluacji z obawami o narzut i ograniczone niezależne dowody.
Są to przydatne opisy usterek i preferencji, a nie reprezentatywne pomiary.
Koszty i znane ograniczenia
Dział zatytułowany „Koszty i znane ograniczenia”Czas, tokeny i liczba artefaktów
Dział zatytułowany „Czas, tokeny i liczba artefaktów”Proces celowo dodaje pytania, dokument projektu, plan, cykle testów, prompty subagentów, review i komendy weryfikacyjne. Ta inwestycja może zapobiec kosztownym poprawkom dużej funkcjonalności. Przy zmianie dwóch linii może zdominować całe zadanie.
Plany są wyjątkowo szczegółowe: aktualny writing-plans żąda kompletnego kodu, testów, komend i oczekiwanego outputu. Issue #895 argumentuje, że może to skłaniać executora do kopiowania rozwiązania zamiast rozumowania. Maintainer uznaje szczegółowość za zamierzoną, ponieważ pozwala działać tańszym lub słabszym executorom. Właściwy kompromis zależy od zestawu modeli i procesu review.
Zmienność hostów i modeli
Dział zatytułowany „Zmienność hostów i modeli”Ta sama instrukcja Markdown może inaczej wybierać narzędzia i osiągać inny poziom zgodności zależnie od hosta i wydania modelu. Natywne planowanie, subagenci, obsługa worktrees, interfejs zatwierdzeń i kompaktowanie kontekstu różnią się między środowiskami. Ponownie oceń workflow po zmianie modelu, hosta albo pluginu; nie zakładaj, że zeszłomiesięczne zachowanie jest stałe.
Nieprzechodzący baseline
Dział zatytułowany „Nieprzechodzący baseline”Konfiguracja worktree uruchamia bazowe testy, aby odróżnić nowe błędy od istniejących. Jeżeli baseline jest czerwony, agent musi zatrzymać się i zapytać, czy kontynuować. Naprawianie niezwiązanych usterek bez autoryzacji zmieniłoby zakres zadania, a ich ciche zignorowanie uczyniłoby późniejsze dowody niejednoznacznymi.
Konflikty z polityką repozytorium
Dział zatytułowany „Konflikty z polityką repozytorium”Twoje AGENTS.md, CLAUDE.md, podręcznik inżynierski, bramki CI i proces wydawniczy mają pierwszeństwo. Sprzeczności rozwiązuj jawnie. Krótkie żądanie „po prostu to napraw” nie powinno być uznawane za wiarygodne globalne wyłączenie procesu; określ, które fazy świadomie skracasz i jakie kontrole bezpieczeństwa pozostają.
Otwarte problemy techniczne
Dział zatytułowany „Otwarte problemy techniczne”- #1942: równoległe sesje SDD mogą kolidować w
.superpowers/sdd/. - #1918: hook startu sesji w Windows może nie działać, gdy ścieżka profilu zawiera nawias.
- #1773: neutralne platformowo instrukcje brainstormingu mogą wywołać regresje interakcji specyficzne dla hosta.
- #992:
writing-plansoferuje wybór trybu wykonania, podczas gdyexecuting-plansmoże przekierować do SDD, gdy subagenci są dostępni.
Sprawdź, czy problemy zostały zamknięte w instalowanym wydaniu.
Bezpieczeństwo i łańcuch dostaw
Dział zatytułowany „Bezpieczeństwo i łańcuch dostaw”Skille agentów są w praktycznym sensie wykonywalnymi instrukcjami: mogą nakłonić agenta z dostępem do repozytorium, shella, Git i sieci do podjęcia działań. Audytuj je jak kod.
W przypadku Superpowers:
- główny
package.jsonnie ma zależności runtime; - opcjonalny Visual Companion zawiera wykonywalny kod serwera;
- integracje Claude, Cursor i Copilot mogą używać hooków startu sesji;
- Codex
v6.1.1jawnie deklaruje brak hooków; - komentarze review, treści issues, strony WWW i kopiowane plany pozostają niezaufaną treścią;
- pakiety marketplace’ów mogą pozostawać za upstreamem lub zmieniać się niezależnie.
Badanie całego ekosystemu Agent Skills in the Wild oznaczyło potencjalnie niebezpieczne wzorce w 26,1% z 31 132 przeskanowanych skilli — w większości były to niebezpieczne praktyki, a nie potwierdzone malware. Nie jest to audyt Superpowers, lecz wspiera ostrożny proces instalacji. Skan bezpieczeństwa receiving-code-review wykonany przez Tessl ostrzega konkretnie przed pośrednim prompt injection z niezaufanego feedbacku review.
Zastosuj następujące kontrole:
- instaluj z natywnego oficjalnego marketplace’u albo ze sprawdzonego, przypiętego tagu lub commita;
- przed aktualizacją przeglądaj manifesty, hooki, skrypty, uprawnienia i diff wersji;
- najpierw testuj w niewrażliwym repozytorium bez sekretów produkcyjnych;
- zachowaj sandboxing, zatwierdzanie komend, chronione branche, CI i ludzki review;
- izoluj równoległą pracę w osobnych worktrees;
- traktuj zewnętrzną prozę jako dane, a nie instrukcje o wyższym priorytecie;
- weryfikuj pochodzenie kodu, licencje zależności i wygenerowane zasoby;
- nie commituj danych roboczych z
.superpowers/sdd/, chyba że zespół świadomie tego chce; - wyłącz telemetrię lub zdalny dostęp do Visual Companion, jeśli wymaga tego polityka.
Superpowers a sąsiednie narzędzia
Dział zatytułowany „Superpowers a sąsiednie narzędzia”| Narzędzie lub podejście | Główny cel | Relacja z Superpowers |
|---|---|---|
| Natywny Plan Mode | Przegląd i uzgodnienie kierunku implementacji | Lżejszy i wbudowany w hosta; zwykle nie obejmuje pełnego cyklu TDD, review i zakończenia |
Reguły repozytorium (AGENTS.md, CLAUDE.md) | Zapis ograniczeń i komend specyficznych dla projektu | Lokalna polityka o wyższym priorytecie; Superpowers dostarcza wokół niej ogólny proces |
| Grill Me / wywiad wymagań | Sprawdzenie pomysłu pod presją i wykrycie niejednoznaczności | Głębsze odkrywanie może zasilić projekt Superpowers; nie realizuje reszty cyklu |
| Spec Kit | Utrwalanie wymagań, specyfikacji, planów i zadań | Kontroluje przede wszystkim co powstaje; Superpowers koncentruje się na tym, jak agent wykonuje i weryfikuje pracę |
| Serwery MCP | Dostarczanie modelowi narzędzi i dostępu do systemów zewnętrznych | Uzupełnienie: MCP daje możliwości, Superpowers — procedurę operacyjną |
| Własne wąskie skille | Kodowanie mniejszego lub firmowego workflow | Mniejszy narzut i lepsze dopasowanie do polityki, ale musisz samodzielnie zaprojektować i przetestować zachowanie |
Nie musisz wybierać wyłącznie jednego systemu. Dojrzała konfiguracja często łączy reguły repozytorium dla lokalnej polityki, MCP dla możliwości, metodę odkrywania wymagań dla trudnych problemów oraz wybrane skille Superpowers dla dyscypliny wykonania.
Kiedy używać
Dział zatytułowany „Kiedy używać”Pełny proces jest dobrym punktem wyjścia, gdy:
- wymagania są niejednoznaczne, a błędna interpretacja byłaby kosztowna;
- funkcjonalność przechodzi przez kilka warstw lub plików;
- zachowanie da się wyspecyfikować i przetestować;
- refaktoryzacja wymaga niezawodnej ochrony przed regresją;
- błąd oparł się oczywistym poprawkom;
- praca będzie przekazywana pomiędzy sesjami lub ludźmi;
- implementacja i review w świeżych kontekstach są wartościowe;
- zespół nie ma spójnego workflow dla agentów.
Użyj skróconego procesu — albo zrezygnuj z Superpowers — gdy:
- zadanie jest wyłącznie researchem lub wyjaśnieniem bez zmian;
- zmiana jest mechaniczna i trywialna do zweryfikowania;
- eksplorujesz jednorazowy prototyp;
- ścisłe TDD źle pasuje do wyniku;
- utrwalony proces inżynierski zespołu zapewnia już silniejsze równoważne bramki;
- czas wykonania lub budżet tokenów są ważniejsze niż ograniczenie poprawek;
- nie możesz bezpiecznie odizolować równoległych sesji SDD.
Selektywna adopcja jest uzasadniona. brainstorming, systematic-debugging i verification-before-completion mogą przynosić wartość niezależnie. Jeżeli pomijasz fazy, zdecyduj o tym jawnie, zamiast polegać na tym, że agent wywnioskuje intencję z niecierpliwego promptu.
Plan adopcji zespołowej
Dział zatytułowany „Plan adopcji zespołowej”- Wybierz reprezentatywny pilotaż. Użyj średniej wielkości funkcjonalności z jasnymi kryteriami akceptacji, a nie zabawkowego zadania ani migracji o najwyższym ryzyku produkcyjnym.
- Zapisz baseline. Zmierz akceptację pierwszej wersji, czas ścienny, tokeny lub koszt, liczbę korekt człowieka, błędy testów i defekty z review dla porównywalnej pracy bez pluginu.
- Przypnij i przejrzyj plugin. Zapisz tag upstream, wersję pakietu marketplace, wersję hosta, model, tryb zatwierdzania i wyłączone skille.
- Zdefiniuj granice polityki. Ustal, które instrukcje repozytorium mają pierwszeństwo, kiedy wolno zrobić wyjątek od TDD, kto zatwierdza projekt i plan oraz które komendy zawsze wymagają potwierdzenia.
- Pracuj w izolacji. Każdemu równoległemu workflow przydziel osobny worktree i nie udostępniaj środowisku sekretów produkcyjnych.
- Przejrzyj artefakty. Oceń, czy projekt i plan zmniejszyły niejednoznaczność, czy jedynie dodały tekst. Sprawdź, czy testy faktycznie nie przechodziły przed implementacją i czy review wykrył realne defekty.
- Porównaj wyniki. Mierz akceptację pierwszej wersji, błędy, które uciekły, liczbę iteracji, czas, koszt tokenów i utrzymywalność — nie tylko to, czy agent skończył.
- Zachowaj, dostrój albo usuń skille. Powtórz pilotaż po aktualizacji modelu lub hosta. Użyteczny proces może stawać się lżejszy wraz z rozwojem natywnych agentów.
Checklista rozwiązywania problemów
Dział zatytułowany „Checklista rozwiązywania problemów”| Objaw | Co sprawdzić |
|---|---|
| Agent od razu przechodzi do kodu | Potwierdź instalację pełnego pluginu, nie tylko skopiowanych skilli; sprawdź aktywację bootstrapu lub hooka i numer wersji |
| Pojawiają się stare slash commands lub nazwany reviewer | Prawdopodobnie masz pakiet sprzed v5.1 albo nieaktualną treść marketplace’u |
| Codex uruchamia hook sesji Claude | Zaktualizuj integrację upstream do v6.1.1 lub nowszej |
| Nie powstają subagenci | Potwierdź obsługę przez hosta; użyj executing-plans w osobnej sesji wykonawczej |
| Konfiguracja worktree zatrzymuje się | Sprawdź konwencje worktree repozytorium, reguły ignorowania, instalację zależności i błędy baseline’u |
| Agent mówi, że testy przechodzą, bez outputu | Wywołaj verification-before-completion i zażądaj komendy ze świeżym wynikiem |
| TDD zostaje pominięte | Traktuj to jako nieudany przebieg workflow; dodaj zewnętrzną bramkę CI lub review zamiast ufać samemu brzmieniu instrukcji |
| Dwie sesje dostają niewłaściwe zadania | Zatrzymaj obie; odizoluj je w osobnych worktrees i sprawdź .superpowers/sdd/ pod kątem kolizji #1942 |
| Odpowiedzi stają się wolne lub rozwlekłe | Porównaj mniejszy podzbiór skilli, ogranicz pełny pipeline tam, gdzie nie jest potrzebny, i mierz tokeny po każdej aktualizacji |
Źródła i sposób weryfikacji
Dział zatytułowany „Źródła i sposób weryfikacji”Artykuł stosuje następującą hierarchię dowodów:
- Źródło prawdy: otagowany kod upstream, release notes
v6.1.1, poszczególne plikiSKILL.md, manifesty, hooki i testy. - Stan dystrybucji: oficjalny manifest Claude, manifest pluginu OpenAI, listing marketplace’u Cursora, skills.sh i strona pluginu Claude.
- Ewaluacja projektu: Quorum / superpowers-evals oraz dzienniki eksperymentów. Są to własne testy zgodności z workflow.
- Niezależne dowody: ewaluacje zachowania i bezpieczeństwa Tessl, SWE-Skills-Bench, praktyczne porównania, przypadek
chardeti niezależne komentarze techniczne. - Dowody anegdotyczne: issues, Reddit i Hacker News. Wskazują prawdopodobne usterki, ale nie określają ich częstości.
Liczby instalacji mierzą również różne rzeczy. W chwili researchu skills.sh pokazywał około 2,2 mln zagregowanych instalacji skilli, natomiast strona pluginu Claude — około 941 000 instalacji pluginu. Nie dodawaj tych wartości, nie porównuj ich wprost i nie myl żadnej z nich z liczbą aktywnych użytkowników. Gwiazdki GitHub są trzecią, niezależną miarą.