Dynamiczne workflow w Claude Code — checklista · Zasób

To jest wersja do trzymania pod ręką, gdy stoisz przed decyzją „odpalić workflow czy nie”. Przechodzisz kolejne fazy z góry na dół: najpierw rozstrzygasz, czy zadanie w ogóle pasuje do workflow, potem zabezpieczasz koszty, a na końcu sprawdzasz miejsce zapisu i pułapki. Każdy punkt zaczyna się od czynności, którą da się odhaczyć.

Zasada, która rozstrzyga wszystko w jednym zdaniu: nie pytaj, która funkcja jest najmocniejsza — pytaj, która pasuje do problemu, który masz dziś przed sobą.

0. Zanim zaczniesz — co musisz wiedzieć

Sprawdź, że masz model Opus 4.8 albo nowszy — dynamiczne workflow pojawiły się dopiero od jego premiery.
Ustal, czym workflow różni się od sąsiednich funkcji, żeby nie sięgnąć po droższą bez potrzeby:
Skill to powtarzalny przepis — instrukcja, którą wołasz jedną komendą.
Sub-agent to równoległy pomocnik z własnym, czystym kontekstem; sub-agenty nie rozmawiają ze sobą, każdy raportuje wynik do twojej głównej sesji.
Zespół agentów to mała załoga ze wspólną listą zadań, która wymienia się między sobą — i za tę rozmowę płacisz w tokenach.
/goal to głębokość: jeden cel, wiele przebiegów, aż agent spełni kryterium ukończenia.
Dynamiczne workflow to szerokość: skrypt w JavaScripcie odpala wiele niezależnych sub-agentów naraz, każdy nad swoim wycinkiem, a wyniki łączą się na końcu.
Zapamiętaj, że to drabina rosnącej mocy, kosztu i ryzyka: rozmowa → skill → sub-agent → zespół agentów → /goal → workflow. Im wyżej, tym więcej zrobisz jednym poleceniem i tym więcej możesz przy okazji spalić.

1. Rozstrzygnij, czy w ogóle potrzebujesz workflow

Zadaj jedno pytanie rozstrzygające: czy to zadanie rozpada się na wiele kawałków, które mogą działać niezależnie, w tym samym czasie?
Jeśli tak — rozważ workflow.
Jeśli nie — prawie na pewno go nie potrzebujesz.
Dopasuj narzędzie do sytuacji, zamiast sięgać po najmocniejsze:
Szybka rzecz → po prostu zapytaj Claude'a.
Proces, który powtarzasz → zrób skill.
Uciążliwe zadanie poboczne → zleć sub-agentowi.
Mała załoga, która musi się dogadywać → zespół agentów.
Ma działać, aż spełni kryterium → /goal.
Wielkie zadanie do zrównoleglenia → dynamiczne workflow.
Sprawdź, czy twój przypadek wygląda jak te, do których workflow pasuje dobrze: przejrzenie każdego pliku w bazie kodu albo migracja czterystu plików naraz — dużo kawałków, każdy dostaje własny pas i pełną uwagę osobnego agenta.

2. Zabezpiecz koszty, zanim cokolwiek odpalisz

Najpierw zrozum mechanizm: każdy agent to pełne wywołanie Claude'a z własnym kontekstem, który musi przeczytać — przy wielu agentach naraz zużycie tokenów wejściowych potrafi gwałtownie wystrzelić. Tokeny wyjściowe są zwykle dużo mniejsze i tańsze. Dlatego zrób trzy rzeczy, zanim naciśniesz „uruchom”:

Ogranicz zakres. Powiedz dokładnie, gdzie agenci mają szukać, a gdzie nie — niczym nieograniczony zakres (np. cały pulpit i wszystkie lokalne repozytoria) zjada tokeny hurtowo.
Nazwij konkretny rezultat. Im precyzyjniej opiszesz, czego chcesz, tym mniej zbędnej pracy. Ta sama logika dotyczy /goal — niejasne polecenie potrafi zapętlić się na długo.
Posadź pracowników na Haiku. To najszybszy i najtańszy z modeli Claude'a, w sam raz do wielu drobnych, równoległych zadań.

3. Uruchom workflow i trzymaj rękę na pulsie

Poczekaj na prośbę o potwierdzenie — workflow nigdy nie odpala się przypadkiem.
Zanim cokolwiek ruszy, obejrzyj surowy skrypt, który ma zostać wykonany.
W trakcie wpisz /workflows i sprawdź wszystkie uruchomione przebiegi — widzisz, ilu agentów pracuje, na jakim modelu, ile zużyli tokenów i jak długo działają.
Jeśli coś idzie nie tak, zatrzymaj przebieg z poziomu /workflows.

4. Zadbaj o miejsce zapisu i ponowne użycie

Jeśli chcesz mieć skrypt pod ręką w repozytorium, powiedz Claude'owi wprost, żeby zapisał go w .claude/workflows wewnątrz projektu — domyślnie może wylądować w lokalizacji globalnej, poza projektem.
Wykorzystaj to, że workflow można zachować i odpalić ponownie: plan siedzi w zapisanym skrypcie, nie przy Claude'ie.
Zagnieźdź skill w workflow, jeśli pasuje — sub-agenty potrafią czytać i używać twoich skilli, więc skill mówi jak coś zrobić, a workflow decyduje, na ilu frontach to wykonać.

Na co uważać

Niepotrzebny zespół agentów. Nie buduj zespołu do zadania, które rozpada się na niezależne kawałki i nie wymaga, żeby agenci ze sobą gadali — zapłacisz wtedy za rozmowę, która niczego nie wnosi.
Workflow tam, gdzie nie trzeba. Pojedyncze poprawki, krótkie pytania, ogólna praca z wiedzą czy dążenie do jednego konkretnego rezultatu to dla workflow przerost formy. Sama nazwa nie zobowiązuje cię do używania go codziennie.
Jeden zbyt szeroki prompt. Może pochłonąć sporą część miesięcznego limitu i działać kilkadziesiąt minut — wracaj wtedy do faz 1 i 2.
ultracode na co dzień. To tryb najinteligentniejszy i najdroższy: łączy bardzo wysoki poziom rozumowania z workflow włączonymi domyślnie i pomija część zwykłych pytań o zgodę. Traktuj go jak świadomy, kosztowny wyjątek.

Jeśli chcesz zobaczyć workflow w działaniu, nie budując nic od zera, użyj /deep research — ta funkcja sama uruchamia workflow pod spodem: odpala wiele agentów do równoległego researchu, zleca im głosowanie nad każdą tezą, a na końcu dostajesz raport z przypisami.