Superpowers naprawia Claude Code, ale ma swoją cenę

Superpowers to plugin do Claude Code napisany przez Jessego Vincenta, który tworzy otwarte narzędzia dla deweloperów od lat 90. Wydał go w październiku, a niecały rok później repozytorium ma 280 000 gwiazdek i 25 000 forków, przy czym ostatni push wylądował dwa dni przed naszym nagraniem. Projekt jest już w szóstej dużej wersji i ma 681 commitów na głównej gałęzi, więc nie jest to zbiór promptów porzucony tuż po szumie z premiery.

Sygnał	Wartość
Gwiazdki na GitHub	280 000
Forki	25 000
Duża wersja	6
Commity na main	681
Otwarte issues	125

Zakład Vincenta mieści się w jednym zdaniu: agentom do kodowania nie brakuje możliwości, brakuje im dyscypliny. Ta dyscyplina ma postać zwykłych plików markdown, które każdy może przeczytać, sforkować i dopasować. Zainstalowaliśmy plugin, przeczytaliśmy wszystkie czternaście skilli linijka po linijce i sprawdziliśmy, co zmienia na czterech frontach: produktywność, niezawodność kodu, zużycie tokenów i dokumentacja.

Superpowers to darmowy, otwarty plugin do Claude Code. Znajduje się w oficjalnym marketplace pluginów Anthropic i instaluje się jedną komendą. Ta sama metodologia istnieje dla kilkunastu innych narzędzi, w tym Cursor, Codex i Gemini, każde z własną ścieżką instalacji.

Rdzeniem jest czternaście skilli: plików markdown z instrukcjami, które agent ładuje, gdy sytuacja do nich pasuje. Brainstorming, pisanie planów, development przez subagentów, test-driven development i systematyczny debugging kodują każdy kompletny sposób pracy, z własnymi listami kontrolnymi i zabezpieczeniami. Skill do debugowania zabrania proponować poprawkę, zanim wyizoluje się przyczynę. Skill weryfikacji każe agentowi udowodnić, że zadanie jest skończone, zamiast tylko to twierdzić. Każdy skill ogłasza się przy ładowaniu, więc zawsze wiesz, w jakim trybie pracuje agent.

Hook na starcie sesji zmusza Claude do sprawdzenia przed każdym zadaniem, czy któryś z tych skilli pasuje. Zasada jest zapisana w skillu wejściowym: jeśli jest choć jeden procent szans, że skill jest istotny, agent musi go załadować. Efekt zachowuje się mniej jak skrzynka z narzędziami, a bardziej jak metodologia pracy wstrzyknięta do agenta.

Vincent opisuje początki na swoim blogu. Zbudował skille, przekopując 2 249 plików markdown z lekcjami, które wyciągnęli jego własni agenci, a potem testował szkice na tych samych archiwach. Metodologia została wydobyta z prawdziwych porażek agentów, a nie napisana z teorii.

Brainstorming to skill, przez który przechodzi wszystko. Gdy tylko prosisz o funkcję, Claude go ładuje i na czas rozmowy ustawiającej ramy zamienia się w eksperta od wymagań. Cała metoda mieści się w jednym czytelnym pliku.

Plik otwiera twarda bramka: żadnego kodu, żadnego szkieletu, żadnego skilla implementacji, dopóki nie zatwierdzisz jawnej intencji. Nic nie powstaje na przeczucie, a bramka dotyczy każdego zadania, choćby wyglądało na małe. Następnie skill sortuje każdą prośbę na jedną z trzech ścieżek.

Ścieżka	Definicja	Wynik
Spike	Pytanie o wykonalność	Odpowiedź, a nie kod, który zachowujesz
Bounded	Mała zmiana w przepływie, który już istnieje w repozytorium	Zmiana o ograniczonym zakresie
Architectural	Wszystko, co przebudowuje strukturę projektu	Spec, który zatwierdzasz, a potem plan implementacji

Agent mówi swoją klasyfikację wprost, żebyś mógł ją zmienić, a zapadka obraca się tylko w jedną stronę: ukryta złożoność odkryta w trakcie zadania podnosi ścieżkę, nigdy odwrotnie. Plik zawiera tabelę czerwonych flag, myśli w stylu „to za proste, żeby potrzebować designu”, a obok każdej kontrargument: to właśnie w prostych zadaniach niezbadane założenia kosztują najwięcej. Nawet spike ma swoje zabezpieczenie. Cokolwiek agent zbuduje, by odpowiedzieć na pytanie, zostaje oznaczone jako jednorazowe, a zachowanie tego kodu staje się nową prośbą do sklasyfikowania.

W trakcie dialogu agent zadaje pytania, które zadałby lead engineer, i przedstawia swój design w strawnych sekcjach. W naszym własnym pipeline ta faza już ubiła funkcje, które zbudowalibyśmy na darmo.

Skill pisania planów otwiera instrukcja, która nadaje ton: napisz plan dla zdolnego dewelopera, który nie zna twojego kodu i ma, jak ujmuje to sam plik, wątpliwy gust.

Konkretnie: praca jest cięta na zadania, w których każdy krok zajmuje od dwóch do pięciu minut: napisz padający test, uruchom go, żeby upewnić się, że pada, napisz minimalny kod, który go przechodzi, uruchom testy ponownie, zrób commit. Jedna akcja, jedna weryfikacja, a praca idzie naprzód częstymi commitami. To cykl test-driven development, wymuszany przez inny skill pluginu, więc każde zadanie ma własny cykl testów.

Każde zadanie wylicza dokładne pliki do utworzenia lub zmiany, co do numerów linii. Plan otwiera obowiązkowy nagłówek: cel w jednym zdaniu, architektura w dwóch lub trzech, stack technologiczny, link do specu i globalne ograniczenia projektu skopiowane słowo w słowo. Jeśli spec obejmuje kilka niezależnych podsystemów, skill wymaga osobnych planów, jednego na podsystem, a każdy z nich ma dawać software testowalny samodzielnie.

Rozmiar zadań to sedno argumentu o niezawodności. Krótkie zadanie oznacza agenta, który kończy pracę z oknem kontekstu wciąż w większości pustym. Nigdy nie dochodzi do momentu, w którym sesja się przelewa, agent traci wątek i zaczyna wymyślać funkcje, które nie istnieją. Żadne pięciominutowe demo nie pokaże tego problemu, ale w prawdziwym projekcie decyduje on o wszystkim: jakość agenta pod koniec sesji nie ma nic wspólnego z jego jakością przy pierwszym prompcie. Mniej nasycony kontekst to mechanicznie mniej halucynacji i kod, który robi to, co mówił plan.

W czasie wykonania dedykowany skill izoluje pracę w worktree Gita, czyli osobnej kopii roboczej repozytorium, więc plan działa, nie wchodząc w drogę temu, co robisz obok.

Skill wykonania prowadzi development przez subagentów. Jego zasada mieści się w jednej linijce pliku: świeży subagent na zadanie, review po każdym zadaniu i szerokie review całej gałęzi na końcu. Twoja główna sesja staje się orkiestratorem. Już nie koduje, deleguje. Każdy subagent dostaje dokładnie ten kontekst, którego potrzebuje jego zadanie, i nigdy historię twojej sesji, co zapobiega zanieczyszczeniu kontekstu i zostawia twoje własne okno wolne na koordynację.

Subagent może zadać pytania, zanim zacznie, a potem implementuje, testuje, commituje i sprawdza własną pracę. Gdy skończy, orkiestrator robi review w dwóch częściach, najpierw zgodność ze specem, potem jakość kodu, z dedykowanym reviewerem do każdego zadania. Nic nie jest improwizowane: skill zawiera szablon promptu dla każdej roli (implementer, reviewer zadania i reviewer, który sprawdza poprawki), a orkiestrator wypełnia go kontekstem zadania.

Wynik review	Co się dzieje
Przechodzi	Orkiestrator zapisuje ukończenie w rejestrze i idzie dalej w planie
Nie przechodzi, rundy 1 do 3	Pierwotny implementer wraca do pracy, bo już zna kod i własne wybory
Nie przechodzi, runda 4	Świeży implementer jest wysyłany na mocniejszym modelu
Nie przechodzi, runda 5	Zadziała bezpiecznik i orkiestrator sam rozstrzyga każdą otwartą uwagę

Skill unika też przeciwnej przesady: seria drobnych mechanicznych zadań idzie jako jedna grupa, sprawdzana jako całość. Nic nie jest mergowane bez przejścia przez reviewera. Efekt to to, co ludzki zespół nazywa procesem code review, tylko że działa samo, zadanie po zadaniu.

System delegowania otwiera drzwi do trzeciej wygranej: ekonomii tokenów. Skill ma sekcję wyboru modelu, która zaczyna się jedną zasadą: użyj najsłabszego modelu, który poradzi sobie z daną rolą. Orkiestrator ocenia trudność każdego zadania w planie i przypisuje pasujący model.

Zadanie	Poziom modelu
Dobrze opisane mechaniczne zadanie na plik czy dwa albo plan, który już zawiera kod do napisania	Najtańszy poziom (implementacja staje się przepisywaniem plus testami)
Koordynacja wielu plików, debugging	Standardowy model
Architektura, końcowe review gałęzi	Najmocniejszy dostępny model

Plik dodaje dwie subtelności. Po pierwsze: zawsze podawaj model jawnie, gdy delegujesz. Subagent bez modelu dziedziczy model twojej sesji, często najdroższy, co po cichu niweczy całą tę sekcję. Po drugie: liczba tur bije cenę tokena. Najtańsze modele potrzebują więcej tur przy pracy z wieloma krokami i w sumie wychodzą drożej, dlatego reviewerzy i implementerzy pracujący z opisu mają podłogę o poziom wyżej, a nie najtańszą półkę.

Ten układ umożliwia coś wbrew intuicji: używanie Opus albo Fable, najdroższych modeli w katalogu, na planie Pro za 20 dolarów. Drogi model pracuje tylko nad kilkoma decyzjami, które na to zasługują, a reszta planu leci na modelach zużywających ułamek twojego limitu.

Ostatnia wygrana to ta, o której nikt nie myśli, instalując plugin. Specy i plany to nie wiadomości z czatu, które znikają z końcem sesji. To pliki markdown zapisane w repozytorium i commitowane razem z pracą. Skill ustala lokalizację: datowany folder planów, jeden plik na funkcję, z celem, architekturą i linkiem do specu w nagłówku.

Spec podróżuje z planem, a konflikty między nimi rozstrzyga się na rzecz specu: autorytetem jest dokument, nie pamięć agenta. Historia Gita nie mówi już tylko, co się zmieniło. Mówi dlaczego i co agent wtedy postanowił. Pół roku później wystarczy wspomnieć plik planu w prompcie, a agent od razu podnosi kontekst pierwotnej funkcji, a nowa funkcja w tym samym podsystemie buduje na istniejącym specu, zamiast odkrywać teren od nowa.

Nie ma już czegoś takiego jak nieśledzone zadanie: wszystko, co agent zrobił w kodzie, zostawiło po sobie dokument, od pierwszego brainstormu do ostatniego commita. Projekt streszcza swoją filozofię w dwóch zasadach: systematycznie zamiast ad hoc i dowody zamiast deklaracji. Dokumentacja wypada z procesu sama.

Ograniczenie jest realne, a repozytorium się nim nie chwali: cała ta dyscyplina ma stały koszt, który nigdy się nie wyłącza. Skill wejściowy jest bezpośredni. Przy najmniejszej wątpliwości agent musi załadować skill, a plik brainstormingu mówi wprost, że ceremonia skaluje się z zadaniem, ale ludzkie zatwierdzenie nigdy.

Przy poprawce na dwie linijki oznacza to odpowiadanie na pytania o ramy, zatwierdzanie designu z dwóch zdań, a potem czekanie na pełny cykl, zanim zobaczysz poprawkę. Przy literówce w pliku konfiguracji pełny proces jest po prostu wolniejszy niż poprawienie jej samemu. Sama orkiestracja też zużywa tokeny: briefy do delegowania, dwa review na zadanie i rejestr są płacone za każdym razem, co najbardziej czujesz przy najmniejszych zadaniach.

Jest też odwrotny objaw i to on odpowiada wprost na pytanie z Reddita. Jeśli statystyki użycia pokazują plugin na kilku procentach, twoje prośby prawie nigdy nie uruchamiają skilli, więc płacisz za kontrolę wejściową w każdej sesji, nie tykając zysków. Pętla poprawek na pełne pięć rund to pięć diffów, pięć kolejnych review i arbitraż dla zadania, które miało zająć minuty. Projekt też nigdy nie stoi w miejscu: przeszedł od pierwszej wersji do szóstej w niecały rok i wciąż ma 125 otwartych issues, więc skille, które czytasz dziś, zmienią się do następnej aktualizacji.

Plugin planuje własne wyjście. Jego instrukcje stawiają twoje polecenia ponad skillami, więc możesz wprost powiedzieć agentowi, żeby pominął proces. Nasza zasada: Superpowers domyślnie włączone do każdej pracy nad funkcjami i świadome pominięcie przy drobnych poprawkach.

Twoje użycie Claude Code	Werdykt
Funkcje, które zajmują godziny	Zainstaluj: ramy chronią cię przed wdrożeniem złej rzeczy, krótkie zadania trzymają agenta z dala od nasycenia kontekstu, wybór modelu rozciąga twój limit, a dziedziczysz dokumentację, której sam byś nigdy nie napisał
Jednorazowe skrypty i drobne poprawki	Omiń go: płaciłbyś stały koszt procesu za zadania, które go nie potrzebują
Pomiędzy	Zainstaluj go i naucz się mówić „skip”: jedno zdanie w prompcie oddaje ci kontrolę

Jeśli chcesz go przetestować, nie przyjmując wszystkiego, pozwól działać samemu skillowi brainstormingu przez kilka dni. Niesie większość zysku, a pozostałe skille dołączają po nim naturalnie. Plugin dotrzymuje swoich czterech obietnic, o ile karmisz go funkcjami godnymi jego ceremonii. Działa teraz na naszych własnych projektach, a fazy brainstormingu już byśmy nie wyłączyli. Repozytorium jest darmowe i otwarte, a w kolejce przed tobą stoi 280 000 osób.