Dynamic workflows in Claude Code — a checklist · Resource

Keep this open when you're deciding "run a workflow or not." Work the phases top to bottom: first settle whether the task even fits a workflow, then lock down cost, then check where the script lands and what to watch for. Every item opens with something you can act on and check off.

The rule that settles everything in one line: don't ask which feature is the strongest — ask which one fits the problem in front of you today.

0. Before you start — what you need to know

Confirm you're on Opus 4.8 or newer — dynamic workflows only shipped from that release on.
Pin down how a workflow differs from its neighbors, so you don't reach for the pricier option out of habit:
Skill is a repeatable recipe — an instruction you call with one command.
Sub-agent is a parallel helper with its own clean context; sub-agents don't talk to each other, each one reports its result back to your main session.
Agent team is a small crew sharing one task list that talks to itself — and you pay in tokens for that conversation.
/goal is depth: one objective, many passes, until the agent meets the completion criterion.
Dynamic workflow is breadth: a JavaScript script fires off many independent sub-agents at once, each on its own slice, and the results merge at the end.
Remember it's a ladder of rising power, cost, and risk: chat → skill → sub-agent → agent team → /goal → workflow. The higher you climb, the more you get done in one command, and the more you can burn along the way.

1. Decide whether you need a workflow at all

Ask one deciding question: does this task break into many pieces that can run independently, at the same time?
If yes — a workflow is worth considering.
If no — you almost certainly don't need one.
Match the tool to the job instead of reaching for the strongest one:
Something quick → just ask Claude.
A process you repeat → build a skill.
A tedious side task → hand it to a sub-agent.
A small crew that has to coordinate → an agent team.
Needs to keep going until a criterion is met → /goal.
A large task to parallelize → a dynamic workflow.
Check whether your case looks like the ones workflows suit well: reviewing every file in a codebase, or migrating four hundred files at once — many pieces, each getting its own lane and a separate agent's full attention.

2. Lock down cost before you run anything

First understand the mechanism: every agent is a full Claude call with its own context to read, so running many at once can spike input-token usage fast. Output tokens are usually far smaller and cheaper. So do three things before you hit "run":

Scope it tightly. State exactly where the agents should look and where they shouldn't — an unbounded scope (say, your whole desktop and every local repo) burns tokens wholesale.
Name a specific outcome. The more precisely you describe what you want, the less wasted work happens. The same logic applies to /goal — a vague instruction can loop for a long time.
Staff it with Haiku. It's the fastest and cheapest Claude model, well suited to many small, parallel jobs.

3. Launch the workflow and keep watching it

Wait for the confirmation prompt — a workflow never fires by accident.
Before anything runs, read the raw script that's about to execute.
While it's running, type /workflows and check every active run — you'll see how many agents are working, on which model, how many tokens they've used, and how long they've been running.
If something goes wrong, stop the run from /workflows.

4. Handle where it's saved and whether you reuse it

If you want the script kept in the repo, tell Claude explicitly to save it under .claude/workflows inside the project — by default it can land in a global location, outside the project.
Use the fact that a workflow can be saved and re-run: the plan lives in the saved script, not with Claude.
Nest a skill inside a workflow when it fits — sub-agents can read and use your skills, so the skill says how to do something and the workflow decides on how many fronts to do it.

What to watch for

An agent team you didn't need. Don't build a team for a task that breaks into independent pieces and doesn't require the agents to talk to each other — you'll pay for a conversation that adds nothing.
A workflow where none is needed. One-off fixes, quick questions, general knowledge work, or chasing one specific result are overkill for a workflow. The name alone doesn't obligate you to use it every day.
One prompt that's too broad. It can eat a large chunk of your monthly limit and run for tens of minutes — go back to phases 1 and 2 when that happens.
ultracode as a daily habit. It's the smartest and most expensive mode: it pairs very high reasoning with workflows on by default and skips some of the usual confirmation prompts. Treat it as a deliberate, costly exception.

If you want to see a workflow in action without building one from scratch, use /deep research — the feature runs a workflow under the hood on its own: it fires off multiple agents to research in parallel, has them vote on each claim, and hands you back a report with citations.