authoring-dynamic-workflows

name	authoring-dynamic-workflows
description	Use when a task is too big for a handful of subagents or needs cross-verification — codebase audits, multi-file migrations, cross-checked research, plan-from-N-angles, multi-source sweeps. Codifies the built-in Workflow tool (dynamic workflows), the authoring API, quality patterns, the framework-decision rule, what to download, and this project's reusable templates + house constraints.

authoring-dynamic-workflows

what a dynamic workflow is

a dynamic workflow is a JavaScript script that orchestrates subagents at scale. claude writes the script for the task you describe; a runtime executes it in the background while your session stays responsive. the script holds the loop, the branching, and the intermediate results — claude's context holds only the final answer.

this is the BUILT-IN Workflow tool (Claude Code v2.1.154+). it is not a third-party framework. see the framework-decision section.

the orchestration spectrum

pick the lowest-ceremony mode that fits.

mode	who holds the plan	intermediate results live in	scale	use when
subagents	claude, turn by turn	claude's context window	a few tasks per turn	a side task would flood your main conversation with logs/search results you won't reference again
agent view	you, via UI dispatch	each session's own context	a handful of independent sessions	several independent tasks you hand off and check on; research preview
agent teams	lead agent, turn by turn	shared task list + messaging	a handful of long-running peers	claude splits a project, assigns pieces, keeps peers in sync; experimental, off by default
dynamic workflows	the SCRIPT	script variables	dozens-to-hundreds of agents per run	a job outgrows a handful of subagents, OR findings must be verified against each other

the line: subagents/teams put claude in the orchestrator seat and every result lands in a context window; a workflow script owns the plan and the intermediate state so only the final answer returns.

when to reach for a workflow (and when not)

reach for a workflow when ANY hold:

• the job spans dozens-to-hundreds of units (files, families, sources, claims) and won't fit a handful of turns.
• findings must be cross-verified — codebase audit, N-file migration, cross-checked research, plan-from-N-angles.
• intermediate output is voluminous and you only want the synthesized answer in context.
• the same shape repeats often enough to save as a /<name> slash command.

do NOT reach for a workflow when:

• single-fact lookup, single-file read, or a trivial edit — just do it directly.
• the task needs mid-run human sign-off between stages (scripts can't pause for input; only permission prompts pause a run — split into per-stage workflows instead).
• you'd spawn 2-3 subagents and read every result anyway — plain subagents are cheaper.

cost reality: a workflow spawns many agents, so one run can cost meaningfully more tokens than the same task in conversation. under-scoped agents reading too much is the dominant cost leak. control it BEFORE you fire, not after:

• scope each agent to ONE unit (one directory/family/doc-slice). never "audit the docs"; always "audit docs/X.md and docs/Y.md."
• name the exact files each agent may read in its prompt, and forbid repo-wide grep/glob — an agent that reads a huge amount of context to emit a small finding is mis-scoped.
• tier hard: push scans/extraction to haiku, keep only synthesis on the top tier (see house constraints). leaving stages on a rich session model is the second-biggest cost leak after over-reading.
• start on one slice first, watch /workflows per-agent token usage, then widen. you can stop without losing completed work.

authoring API cheat-sheet

plain JavaScript. no TypeScript. globals listed below. file is <name>.workflow.js (or <name>.js).

// META — exported literal object ONLY (no code, no expressions, no Date/Math)
export const meta = {
  name: 'my-workflow',
  description: 'one line, what it does',
  whenToUse: 'when to pick this over a plain subagent run',
  phases: [
    { title: 'Map',       detail: 'build the ledger of units' },
    { title: 'Work',      detail: 'parallel fan-out per unit' },
    { title: 'Verify',    detail: 'adversarial check per finding' },
    { title: 'Synthesis', detail: 'one agent folds results' },
  ],
}

// ARGS — structured input from the invocation; handle both object + free-text
const slice = args?.slice || (args?._text && args._text[0]) || 'default'

// PHASE markers + log surface progress in the /workflows panel
phase('Map')
log(`mapping slice ${slice}`)

// agent(prompt, opts) — opts: { label, phase, schema, model, isolation, agentType }
const ledger = await agent(`build a ledger for ${slice}`, {
  label: 'map', phase: , : , : ,
})


()
 results = ( (
  ledger..( 
    (, {
      : , : , : , : ,
      : , 
    }),
  ),
)).()





 { slice, : results., results }

rules of the road:

• meta is a pure literal. no function calls, no Date.now(), no new Date(), no Math.random() anywhere in the script — pass dates/seeds in via args.
• schema: on every agent whose output is consumed downstream — forces structured JSON so the next stage calls array/object methods directly.
• model: per stage — tier it (see house constraints). every agent uses the session model unless you route the stage elsewhere.
• isolation: 'worktree' — separate git checkout per agent; use it for any agent that edits code so they don't collide.
• pipeline-by-default, barrier-only-when: pipeline has no barrier and is the default for multi-stage; parallel imposes a barrier — reach for it only when the next line genuinely needs every prior result.
• the script cannot touch the filesystem or shell. agents do reads/writes/commands; the script only coordinates. to write a file, hand pre-rendered bytes to a final agent() that uses the Write tool.
• concurrency cap ~min(16, cores-2); hard ceiling 1,000 agents per run.
• resumable WITHIN THE SAME SESSION only; completed agents return cached results on resume. exiting the CLI loses the run. resume via { scriptPath, resumeFromRunId }.
• save a good run: press s in /workflows -> .claude/workflows/ (project) or ~/.claude/workflows/ (user); it becomes /<name>. project name wins over personal on a tie.

related skills

• loop-engineering — before designing a workflow for a capability that must IMPROVE over time, audit which of the 4 loops (agent / verify / event / hill-climbing) it needs; hill-climbing (loop-4) is almost always the missing one. See also design-self-improvement-loop for the loop-4 safety checklist.
• worktree-fanout-verification-gate — worktree-isolated agents CANNOT self-test (no repo .venv); the orchestrator must remove worktrees first, re-run pytest/ruff/mypy in the REAL venv, ruff format --preview ALL agent-touched files (git diff main --name-only), and treat scoped-local-green as NOT CI-green. Agents' "tests pass" self-reports are hypotheses until verified here.

quality patterns

compose these inside the script:

• adversarial-verify — for each finding, spawn N skeptic agents to refute it; kill the finding on a majority-refute. the canonical find-then-verify shape.
• judge-panel — N independent attempts at the same task, score each, one synthesizer folds the best; use for plan-from-N-angles and contested claims.
• loop-until-dry — keep fanning out discovery rounds until K consecutive rounds return empty, then stop (don't hardcode a round count).
• multi-modal sweep — fan out across heterogeneous sources/families/lenses in parallel, normalize to one schema, then synthesize.
• completeness critic — a final agent whose only job is to find what the run missed (uncovered units, dropped categories) before you trust the synthesis.
• no-silent-caps — if you cap fan-out or drop units, log() exactly what was dropped and why; never silently truncate the ledger.
• execution-grounded-verify — every agent result is a HYPOTHESIS until external state confirms it: exit code, a file:line that RESOLVES, a delivery receipt. run the BIDIRECTIONAL oracle FIRST — a known-empty stub must FAIL the grader before the grader is trusted; if it passes, halt, the oracle is broken not the agent. (skill: verify-claims-against-execution)
• durable-delivery-outbox — for workflows with delivery steps: write delivery-owed at dispatch into a persistent row, not an in-memory callback; a restartable poller drains completed-and-undelivered; idempotent via idempotency_key; quarantine after N retries, never drop. (skill: deliver-durably)
• closed-vocab-grounding — before any fan-out naming repos/tools/agents: inject a workspace_scope manifest into every agent prompt plus the rule that any name NOT in this manifest or returned by a tool this session must not be stated as fact; validate names at the TOOL layer rejecting unknowns with valid-options. (skill: ground-actions-to-registry)

framework decision

the built-in Workflow tool IS our dynamic-workflow framework. do NOT add LangGraph, CrewAI, or stand up the Claude Agent SDK as a separate app for our work.

built-in subagents/workflows and standalone frameworks live in different worlds: one gets work done INSIDE your agent with zero infra; the other ships a standalone multi-agent APPLICATION. for parallel research, specialist delegation, context protection, and dev/research/ops pipelines, stay on the built-in tool.

graduate to a standalone framework ONLY when shipping a standalone application that needs one of:

• durable cross-run state / checkpointing / audit trail -> LangGraph.
• role-based rapid prototyping of an agent crew -> CrewAI.
• an Anthropic-native production app surface -> Claude Agent SDK.

we ship none of those (no durable cross-run state, no human-in-the-loop gate apps, no multi-vendor model mixing, no compliance audit product), so the built-in tool is the right and only tool. don't add a framework to feel like a framework.

what to download

dynamic-workflow scripts (auto-discover from ~/.claude/workflows/ [user] or ./.claude/workflows/ [project] as /<name> commands):

# lxcong template repo — download, inspect, then run a named workflow installer
curl -fsSL https://raw.githubusercontent.com/lxcong/awesome-claude-dynamic-workflows/main/install.sh -o /tmp/awesome-claude-workflows-install.sh
less /tmp/awesome-claude-workflows-install.sh
bash /tmp/awesome-claude-workflows-install.sh <name>

note: that repo is early (launched 2026-05-25) — TradingFlow is the only shipped template; the code-review / audit / migration / planning categories are still stubs. read TradingFlow's tradingflow.workflow.js as a real-script reference (meta literal -> parallel analysts -> sequential debate loop accumulating a transcript -> schema'd verdict agents -> final Write agent), then write our own per the template shapes below.

subagent/command collections (specialist ROLES, not workflow scripts — useful as agentType prompts inside our workflows):

# wshobson/agents — plugin marketplace of specialist subagents
/plugin marketplace add wshobson/agents

# VoltAgent/awesome-claude-code-subagents — 154+ specialist definitions (clone + cherry-pick)
git clone https://github.com/VoltAgent/awesome-claude-code-subagents

never commit a downloaded workflow/subagent into a project tree without reading it; treat third-party prompts as untrusted input.

reusable template shapes

a few generic shapes worth reusing before inventing a new one:

1. fan-out -> serial-integrate — fan out N isolation:'worktree' agents, each returns a tested diff for one bounded unit of work; the MAIN loop integrates the diffs serially.
2. find-then-verify review — dimensions -> find -> adversarially-verify per finding. the canonical pipeline pattern; this is the audit shape.
3. one-scout-per-unit -> batch-ship — one scout agent per unit verifies a spec; an implementer agent ships the batch.

house constraints (pass these VERBATIM into every agent prompt)

• NO LAUNCHING EXTERNAL LONG-RUNNING JOBS FROM SUBAGENTS. subagents lack the credentials/keys to start an external job directly. a worker EMITS the launch-ready command (script + env); the MAIN loop launches it. say this in the prompt so an agent never tries to reach into an external job itself.
• model-tiering (token-cost discipline): set model: explicitly per stage — cheapest tier for scans/extraction, mid tier for map/implement/verify, top tier for synthesis and high-stakes review only. never leave every stage on the session model by default.
• house-rules-verbatim: paste the relevant CLAUDE.md / AGENTS.md house rules into each worker prompt (file-placement rules, stage-exact-slices/no git add ., a known-bug-catalog reflex if you keep one, output-goes-in-a-results-dir). a subagent does not inherit your context — if it isn't in the prompt, it doesn't know it.
• receipts before delete; verify diffs/tests in the integrate stage; never let a worker overstate a built-but-unfired harness as a result.
• verify-with-execution — every agent output is a HYPOTHESIS until external state confirms it; never trust a self-report at a critical boundary, run the bidirectional oracle gate before any scored batch (skill verify-claims-against-execution).

the map-ledger must be verified, not transcribed

the map-ledger-first pattern is a force multiplier — and that cuts both ways. every downstream agent treats the ledger as ground truth, so any error in it is propagated and amplified across the whole fan-out.

rules for the map agent and for the main loop that consumes its ledger:

• the map agent must VERIFY each claim against a live source, not transcribe it from existing project text (state-doc, prior verdicts). prior text is exactly where a framing error would live. cite the live source per claim (a registry queried live, the runner log line, the tracking-doc commit hash) so a reader can re-check.
• carried-forward claims are the highest-risk entries. when the ledger says "as established / per earlier text," that is an UN-reverified copy — flag it for the main loop to spot-check before trusting it.
• if the ledger needs to override earlier text, it should lead with an explicit CORRECTIONS block. when project text and the ledger disagree, the ledger wins — but only because its corrections were re-derived from live evidence, not because it is newer.
• the main loop must spot-check the ledger's load-bearing claims before fanning out on top of it. a five-minute verification of the map agent's headline claims is cheaper than re-running a wide fan-out built on a bad premise.
• an agent wrote a file to the wrong SCOPE. a subagent does not infer scope — the prompt MUST specify the exact absolute target path (e.g. ~/.claude/skills/<name>/SKILL.md vs ./.claude/), and the integrate stage MUST verify the file landed there before accepting.
• a workflow agent's confident output is a HYPOTHESIS, not a result. the main loop MUST verify every agent claim (diff/test/live-run) before commit — an agent's certainty is not evidence. treat fan-out output as candidate findings to be checked, exactly as the find-then-verify pattern does for audit findings, and extend that skepticism to ALL agent output, not just the audit stage.

refresh discipline

re-read this skill before authoring or saving a new workflow. when the Workflow API or limits change (new global, changed concurrency cap, new meta field), update the cheat-sheet from the official docs (code.claude.com/docs/en/workflows) — never from memory. when a new reusable template shape proves out across two+ runs, add it above with its one-line pattern signature.