Domyślny workflow programistyczny
Speedwave dostarcza wtyczkę superpowers domyślnie włączoną, więc większość sesji, w których coś budujesz albo zmieniasz, przechodzi przez etapowy workflow zamiast od razu wskoczyć w kod. Ta strona pokazuje, co widzisz na każdym etapie i co Speedwave prosi cię zatwierdzić. Pełny spis tego, co trafia do każdego kontenera, znajdziesz w wbudowanych skillach i wtyczkach.
Burza mózgów
Dział zatytułowany „Burza mózgów”Kiedy poprosisz Speedwave o zbudowanie albo zmianę czegoś, zaczyna od pytań, a nie od pisania kodu. Spodziewaj się krótkiej wymiany zdań, która doprecyzuje, czego właściwie chcesz, a potem projektu rozwiązania podzielonego na fragmenty, z których każdy Speedwave przedstawia do zatwierdzenia, zanim przejdzie do kolejnego. Ty decydujesz o zakresie: jeśli jakieś pytanie cię nie interesuje, powiedz to, a Speedwave pójdzie dalej.
Odizolowane środowisko pracy
Dział zatytułowany „Odizolowane środowisko pracy”Gdy zatwierdzisz projekt, Speedwave zakłada odizolowaną gałąź albo worktree, w którym będzie pracować, i sprawdza, czy istniejące testy tam przechodzą, zanim wprowadzi jakąkolwiek zmianę. Dzięki temu praca zostaje oddzielona od tego, co jest na twojej głównej gałęzi, a Speedwave ma sprawdzony punkt odniesienia, z którym porówna kolejne kroki.
Spisywanie planu
Dział zatytułowany „Spisywanie planu”Speedwave rozbija zatwierdzony projekt na małe, konkretne zadania, każde na kilka minut pracy, z dokładnymi plikami, których dotyczy, i sposobem sprawdzenia, że się udało. Ten plan widzisz jeszcze przed rozpoczęciem implementacji, więc możesz złapać zły kierunek, zanim korekta zrobi się kosztowna.
Realizacja
Dział zatytułowany „Realizacja”Każde zadanie z planu realizuje osobny, świeży subagent, który zna tylko to jedno zadanie, a nie całą dotychczasową rozmowę. Zanim Speedwave uzna kawałek pracy za skończony, przechodzi on dwuetapową recenzję: najpierw czy odpowiada temu, co zakładał plan, a potem czy sam kod jest dobry. Widzisz to jako strumień małych, recenzowanych kroków, a nie jedną dużą, nieprzejrzystą zmianę.
Test-driven development
Dział zatytułowany „Test-driven development”Dla każdego fragmentu implementacji Speedwave najpierw pisze test, który nie przechodzi, potem dokładnie tyle kodu, ile trzeba, żeby przeszedł, a na końcu porządkuje wynik. Zobaczysz najpierw niedziałający test, a dopiero potem kod, który go spełnia, w takiej kolejności dla każdego fragmentu planu.
Code review
Dział zatytułowany „Code review”Przed zamknięciem pracy Speedwave ponownie czyta gotowy efekt w zestawieniu z pierwotnym planem i zaznacza wszystko, co się nie zgadza, sortując znaleziska według wagi. To sprawdzenie względem planu, który już zatwierdziłeś, a nie druga dyskusja o projekcie.
To sprawdzenie względem planu jest pierwszym poziomem przeglądu, nie jedynym. Do codziennego przeglądu diffa albo przeglądu pull lub merge requesta na GitHubie czy GitLabie służy wbudowana w Claude Code komenda /code-review, czyli przebieg opisany w przeglądzie kodu wspieranym przez AI. Kiedy chcesz najsilniejszego przejścia, jakie oferuje Speedwave, wywołaj /speedwave-code-review: uruchamia równolegle czternastu wyspecjalizowanych recenzentów (bezpieczeństwo, wydajność, duplikacja, pokrycie testami i inne) nad dowolnym zestawem zmian i łączy wyłącznie zweryfikowane wnioski. Pełną listę recenzentów znajdziesz wśród skilli do przeglądu kodu.
Kończenie gałęzi
Dział zatytułowany „Kończenie gałęzi”Na koniec Speedwave jeszcze raz weryfikuje pracę, a potem pyta cię, jak ją zamknąć: scalić, otworzyć pull albo merge request, czy posprzątać i zatrzymać się. Nic nie trafia na współdzieloną gałąź bez twojego wyboru.
Debugowanie i weryfikacja, przez cały czas
Dział zatytułowany „Debugowanie i weryfikacja, przez cały czas”Dwa zachowania działają poza etapowym przebiegiem opisanym wyżej, ilekroć są potrzebne. Gdy Speedwave natrafi na błąd albo test, który nie przechodzi, szuka przyczyny źródłowej w uporządkowanych fazach, zamiast zgadywać poprawkę. A zanim Speedwave powie ci, że coś jest gotowe, naprawione albo przechodzi, najpierw uruchamia weryfikację tego stwierdzenia, zamiast twierdzić to z samej pewności siebie.
Jak to się ma do planowania i historyjek użytkownika
Dział zatytułowany „Jak to się ma do planowania i historyjek użytkownika”Ten workflow dotyczy tego, jak Speedwave buduje wewnątrz sesji, rozbijając jeden kawałek pracy na recenzowane, prowadzone testami kroki. Planowanie i historyjki użytkownika dotyczy tego, gdzie wymagania żyją, zanim to się zacznie: w Jirze, Confluence albo Redmine, prowadzone przez te integracje. Oba podejścia spotykają się tam, gdzie krok planu odwołuje się do zadania w jednym z tych systemów albo je aktualizuje; jedno nie zastępuje drugiego.
Wyłączanie
Dział zatytułowany „Wyłączanie”Wyłącz cały ten przebieg dla kontenera projektu komendą /plugin disable superpowers. Ten wybór przetrwa restarty; Speedwave nie doinstaluje go ponownie za ciebie. W trakcie sesji możesz też po prostu powiedzieć Speedwave, żeby pominął ceremonię przy czymś trywialnym. Jednolinijkowa poprawka nie potrzebuje burzy mózgów i planu, a Speedwave odpowiednio zmniejszy skalę.