DYNAMIC WORKFLOWS v2.1.154+
Orchestrate dozens to hundreds of subagents from a script Claude writes — plus 24 copy-paste workflow scripts the docs don't give you.
A dynamic workflow is a JavaScript script that orchestrates subagents at scale. You describe a task, Claude writes the script, and a runtime executes it in the background — spawning dozens to hundreds of agents — while your session stays responsive. The script holds the loop, the branching, and the intermediate results, so only the final answer reaches Claude's context window.
Reach for one when a task needs more agents than a single conversation can coordinate, or when you want the orchestration codified as a script you can read and rerun: a codebase-wide bug sweep, a 500-file migration, or research that cross-checks its own sources. Below are 24 ready-to-run scripts you can copy, plus the full trigger, API, and runtime reference.
Subagents, skills, agent teams, and workflows can all run a multi-step task. The difference is who holds the plan — and a workflow moves it into code.
| Subagents | Skills | Agent teams | Workflows | |
|---|---|---|---|---|
| What it is | A worker Claude spawns | Instructions Claude follows | A lead supervising peers | A script the runtime executes |
| Who decides what runs next | Claude, turn by turn | Claude, per the prompt | The lead agent, turn by turn | The script |
| Where results live | Claude's context | Claude's context | A shared task list | Script variables |
| What's repeatable | The worker definition | The instructions | The team definition | The orchestration itself |
| Scale | A few per turn | Same as subagents | A handful of peers | Dozens to hundreds per run |
| Interruption | Restarts the turn | Restarts the turn | Teammates keep running | Resumable in the session |
A workflow can also apply a repeatable quality pattern — independent agents adversarially reviewing each other's findings, or a plan drafted from several angles and weighed against each other — for a more trustworthy result than a single pass.
Put the keyword ultracode in any prompt to run that single task as a workflow without changing the session effort level. Asking in your own words ("use a workflow") works too.
Set /effort ultracode to combine xhigh reasoning with automatic workflow orchestration — Claude then plans a workflow for every substantial task. Lasts the session; drop back with /effort high.
The built-in workflow: fans out web searches, cross-checks sources, votes on each claim, and returns a cited report with unsupported claims filtered out. Needs the WebSearch tool.
After a run does what you want, open /workflows, select it, and press s to save its script as a command. It then runs as /<name> in future sessions and accepts input via args.
Repeatedly fan out finders across the repo, dedupe against everything seen, then have independent skeptics try to refute each bug before it is reported.
When: You suspect latent bugs but have no single entry point. Keeps spawning finders until two consecutive rounds turn up nothing new.
One agent per OWASP-style dimension reviews the codebase; each finding is verified by a focused skeptic as soon as its review lands — no barrier between stages.
When: Pre-release hardening or a periodic security review across an entire service or repo.
Scout every route handler first, then check each one for an authorization guard in parallel. The official docs use this exact shape as the canonical ultracode example.
When: Confirming every endpoint under a routes directory enforces auth before a release.
List direct dependencies, then in parallel assess each for known CVEs, maintenance health, and license risk, returning only the ones worth acting on.
When: Quarterly supply-chain review or vetting before adding a dependency-heavy feature.
Enumerate user-facing pages, audit each against WCAG criteria, then group violations by severity so you fix the blockers first.
When: Bringing a UI up to WCAG AA, or catching regressions across many templates at once.
Discover every file using the old API, then migrate and verify each in its own git worktree so parallel edits never collide.
When: Swapping a framework or library across hundreds of files where agents must edit concurrently.
Find every call site of a deprecated function, then rewrite each to the replacement in parallel, reporting any that need human judgment.
When: Removing a deprecated internal API and cleaning up all of its consumers in one pass.
Port each source module to the target language in isolation, then immediately run its tests so a failing port is flagged without blocking the others.
When: Large ports like the Bun Zig→Rust effort — module-by-module with a test gate per unit.
Find candidate dead exports, confirm each truly has zero references (including dynamic/string uses), then remove only the confirmed ones.
When: Shrinking a codebase safely — the verify step prevents deleting something used via reflection or a string key.
Plan a rename (including docs, tests, and config), then apply it file-by-file in isolated worktrees, skipping unrelated same-named symbols.
When: Renaming a widely-used symbol when a naive find-and-replace would clobber unrelated matches.
Search a question from several angles, fetch and read the sources, vote on each claim, and synthesize a report with unsupported claims filtered out. This is the shape behind the bundled /deep-research.
When: Any research question where a single search pass is not trustworthy enough and sources must be checked against each other.
Draft a plan from several independent angles, score each with parallel judges, then synthesize a final plan from the winner while grafting the best ideas from the runners-up.
When: A hard design decision worth more than one pass before you commit — architecture, a rollout, a tricky refactor.
Point one reader at each subsystem to summarize its responsibilities and key files, then merge the summaries into a single architecture map.
When: Onboarding to an unfamiliar repo, or producing an up-to-date architecture overview on demand.
Investigate an incident from several blind angles at once — recent diffs, error logs, config changes, dependency bumps — then synthesize the most likely root cause.
When: A regression appeared and you want parallel lines of inquiry instead of one serial hunt.
Review the diff across dimensions (correctness, security, performance, tests), then have each finding adversarially verified before it is surfaced — the canonical review pattern.
When: A review you run on every branch. Save it and it runs the same orchestration each time.
For each module, identify behaviors with no test, rank by blast radius, and propose the specific test cases that would close each gap.
When: Deciding where to invest test effort, or hardening a module before a risky change.
Check each documentation page against the current code and flag statements that are now wrong — stale flags, renamed options, removed APIs.
When: Keeping a docs site or README honest after a release without re-reading everything by hand.
Scan CI history for tests that fail intermittently, diagnose the cause of each (timing, shared state, ordering), and propose a fix.
When: A flaky suite eroding trust in CI — turn the noise into a ranked, actionable list.
Find public functions lacking documentation and write accurate doc comments for each in an isolated worktree so parallel writes never conflict.
When: Bringing an under-documented public API up to standard in one pass.
Enumerate the test cases a module needs, write each as a test, then run the suite to confirm the new tests pass and actually exercise the code.
When: Backfilling tests for a critical module before you refactor it.
Classify each commit since the last release by type and audience impact, drop the noise, and group the rest into human-readable release notes.
When: Turning a messy commit range into clean release notes without hand-curating every line.
Have agents read setup, architecture, conventions, and the dev loop in parallel, then synthesize a single onboarding doc a new engineer can follow start to finish.
When: Producing a "day one" guide for a repo that has none, grounded in what the code actually does.
Find hardcoded user-facing strings across the UI and, for each, propose a stable translation key and the catalog entry to add.
When: Preparing an app for localization without manually combing every component.
Keep spawning audit rounds until the token budget you set with a "+Nk" directive is nearly spent — depth scales to what you are willing to pay for.
When: You explicitly want maximum coverage and have set a token target for the turn; the script self-paces to fill it.
The hooks available inside a workflow script. Default to pipeline() — it runs each item through every stage with no barrier between stages. Reach for parallel() only when a stage genuinely needs all prior results at once.
agent()agent(prompt, { schema?, label?, phase?, model?, isolation?, agentType? }) → PromiseSpawn one subagent. With a JSON-schema, it returns a validated object; without, its final text. Returns null if it is skipped or dies.
pipeline()pipeline(items, stage1, stage2, ...) → Promise<any[]>Run each item through every stage independently — NO barrier between stages. The default for multi-stage work. A throwing stage drops that item to null.
parallel()parallel(thunks) → Promise<any[]>Run thunks concurrently and await all of them — a barrier. A failing thunk resolves to null, so filter(Boolean) before use. Reach for it only when you need all results together.
phase()phase(title)Start a new progress group; later agent() calls are shown under it in /workflows.
log()log(message)Emit a progress line to the user above the progress tree.
argsargs: anyThe input passed to a saved workflow, verbatim. undefined if none. Read it for a question, target paths, or a config object.
budgetbudget: { total, spent(), remaining() }The turn token target from a "+Nk" directive. total is null if unset; remaining() is Infinity then. The target is a hard ceiling — agent() throws once it is hit.
workflow()workflow(nameOrRef, args?) → PromiseRun another saved workflow inline as a sub-step. Nesting is one level deep.
/config"disableWorkflows": trueCLAUDE_CODE_DISABLE_WORKFLOWS=1Ultracode keyword triggerA dynamic workflow is a JavaScript script that orchestrates subagents at scale. Claude writes the script for the task you describe, and a runtime runs it in the background — spawning dozens to hundreds of agents — while your session stays responsive. The script holds the loop, branching, and intermediate results, so only the final answer lands in Claude's context.
Include the keyword ultracode in your prompt (or just ask for "a workflow"), and Claude writes a workflow for that task. Or set /effort ultracode so Claude plans a workflow for every substantial task in the session. You can also run the bundled /deep-research, or any workflow you have saved.
Ultracode is a Claude Code setting that combines xhigh reasoning effort with automatic workflow orchestration. With it on, Claude decides when a task warrants a workflow and a single request can become several workflows in a row. It lasts for the session and resets when you start a new one.
Reach for a workflow when a task needs more agents than one conversation can coordinate, or when you want the orchestration codified as a repeatable script — codebase-wide audits, large migrations, and research that must cross-check its sources. With subagents, skills, and agent teams, Claude orchestrates turn by turn; a workflow moves the plan into code.
A workflow spawns many agents, so one run can use meaningfully more tokens than the same task in conversation. Runs count toward your plan usage and rate limits. To gauge spend, run on a small slice first — one directory, or a narrow question — and watch per-agent token usage in /workflows.
Yes. After a run does what you want, open /workflows, select it, and press s to save its script to .claude/workflows/ (shared in the repo) or ~/.claude/workflows/ (just you). It then runs as a /<name> command and can accept input through args.
Within the same session, yes — agents that already finished return their cached results and the rest run live. Resume from /workflows with p, or ask Claude to relaunch the same script. Exiting Claude Code while a run is going starts it fresh next session.
Up to 16 concurrent agents (fewer on limited CPUs) and 1,000 agents total per run. The script itself has no direct filesystem or shell access — agents do that work. There is no mid-run user input beyond agent permission prompts; for sign-off between stages, run each stage as its own workflow.
