Dynamiczne przepływy pracy i ultracode

Dynamiczny przepływ pracy (dynamic workflow) w Claude Code to skrypt JavaScript, który Claude pisze pod konkretne zadanie, a środowisko uruchomieniowe wykonuje w tle, orkiestrując od kilkudziesięciu do kilkuset subagentów na uruchomienie. Wyniki pośrednie zostają w zmiennych skryptu, nie w kontekście Claude. ultracode uruchamia go dla jednego promptu, a /effort ultracode pozwala planować go przy większych zadaniach.

Ta strona jest dla programistów, którzy przepuszczają przez Claude Code duże, powtarzalne zadania, oraz dla tech leadów, którzy chcą zapisać je jako wspólne, przeglądane polecenia. Problem, który rozwiązuje: prosisz Claude o audyt 140 handlerów tras, Claude deleguje pracę kilku subagentom, kontekst zapełnia się niedoczytanymi wynikami, a odpowiedź obejmuje jedną trzecią tras i nie wiadomo, którą.

Co daje Ci dobrze ustawiony dynamiczny przepływ pracy

• Regułę decyzyjną: kiedy przepływ pracy wygrywa z subagentami, /goal albo zwykłą sesją, zanim wydasz tokeny.
• Sześć promptów do skopiowania, które tworzą przepływy z wbudowaną fazą weryfikacji, a nie doklejoną na końcu.
• Zapisane, przeglądalne polecenie w .claude/workflows/, które zespół uruchamia na każdej gałęzi.
• Procedurę weryfikacji, która dowodzi poprawności wyniku bez czytania każdego pliku zmienionego przez agentów.
• Sposoby wyjścia z awarii, które naprawdę się zdarzają: zablokowane prośby o uprawnienia, ponowne uruchomienia po błędzie w środku fan-outu, limity użycia i przekroczone koszty.

Dynamiczne przepływy pracy pojawiły się w Claude Code v2.1.154 (2026-05-28). Wszystko na tej stronie sprawdzono 2026-09-26 w v2.1.283 (kanał latest) i w oficjalnej dokumentacji workflows, z wyjątkiem fragmentów, które podają datę 2026-10-12, wersję nowszą niż v2.1.283, Sonnet 5.5 lub Haiku 5.5; te sprawdziliśmy ponownie na Claude Code 2.1.296 i na stronach Anthropic 2026-10-12. Każda opisana tu funkcja przepływów, a także Opus 5.5 jako model domyślny (v2.1.280), jest na obu kanałach wydań: stable to v2.1.287 na 2026-10-12.

Kiedy przepływ pracy wygrywa z subagentami albo /goal?

Dynamiczny przepływ pracy to jeden z rodzajów agentowego przepływu pracy: zadanie jest wykonywane w kilku przebiegach, przez subagentów, a nie jedną odpowiedzią. Subagenci, umiejętności (skills), zespoły agentów (agent teams) i przepływy pracy potrafią wykonać zadanie wieloetapowe. Różnica polega na tym, kto trzyma plan:

	Subagenci	Umiejętności	Zespoły agentów	Przepływy pracy
Kto decyduje, co dalej	Claude, tura po turze	Claude, według instrukcji	Agent prowadzący, tura po turze	Skrypt
Gdzie są wyniki pośrednie	W oknie kontekstu Claude	W oknie kontekstu Claude	We wspólnej liście zadań	W zmiennych skryptu
Co da się powtórzyć	Definicję wykonawcy	Instrukcje	Definicję zespołu	Samą orkiestrację
Skala	Kilka delegowanych zadań na turę	Jak subagenci	Kilku długo działających partnerów	Dziesiątki do setek agentów na uruchomienie
Przerwanie	Restartuje turę	Restartuje turę	Członkowie zespołu działają dalej	Wznawialne w tej samej sesji

Reguła decyzyjna:

• Ten sam krok na wielu elementach (każda trasa, każdy komponent, każdy zmieniony plik): przepływ pracy.
• Wynik trzeba zweryfikować krzyżowo, zanim mu zaufasz (znaleziska bezpieczeństwa, twierdzenia badawcze): przepływ pracy, bo skrypt za każdym razem każe niezależnym agentom obalać cudze wyniki, a nie tylko wtedy, gdy Claude o tym pamięta.
• Stan końcowy to jeden warunek zaliczone/niezaliczone („build jest zielony”): /goal. Taniej i bez skryptu.
• Potrzebujesz dwóch, trzech wyszukań w tej turze: subagenci.
• Chcesz kilku długich sesji, którymi sterujesz sam: agent view.

Wzorce stojące za tymi wyborami (fan-out/fan-in, best-of-N z sędzią, rozdzielenie autora i recenzenta) oraz ich odpowiedniki w Codex i Cursorze opisuje strona o wzorcach orkiestracji wielu agentów. Porównanie opcji równoległych w jednym repozytorium znajdziesz w przepływach pracy na wielu plikach.

Uruchom pierwszy przepływ pracy

1. Sprawdź, czy przepływy pracy są włączone. Domyślnie są włączone na każdym planie poza Pro. Na Pro są wyłączone, dopóki nie włączysz wiersza Dynamic workflows w /config, który zapisuje enableWorkflows w ustawieniach użytkownika. Działają też w Amazon Bedrock, w Agent Platform w Google Cloud (dawniej Vertex AI) i w Microsoft Foundry.

2. Zatwierdź z góry narzędzia, których potrzebują agenci. Subagenci przepływu pracy korzystają z Twoich reguł uprawnień, a w trybie Manual każdy, który sięgnie po niezatwierdzone narzędzie, wstrzymuje uruchomienie prośbą o zgodę. Przed długim uruchomieniem dodaj polecenia testów, lintera i odczytu do permissions.allow w .claude/settings.json. Bezpieczny punkt wyjścia opisuje strona o uprawnieniach i sandboksie.

3. Zacznij od małego wycinka. Skieruj prompt na jeden katalog, przeczytaj raport, potem rozszerz zakres. Widok /workflows pokazuje zużycie tokenów na agenta, więc wycinek mówi Ci, ile będzie kosztować pełne uruchomienie.

4. Poproś o przepływ pracy. Umieść w prompcie słowo ultracode albo poproś własnymi słowami („use a workflow”). Claude pisze skrypt zamiast pracować tura po turze.

5. Zatwierdź plan. W trybach Manual i accept edits Claude Code pokazuje zaplanowane fazy z opcjami Yes, run it, View raw script i No (przy zapisanym lub wbudowanym przepływie dochodzi Yes, and don’t ask again dla tego przepływu w tym projekcie). Za pierwszym razem wybierz View raw script: z listy faz od razu widać, czy jest krok weryfikacji, zanim wydasz jakikolwiek token. Ctrl+G otwiera skrypt w edytorze, Tab pozwala poprawić prompt. W trybie auto zatwierdzasz tylko pierwsze uruchomienie, a w trybie bypass permissions nic nie pyta.

6. Obserwuj przebieg. Uruchom /workflows, wybierz przebieg i naciśnij Enter. Każda faza pokazuje liczbę agentów, sumę tokenów i czas.

Prompt do skopiowania: audyt autoryzacji z weryfikacją adwersarialną

ultracode: audit every route handler under src/routes/ for missing authentication or authorization checks. One agent per file. For each finding, record the file, line, the missing check and the request that would exploit it. Then run a second phase in which a different agent tries to refute each finding by reading the middleware chain in src/middleware/ and the router setup; keep only findings that survive. Return a table sorted by severity, plus a list of files that no agent could finish.

Ostatnie zdanie jest kluczowe. Raport z listą tego, czego nie udało się wykonać, odróżnia „brak znalezisk” od „brak znalezisk w 60% plików, które przeszły”.

Obserwuj i steruj przebiegiem w /workflows

Klawisz	Działanie
↑ / ↓	Wybór fazy lub agenta
Enter lub →	Wejście w fazę, potem w prompt, wywołania narzędzi i wynik agenta
Esc lub ←	Powrót o poziom wyżej
f	Filtrowanie agentów w fazie według statusu; kolejne naciśnięcia przełączają filtr
p	Wstrzymanie lub wznowienie przebiegu
x	Zatrzymanie wybranego agenta albo całego przebiegu, gdy fokus jest na przebiegu
r	Restart wybranego działającego agenta
s	Zapis skryptu przebiegu jako polecenia

Jednowierszowy pasek postępu jest też w panelu zadań pod polem wprowadzania. Naciśnij strzałkę w dół, żeby go zaznaczyć, a potem Enter, żeby go rozwinąć.

Jakie prompty dobrze działają jako przepływy pracy?

Przepływ pracy pasuje do zadania większego, niż zmieści jeden agent, albo do jednego kroku powtarzanego na wielu elementach. Każdy prompt poniżej ma warunek stopu i krok weryfikacji. Bez nich przepływ działa do limitu agentów i niczego nie weryfikuje. Prompty zostają po angielsku, bo tak najpewniej działają z narzędziami i komunikatami błędów.

Prompt do skopiowania: migracja z JavaScriptu na TypeScript z bramką typów

use a workflow to migrate every component under src/components/ from JavaScript to TypeScript. Work on each file in its own isolated copy so edits don't conflict. After each file, run npx tsc --noEmit on that file's copy and keep the change only if it type-checks without adding any `any` or `@ts-ignore`. Use a smaller model for the per-file conversions and the session model for the final merge. Finish by running npm test once on the merged result and report: files migrated, files skipped with the reason, and the test summary.

Prompt do skopiowania: poprawiaj, aż sprawdzanie typów przejdzie

use a workflow to run npx tsc --noEmit and keep fixing the reported errors until the type check passes or two rounds in a row make no progress. Group errors by file and give each file to its own agent. Do not change any file under src/generated/ and do not loosen tsconfig.json. At the end, report the error count per round and any errors left.

Prompt do skopiowania: przegląd każdego pliku PR scalony w jedno podsumowanie

use a workflow to review every file changed on this branch against origin/main for correctness bugs: wrong conditions, missing error handling, broken invariants, unsafe concurrency. One reviewer per file. Then have one agent deduplicate the findings, drop anything it cannot point to a specific line for, and rank the rest by user impact. Output a markdown list with file:line, the bug, and a one-line reproduction.

Prompt do skopiowania: szukaj niestabilnych testów, aż lista przestanie rosnąć

use a workflow to find flaky tests in this repo: run the test suite repeatedly in parallel batches, record which tests fail intermittently with their error messages, and stop once two rounds in a row find nothing new. Do not edit any test. Report each flaky test with its failure rate across all runs and the most likely cause.

Do pytań badawczych służy wbudowany przepływ /deep-research. Rozsyła wyszukiwania w sieci pod kilkoma kątami, weryfikuje źródła krzyżowo, głosuje nad każdym twierdzeniem i zwraca raport z cytowaniami, z którego odrzucono obalone twierdzenia. Twierdzenia, których weryfikatorzy nie zdołali sprawdzić (na przykład po limicie zapytań), trafiają na listę niezweryfikowanych, a nie znikają. Wymaga narzędzia WebSearch:

/deep-research What changed in the Node.js permission model between v20 and v22?

Interaktywna sesja w terminalu pozwala na 200 wywołań WebSearch, a wyszukiwania z głównej rozmowy i ze wszystkich agentów liczą się do tego jednego limitu, więc szeroka rozsyłka badawcza może go osiągnąć. Od v2.1.290 (na 2026-10-12 tylko kanał latest) limit uzupełnia się o około 100 wywołań na godzinę, a CLAUDE_CODE_WEB_SEARCH_REFILLS_PER_HOUR zmienia tempo; w sesji nieinteraktywnej domyślnie jest to 0, czyli uzupełnianie wyłączone. CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION podnosi limit, a /clear zeruje licznik (strony narzędzi i zmiennych środowiskowych Claude Code, sprawdzone 2026-10-12).

Jak zweryfikować wynik przepływu pracy bez czytania każdego pliku?

Przepływ pracy może zmienić 500 plików. Czytanie każdego diffu przekreśla sens całego zabiegu. Wbuduj dowód w przebieg i sprawdzaj dowód:

1. Wpisz w prompt deterministyczną bramkę. „Zachowaj zmianę tylko wtedy, gdy tsc przechodzi” albo „uruchom raz npm test na scalonym wyniku” zamienia deklarację agenta w sprawdzenie wykonane przez maszynę. Robią to prompty migracji i sprawdzania typów powyżej. Zestaw testów jest wart tyle, ile jego asercje; zobacz, jak mocna jest Twoja wyrocznia testowa.
2. Wymagaj fazy adwersarialnej przy znaleziskach. Audyty i przeglądy powinny kończyć się agentami, którzy próbują obalić każde znalezisko. Raport zawiera wtedy tylko to, co przetrwało, a Ty sprawdzasz wyrywkowo dwa, trzy znaleziska zamiast wszystkich.
3. Wymagaj listy „niezrobione”. Każdy prompt powyżej prosi o pominięte lub niedokończone elementy. agent() zwraca null, gdy agenta zatrzymano albo trafił na nienaprawialny błąd API, więc skrypt, który po cichu odfiltrowuje null, może raportować sukces przy częściowym pokryciu.
4. Porównaj liczby z repozytorium. Zestaw „pliki zmigrowane plus pominięte” z wynikiem git ls-files src/components | wc -l w terminalu. Rozbieżność oznacza, że faza wyszukiwania plików coś pominęła.
5. Raz uruchom pełną bramkę sam. Po przebiegu uruchom zwykłe sprawdzanie typów, linter i testy, potem otwórz pull request. CI i agenci recenzujący sprawdzają go ponownie, jak każdą inną zmianę. Zbierz wyniki w pakiet dowodów, żeby recenzent zatwierdzał dowody, a nie diff czytany linia po linii.

Kto zatwierdza: pull request należy do programisty, który uruchomił przebieg. Zapisane zespołowe przepływy w .claude/workflows/ tech lead przegląda jak każdy inny kod, bo każde kolejne uruchomienie powtarza ich logikę.

Pozwól Claude decydować dzięki ultracode

ultracode to ustawienie Claude Code, a nie poziom wysiłku modelu. Nie zmienia poziomu wysiłku sesji (od v2.1.284; wcześniej ustawiał xhigh) i każe Claude planować przepływ pracy przy każdym większym zadaniu bez proszenia. claude --effort ultracode i wartość effortLevel: "ultracode" w Agent SDK dodatkowo ustawiają poziom xhigh. Wybór innego poziomu w /effort już nie wyłącza ultracode: wyłączysz go przez /effort lub ustawienie ultracode. Jedno polecenie może zamienić się w kilka przepływów po kolei: jeden do zrozumienia kodu, drugi do zmiany, trzeci do weryfikacji.

/effort ultracode

Inne sposoby włączenia: uruchom claude --effort ultracode (v2.1.203 lub nowsza), przesuń suwak wysiłku w selektorze /model na ultracode albo ustaw "ultracode": true w pliku ustawień, żeby każda sesja startowała z nim.

Ultracode jest dostępne tylko wtedy, gdy spełnione są oba warunki:

• Dynamiczne przepływy pracy są dla Ciebie włączone.
• Model obsługuje xhigh. Na 2026-10-12 są to Claude Opus 5.5, Sonnet 5.5, Haiku 5.5, Opus 5, Sonnet 5, Fable 5.1, Fable 5, Opus 4.8 i Opus 4.7. Nie obsługują go Opus 4.6 ani Sonnet 4.6, a Haiku 4.5 nie ma ustawienia wysiłku.

Limit wysiłku nie wyłącza ultracode: od v2.1.284 zostaje włączony na poziomie limitu.

Ultracode zwiększa koszt każdego polecenia

Ultracode dotyczy każdego zadania w sesji, więc istotne polecenie może zamienić się w jeden lub kilka przepływów pracy z wieloma agentami i zużywa więcej tokenów oraz trwa dłużej niż to samo polecenie w zwykłej turze na tym samym poziomie wysiłku. Na planie subskrypcyjnym sesja szybciej dochodzi do limitu sesyjnego lub tygodniowego. Ultracode wyłącza też trzy zabezpieczenia: ostrzeżenie Large workflow, limit równoległych subagentów w sesji i (w trybie auto) zatwierdzenie pierwszego uruchomienia. Wyłącz ultracode w /effort, gdy wracasz do rutynowej pracy. Od v2.1.280 domyślnym modelem Claude Code jest Opus 5.5, który domyślnie działa z wysiłkiem medium; domyślne ustawienia u poszczególnych dostawców opisuje hub modeli.

Ani zapisywane ustawienie effortLevel, ani zmienna CLAUDE_CODE_EFFORT_LEVEL nie przyjmują wartości ultracode. Jeśli CLAUDE_CODE_EFFORT_LEVEL albo limit wysiłku ustawia poziom sesji, ultracode zostaje włączony na tym poziomie (od v2.1.284).

Zapisz przepływ pracy, który zespół uruchamia ponownie

Gdy przebieg zrobił to, czego chciałeś, zapisz jego skrypt jako polecenie:

1. Uruchom /workflows, wybierz przebieg i naciśnij s.
2. Klawiszem Tab wybierz lokalizację:
   • .claude/workflows/ w projekcie, wspólną dla wszystkich, którzy sklonują repozytorium. Commituj ją i przeglądaj jak kod.
   • ~/.claude/workflows/, dostępną we wszystkich Twoich projektach i widoczną tylko dla Ciebie.
3. Naciśnij Enter. Przepływ działa teraz jako /<nazwa> i pojawia się w podpowiedziach po wpisaniu /.

Jeśli przepływ projektowy i osobisty mają tę samą nazwę, uruchamia się projektowy. W monorepo zapis trafia do najbliższego istniejącego katalogu .claude/workflows/ między katalogiem roboczym a korzeniem repozytorium. Żeby udostępnić przepływ w wielu repozytoriach, umieść go w katalogu workflows/ wtyczki; działa wtedy jako /<wtyczka>:<nazwa>.

Zapisany przepływ przyjmuje dane wejściowe. Napisz „Run /triage-issues on issues 1024, 1025, and 1030”, a Claude przekaże listę do skryptu jako globalną zmienną args, już w postaci strukturalnej.

Zapisany plik wygląda tak. Rzadko go edytujesz, ale przy przeglądzie warto go rozpoznać:

export const meta = {
  name: 'audit-routes',
  description: 'Audit every route handler for missing auth checks',
}

const found = await agent('List every .ts file under src/routes/.', {
  schema: { type: 'object', required: ['files'], properties: { files: { type: 'array', items: { type: 'string' } } } },
})

const audits = await pipeline(found.files, file =>
  agent(`Audit ${file} for missing authentication checks.`, { label: file }),
)

return audits.filter(Boolean)

agent() uruchamia jednego subagenta, pipeline() po jednym na element listy, parallel() zestaw naraz, a phase() grupuje agentów pod tytułem w widoku postępu. schema sprawia, że agent zwraca zwalidowany JSON zamiast prozy. Przy przeglądzie sprawdź dwie rzeczy: czy istnieje faza weryfikacji i czy .filter(Boolean) idzie w parze z licznikiem odrzuconych elementów, zamiast je ukrywać.

Prompt do skopiowania: dodaj fazę weryfikacji do zapisanego przepływu

Najpierw uruchom /workflow-authoring, żeby Claude wczytał dokumentację skryptów, a potem wyślij:

Edit .claude/workflows/audit-routes.js: after the audit pipeline, add a phase titled "Verify" in which a separate agent per finding tries to refute it by reading src/middleware/. Return only surviving findings, plus a count of files whose audit agent returned null. Keep the meta block a plain object literal.

/workflow-authoring (v2.1.248 lub nowsza) ładuje dokumentację pisania skryptów, z której korzysta Claude. Po edycji uruchom /reload-skills, a potem ponownie /<nazwa>.

Uruchom zapisany przepływ bez interakcji w CI

Słowo ultracode nie uruchamia przepływu, gdy prompt przychodzi przez claude -p, przez wiadomość Agent SDK nieoznaczoną jako wpisana przez człowieka, z zaplanowanego zadania albo z przekazanego webhooka lub komentarza w pull requeście. To celowe: tekst, którego nie wpisałeś, nie może zgodzić się w Twoim imieniu na duże uruchomienie. W trybie bez interakcji wywołaj zapisany przepływ po nazwie i jawnie go dopuść:

claude -p "Run /audit-routes" --allowedTools "Workflow(audit-routes)" "Read" "Grep" "Glob"

Workflow(<nazwa>) zatwierdza ten jeden zapisany przepływ, a sama reguła Workflow zatwierdza wszystkie. Przy audytach zostaw resztę listy narzędzi tylko do odczytu. W CI uruchamiaj to wyłącznie na zaufanych refach i nigdy z sekretami w środowisku zadania, które pobiera kod kontrybutora; bezpieczny układ zadania opisuje strona o automatyzacji i uruchomieniach bez interakcji.

Limity, które wpływają na treść promptu

Limit	Co oznacza dla promptu
Brak wejścia od użytkownika w trakcie przebiegu	Jeśli potrzebujesz akceptacji między etapami, uruchom każdy etap jako osobny przepływ.
Skrypt nie ma dostępu do systemu plików, powłoki ani import()	Agenci czytają, piszą i uruchamiają polecenia; skrypt tylko koordynuje. Pracę wymagającą biblioteki umieść w zadaniu agenta.
Domyślnie do 16 równoległych agentów, mniej na maszynach i w kontenerach z mniejszą liczbą CPU	Podnoś limit przez CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS (1–256, v2.1.269 lub nowsza) tylko przy fan-outach ograniczonych inferencją.
Do 4096 elementów w jednym wywołaniu pipeline() lub parallel(); 1000 agentów na przebieg	Większe zadania dziel na partie według katalogów.
Date.now(), Math.random() i bezargumentowe new Date() rzucają wyjątek w skrypcie	Przekaż znacznik czasu przez args. Dzięki temu ponowne uruchomienie odtwarza te same wywołania agent().
Wytyczna rozmiaru: small poniżej 5 agentów, medium poniżej 10, large poniżej 50 albo unrestricted	Domyślnie medium (small na Pro od v2.1.271). To rada dla Claude, a nie twardy limit. Ustawisz ją przez /config workflowSizeGuideline=small lub klucz workflowSizeGuideline.

Każdy agent działa na modelu, który skrypt wskazuje dla jego etapu, albo na modelu sesji, gdy żaden nie jest wskazany. Poproś w prompcie o mniejszy model dla etapów mechanicznych, jak w prompcie migracji. Jeśli lista availableModels Twojej organizacji blokuje żądany model, agent działa na zamienniku, a /workflows pokazuje ostrzeżenie z nazwami obu modeli. Żeby uruchomić wszystkie agenty przepływu pracy na jednym modelu, a pozostałym subagentom zostawić ich własne, ustaw CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL (v2.1.296, na 2026-10-12 tylko kanał latest; wpis w changelogu Anthropic nie mówi nic więcej).

Gdy przebieg planuje więcej niż 25 agentów albo prognozuje ponad 1,5 mln tokenów, pasek postępu pokazuje ostrzeżenie Large workflow. Ma ono charakter informacyjny; zatrzymaj przebieg w /workflows, jeśli liczby Cię zaskoczą. Jeśli sam wybierzesz wytyczną rozmiaru, jej liczba agentów zastępuje próg 25.

Agenci jednego przebiegu dzielą cache promptów, gdy mają ten sam model, wysiłek, narzędzia, schemat wyniku i katalog roboczy, więc jednolity fan-out kosztuje mniej niż zróżnicowany. Ich cache żyje domyślnie pięć minut; jeśli etapy przebiegu stoją dłużej, ustaw subagentPromptCacheTtl na 1h (zapis do cache godzinnego jest droższy). Budżety dla zespołu opisuje strona o kontroli kosztów.

Co się psuje przy dynamicznych przepływach pracy?

Przebieg stoi od kilku minut. Agent czeka na zgodę na uprawnienie; poza oczekiwaniem na reset limitu użycia to jedyna rzecz, która sama wstrzymuje przebieg. Odpowiedz na prośbę, a przed następnym uruchomieniem dodaj to narzędzie do permissions.allow.

Jeden agent padł, a ponowne uruchomienie powtórzyło pół zadania. Przy ponownym uruchomieniu zakończeni agenci zwracają zapisane wyniki tylko do pierwszego agenta, który zawiódł albo którego prompt się zmienił; wszystko, co wystartowało po nim, działa od nowa. Jeśli A, B, C i D startowały w tej kolejności, a B zawiódł, A wraca z pamięci podręcznej, a B, C i D wykonują się ponownie. Zatrzymanie pojedynczego agenta klawiszem x liczy się jako błąd. Wyjście: jeśli zamierzasz uruchomić ponownie, zatrzymuj cały przebieg, a nie pojedynczych agentów, i dziel kosztowne etapy na osobne przepływy.

Po powrocie przebiegu nie ma. Wznawianie działa w tej samej sesji. Jeśli wyszedłeś przez Exit and stop tasks, wróć do tej sesji przez claude --resume i poproś Claude o ponowne uruchomienie; ukończeni agenci zwrócą zapisane wyniki. Nowa sesja nie zna wcześniejszego przebiegu i zaczyna od zera. Jeśli Claude Code w ogóle nie znajdzie zapisanych wyników, ponowne uruchomienie kończy się błędem nothing to resume; poproś wtedy Claude o start przepływu jako nowego przebiegu. Następnym razem, przy włączonym agent view, wybierz Move to background and exit, żeby przebieg działał dalej.

Agenci padają na limicie użycia. Od v2.1.271 interaktywny przebieg zalogowany subskrypcją claude.ai wstrzymuje się i wznawia po resecie, o ile autoContinueAtUsageLimit jest włączone, reset nastąpi w ciągu 24 godzin, a przebieg nie czekał już dwa razy. W claude -p, Agent SDK i sesji w tle agenci zamiast tego zawodzą. Przebiegi bez interakcji ograniczaj przez workflowSizeGuideline i wąski wycinek.

Słowo „ultracode” w prompcie uruchomiło niechciany przebieg. Naciśnij Option+W na macOS lub Alt+W na Windows i Linuksie, żeby odrzucić wyróżnienie dla tego promptu. Żeby słowo w ogóle przestało działać, wyłącz Ultracode keyword trigger w /config albo ustaw "workflowKeywordTriggerEnabled": false w pliku ustawień.

W /effort nie ma ultracode. Model nie obsługuje xhigh albo przepływy pracy są wyłączone. Przełącz się przez /model na model obsługujący xhigh (Opus 5.5 jest domyślny od v2.1.280 na obu kanałach wydań) albo zapytaj administratora, czy przepływy pracy są wyłączone.

Raport jest pewny siebie, ale ubogi. Skrypt odfiltrował wyniki null albo faza wyszukiwania pominęła pliki. Uruchom ponownie z promptem, który wymaga listy „niezrobione”, i porównaj liczby z git ls-files, jak w sekcji o weryfikacji.

W trybie auto klasyfikator blokuje akcję agenta, która miała przejść. Prompt, który skrypt przekazuje do agent(), nie liczy się jako Twoje polecenie, gdy klasyfikator ocenia akcje tego agenta, bo Claude Code oznacza go jako tekst wyliczony przez skrypt. „Zadanie kazało” nie jest więc dowodem Twojej intencji. Z góry zatwierdź potrzebne agentom polecenia w permissions.allow albo uruchom ten etap w trybie Manual z tymi regułami.

Równoległe edycje się zderzyły. Agenci pisali do tych samych plików. Poproś w prompcie o „each file in its own isolated copy”, jak w prompcie migracji, i scalaj w fazie końcowej.

Wyłącz przepływy pracy dla siebie lub całej organizacji

• Dla siebie: wyłącz Dynamic workflows w /config, ustaw "disableWorkflows": true w ~/.claude/settings.json albo ustaw CLAUDE_CODE_DISABLE_WORKFLOWS=1 w środowisku, z którego uruchamiasz Claude Code (zmienna jest odczytywana przy starcie).
• Dla organizacji: ustaw "disableWorkflows": true w ustawieniach zarządzanych albo użyj przełącznika na stronie ustawień administracyjnych Claude Code.
• Żadne ustawienie nie wyłącza samego ultracode, a limit wysiłku (maxEffortLevel) go nie wyklucza: od v2.1.284 zostaje włączony na poziomie limitu. Żeby go wykluczyć, wyłącz przepływy pracy.

Gdy przepływy są wyłączone, znikają wbudowane polecenia i /workflow-authoring, słowo kluczowe przestaje działać, a ultracode znika z menu /effort. Przebieg, który już trwa, działa dalej.

Dokąd dalej z dynamicznymi przepływami pracy

Własni subagenci Zdefiniuj wyspecjalizowanych wykonawców, na których przepływ pracy rozdziela zadania, z własnym modelem i listą narzędzi.

Przepływy celu z /goal Gdy stan końcowy to jeden warunek zaliczone/niezaliczone, ustaw cel zamiast pisać fan-out.

Wzorce orkiestracji wielu agentów Fan-out/fan-in, best-of-N z sędzią i rozdzielenie autora i recenzenta w Claude Code, Codex i Cursorze.

Agent view Uruchamiaj i monitoruj wiele sesji w tle z jednego panelu i zachowaj działające przepływy po wyjściu.