Domyślny workflow programistyczny

Speedwave dostarcza zestaw skilli inżynierskich z prefiksem speedwave-, które porządkują pracę w sesji, gdy tego potrzebujesz. Drobną poprawkę nadal wystarczy opisać zwykłą prośbą. Przy większym zadaniu uruchamiasz wybraną ścieżkę, wywołując odpowiedni skill w oknie czatu lub w CLI; żaden skill nie uruchamia się samoczynnie na początku sesji. Pełną listę znajdziesz w artykule Wbudowane skille i wtyczki, a /speedwave-ask poleci ścieżkę dopasowaną do Twojej sytuacji.

Zanim zaczniesz

Przy pierwszym użyciu w repozytorium uruchom /speedwave-setup. Skill zapyta, gdzie prowadzisz zgłoszenia: w GitHubie, GitLabie, systemie Jira lub Redmine przez włączoną integrację, albo w lokalnych plikach markdown w .speedwave/scratch/. Zapisze też etykiety używane przy wstępnej selekcji (triage) oraz miejsce, w którym trzymasz słownik pojęć projektu (SPEEDWAVE.md) i rejestr decyzji architektonicznych (docs/adr/).

Od pomysłu do przejrzanego kodu

1. Doprecyzuj pomysł. /speedwave-grill-with-docs szczegółowo analizuje z Tobą plan, dopóki wszystkie wątpliwości nie zostaną rozstrzygnięte. Uzgodnione pojęcia zapisuje w SPEEDWAVE.md, a kluczowe decyzje architektoniczne jako dokumenty ADR. Jeśli na któreś pytanie odpowie dopiero działający kod, /speedwave-prototype buduje najpierw szybki prototyp poglądowy.

2. Spisz specyfikację i zgłoszenia. Przy pracy rozłożonej na kilka sesji /speedwave-to-spec zamienia rozmowę w spójną specyfikację, a /speedwave-to-tickets dzieli ją na mniejsze zadania. Każde z nich wskazuje zgłoszenia, które je blokują. W Redmine zależności te stają się natywnymi relacjami między zadaniami, a w pozostałych trackerach linią Blocked by:.

3. Zaimplementuj. /speedwave-implement realizuje jedno zgłoszenie naraz, zaczynając od testów za pośrednictwem /speedwave-tdd: najpierw powstaje test zakończony niepowodzeniem, następnie minimalny kod sprawiający, że test przechodzi pomyślnie, i tak krok po kroku. Zmiany są commitowane do bieżącej gałęzi. Pomiędzy kolejnymi zgłoszeniami warto wyczyścić kontekst sesji (/clear), ponieważ każde zgłoszenie zawiera komplet informacji wymaganych do dalszej pracy.

4. Przejrzyj zmiany. Po zakończeniu zgłoszenia Claude poprosi Cię o uruchomienie /speedwave-code-review, które sprawdza zmiany równolegle czternastoma agentami recenzującymi (zobacz Przegląd kodu z AI). O scaleniu zmian decydujesz Ty.

Przy mniejszych zadaniach krok drugi można pominąć: /speedwave-implement można uruchomić w tej samej sesji zaraz po wywiadzie.

Inne punkty wyjścia

• Napływające zgłoszenia: /speedwave-triage przeprowadza zgłoszenia błędów oraz prośby o zmiany przez proces wstępnej selekcji (triage), przekształcając je w precyzyjne zadania gotowe do podjęcia przez agenta.
• Coś nie działa: /speedwave-diagnosing-bugs przygotowuje polecenie odtwarzające błąd, a następnie usuwa usterkę wraz z dodaniem testu regresyjnego.
• Projekt za duży na jedną sesję: /speedwave-wayfinder rozpisuje otwarte decyzje jako zgłoszenia w Twoim trackerze i rozstrzyga je po kolei, zanim przekaże pracę do /speedwave-to-spec.

Kontekst pod kontrolą

Wywiad, specyfikację i podział na zgłoszenia warto prowadzić w ramach jednego okna kontekstu, aby każdy etap bazował na tych samych ustaleniach. Gdy praca jest przenoszona do innego katalogu lub przekazywana innej osobie w zespole, /speedwave-handoff generuje plik z podsumowaniem w .speedwave/handoffs/.

Integracja z systemami zarządzania zadaniami

Zgłoszenia i triage przechodzą przez te same workery integracji co każde inne wywołanie narzędzia, więc obowiązują je te same poświadczenia i zakresy projektu, które opisuje artykuł Planowanie i user stories.

Dostosowanie

Zespół może nadpisać dowolną z tych umiejętności, dodając do repozytorium plik o identycznej nazwie w katalogu .claude/skills/. Konfiguracja na poziomie projektu ma pierwszeństwo przed wbudowanymi skillami.