AIDive

Pakiet do filmu

Superpowers dla Claude Code: tabela werdyktu, źródła, checklista i dalsza lektura

9 min czytania

TL;DR

  • Superpowers to proces, a nie skrzynka z narzędziami: czternaście skilli w markdownie, które każdą funkcję przepuszczają przez sesję brainstormingu, pisemny plan i łańcuch świeżych subagentów, każdy z własnym review.
  • Zainstaluj go, jeśli twoje sesje Claude Code budują funkcje na wiele godzin. Odpuść, jeśli piszesz głównie skrypty na jedno użycie i poprawki na dwie linie: wstępne sprawdzenie odpala się przy każdym zadaniu i nigdy się nie wyłącza.
  • Argument o tokenach jest prawdziwy, ale pochodzi z jednej sekcji jednego skilla: Model Selection. Orkiestrator przydziela każdej roli najtańszy model, który ją uniesie, więc drogi model dotyka tylko architektury i końcowego review brancha.
  • Repo jest w dobrej kondycji: 280,597 gwiazdek, 25,138 forków, 681 commitów na main, wydanie v6.3.0 z 2026-08-12, utworzone 2025-10-09.
  • Skarga, od której zaczął się film, czyli statystyki użycia na poziomie 1 do 3 procent, to nie błąd: oznacza, że skille nigdy nie uruchamiają się przy twojej pracy, więc płacisz za bramkę i nic nie dostajesz w zamian.
  • Środek drogi to jedno zdanie w prompcie: powiedz agentowi, żeby pomijał proces przy drobnych poprawkach, i przez kilka dni używaj samego brainstormingu, zanim przyjmiesz resztę.

Co mówią źródła

Liczby z repozytorium odczytano 2026-09-02: 280,597 gwiazdek, 25,138 forków i 681 commitów na gałęzi main, z ostatnim commitem na main z 2026-08-12 (v6.3.0) i późniejszym pushem z 2026-08-31 na gałąź inną niż main s1. Zakładka Issues pokazywała tego dnia 125 otwartych zgłoszeń; liczba 350 z API obejmuje 225 otwartych pull requestów, więc przy porównaniu z innymi wtyczkami cytuj zakładkę, nie API s6. Projekt powstał 2025-10-09 i zawiera czternaście skilli s2. Post startowy autora wyjaśnia zakład w jednej linijce: agentom kodującym nie brakuje zdolności, brakuje im dyscypliny, a tę dyscyplinę można rozdawać jako zwykłe pliki markdown, które każdy może czytać, forkować i edytować s5. Wtyczka jest na oficjalnym marketplace, więc instalacja to jedno polecenie, a aktualizacje idą za marketplace s4.

Punktem wejścia jest skill, który hook startu sesji ładuje przed czymkolwiek innym. Mówi agentowi, że jeśli ma choćby wątpliwość, czy jakiś skill ma zastosowanie, musi go załadować i sprawdzić, zanim odpowie lub napisze kod. Ta reguła jest źródłem zarówno korzyści, jak i stałego kosztu s14.

Brainstorming otwiera HARD-GATE: żadnego kodu, żadnego scaffoldingu, żadnego skilla implementacyjnego, dopóki nie zatwierdzisz jawnie zamiaru. Potem sortuje prośbę do jednej z trzech ścieżek: spike, gdy wynikiem jest odpowiedź, a nie kod; bounded, dla małej zmiany w przepływie, który repo już ma; architectural, dla wszystkiego, co przebudowuje projekt. Agent ogłasza klasyfikację, żebyś mógł jej zaprzeczyć, a zapadka działa w jedną stronę: ukryta złożoność odkryta w trakcie zadania przesuwa ścieżkę w górę, nigdy w dół s9.

Skill do pisania planów prosi o plan napisany dla kompetentnego programisty, który nie zna twojej bazy kodu i, słowami samego pliku, ma wątpliwy gust. Praca jest cięta na zadania, w których każdy krok trwa od dwóch do pięciu minut: napisz test, który nie przechodzi, uruchom go i zobacz porażkę, napisz minimalny kod, uruchom testy ponownie, zrób commit. Każde zadanie wymienia dokładne pliki do utworzenia lub zmiany, aż do numerów linii, a plan zaczyna się obowiązkowym nagłówkiem s10.

Wykonaniem zajmuje się skill rozwoju sterowanego subagentami: jeden świeży subagent na zadanie, review po każdym zadaniu, review całego brancha na końcu. Główna sesja przestaje kodować i tylko rozdziela pracę. Każdy subagent dostaje wyłącznie kontekst swojego zadania, nigdy historię twojej sesji, co zostawia twoje okno wolne na koordynację. Gdy subagent zaimplementuje, przetestuje, zrobi commit i sam się sprawdzi, orkiestrator przeprowadza dwuczęściowe review, najpierw zgodność ze specyfikacją, potem jakość kodu, z miejscem recenzenta zarezerwowanym dla każdego zadania. Plik ogranicza pętlę do maksymalnie pięciu rund na zadanie s11. Izolację samej pracy zleca skillowi od worktree, więc plan nigdy nie biegnie na twoim bieżącym checkoucie s13.

Sekcja Model Selection zaczyna się od jednej reguły: użyj najmniej zdolnego modelu, który udźwignie rolę. Dobrze określone zadanie mechaniczne dotykające jednego lub dwóch plików idzie do małego modelu; gdy plan już zawiera kod do napisania, implementacja to przepisanie plus testy i wystarczy najtańszy poziom. Koordynacja wielu plików i debugowanie idą do modelu standardowego. Architektura i końcowe review brancha wymagają najzdolniejszego dostępnego modelu. W praktyce liczą się dwa szczegóły: zawsze podawaj model jawnie przy dispatchu i pozwól orkiestratorowi ocenić trudność każdego zadania przed wyborem s12. To mechanizm, który sprawia, że drogi model jest osiągalny na planie Pro za dwadzieścia dolarów: pracuje tylko przy decyzjach, które na to zasługują.

Zysk w dokumentacji to efekt uboczny procesu. Specyfikacje i plany nie są wiadomościami czatu, które znikają; to pliki markdown zapisane w repo i commitowane razem z pracą, więc recenzent później czyta, dlaczego zmianę wprowadzono, a nie tylko co się zmieniło s3.

Koszt jest taki, którego repo nie reklamuje. Wątek, który wywołał film, podaje statystyki użycia na poziomie 1 do 3 procent i pyta, jaka jest wada poza tym, że się go nie używa s7. Odpowiedź w plikach: brainstorming skaluje swoją ceremonię do zadania, ale nigdy nie pomija ludzkiego zatwierdzenia s9. Przy poprawce na dwie linie nadal odpowiadasz na pytania o ramy, zatwierdzasz dwuzdaniowy projekt i czekasz na pełny cykl. Briefy dispatchu, dwa review na zadanie i rejestr śledzenia to tokeny, które płacisz za każdym razem, i widać to przy najmniejszych zadaniach. Niskie statystyki użycia znaczą, że skille nie pasują do twojej pracy, i to jest prawdziwy sygnał do odczytania.

Werdykt według sposobu użycia

Twoje użycie Claude Code Instalować? Dlaczego
Funkcje na wiele godzin, kilka plików, branch Tak Ramowanie chroni przed zbudowaniem złej rzeczy, krótkie zadania trzymają agenta z dala od nasycenia kontekstu, model selection rozciąga limit, dokumentacja wypada z procesu
Mieszane: funkcje niektóre dni, poprawki większość dni Tak, z regułą pomijania Zostaw bramkę dla funkcji, w prompcie każ agentowi pomijać proces przy małych poprawkach
Skrypty na jedno użycie, literówki w configu, poprawki na dwie linie Nie Stały koszt bramki dotyka zadań, które jej nie potrzebują
Ciekawość, ale brak gotowości na całą metodę Tylko brainstorming Niesie większość zysku; pozostałe skille dołączają się potem naturalnie

Zrób to w poniedziałek

  • Zainstaluj z oficjalnego marketplace i otwórz cache wtyczki: przeczytaj raz czternaście plików SKILL.md, są krótkie i to jest cały produkt.
  • Przepuść jedną prawdziwą funkcję przez bramkę od początku do końca: brainstorming, plan, dispatch subagentów, review brancha. Oceń proces po tym, nie po poprawce.
  • Sprawdź statystyki użycia po tygodniu. Poniżej kilku procent skille nie pasują do twojej pracy: albo twoje zadania są za małe, albo musisz formułować prośby jako funkcje.
  • Dodaj regułę pomijania do instrukcji projektu: przy poprawkach w jednym pliku na kilka linii idź prosto do zmiany, bez brainstormingu.
  • Skopiuj drabinę Model Selection do własnych promptów dla subagentów, nawet jeśli porzucisz wtyczkę: podawaj model jawnie przy każdym dispatchu.
  • Commituj specyfikacje i plany, które pisze wtyczka, zamiast je kasować; to twój zapis projektowy.
  • Policz otwarte zgłoszenia w zakładce Issues, nie z liczby z API, zanim porównasz projekt z inną wtyczką.

Czytaj dalej

  • Przeczytaj post startowy, by poznać zamysł projektowy, zanim sięgniesz po pliki skilli: wyjaśnia, dlaczego dyscyplinę rozdaje się jako markdown, a nie kod s5.
  • Sekcja o filozofii w README to krótka wersja metody i miejsce, by sprawdzić, czy pasuje do tego, jak już pracujesz s3.
  • Sekcja biblioteki skilli wylicza czternaście skilli z jednolinijkowym celem każdego; to szybsze niż przeglądanie katalogu s16.
  • Maksymalnie pięć rund na zadanie w skillu subagentów to twardy stop, który warto skopiować do każdej ręcznie pisanej orkiestracji s11.
  • Wątek pyta, czy tego typu wtyczka przetrwa silniejsze modele; przetrwają bramka ramowania i commitowane plany, a modele wchłoną mechanikę s19.
  • Relacja o tygodniowym limicie wypalonym przez ceremonię orkiestracji to kontrprzykład do przeczytania, zanim zastosujesz to przy małej pracy s20.
  • Porównanie z konkurencyjnym zestawem instrukcji pokazuje kompromis: mniej, ale ostrzejszych skilli kontra duży katalog reguł s18.
  • Lista otwartych zgłoszeń to najszybszy wgląd w to, co dziś psuje się innym użytkownikom s6.

Źródła

FAQ

Czy Superpowers oszczędza tokeny, czy je spala?

I jedno, i drugie. Przy funkcjach model selection wysyła zadania mechaniczne do małych modeli, a drogi model zostawia na architekturę i review brancha, więc limit starcza na dłużej. Przy małych poprawkach briefy, dwa review na zadanie i rejestr to czysty narzut.

Co oznaczają statystyki użycia na poziomie 1 do 3 procent?

Skille uruchamiają się tylko wtedy, gdy sytuacja pasuje. Niski wynik znaczy, że twoje zadania nie są funkcjami w rozumieniu wtyczki, więc płacisz za wstępne sprawdzenie i nigdy nie docierasz do części, która się zwraca.

Czy mogę zostawić tylko część?

Tak. Sam brainstorming niesie większość zysku, a drabina Model Selection działa w każdym ręcznie pisanym prompcie dla subagentów. Powiedz agentowi, żeby pomijał proces przy drobnych poprawkach, a zachowasz kontrolę.