# 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](/pl/docs/features/built-in-skills-and-plugins/).

## 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

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

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

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

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

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](/pl/docs/features/code-review/). 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](/pl/docs/features/built-in-skills-and-plugins/).

## 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

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

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](/pl/docs/features/planning-and-user-stories/) 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

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ę.