dynamic-workflow

Dynamic Workflows

Overview

Claude Code can now spawn 10-100 subagents in parallel, each working on a piece of a complex task, with verification before synthesis. This skill teaches you when and how to use this effectively.

When to Use (vs Single Agent)

Task Type	Use Dynamic Workflow?	Why
Simple code fix	NO	One agent is enough. Overhead not worth it.
Research with multiple sources	YES	Fan out searches, verify in parallel, synthesize
Code review across large PR	YES	Each agent reviews one file/component
Architecture comparison	YES	Each agent deeply analyzes one option
Content generation with fact-checking	YES	Generate + verify adversarially in parallel
Debugging intermittent issue	MAYBE	Fan out hypotheses, each agent tests one

Rule of thumb: If you'd naturally say "I need to look at this from 5 different angles" — use a workflow. If it's sequential (step A must finish before B starts) — don't.

Process

Follow this pattern for every dynamic workflow:

The Pattern

1. DECOMPOSE — break the task into independent parallel pieces
2. FAN OUT — spawn one subagent per piece (10-100)
3. EXECUTE — each agent works independently with its own context
4. VERIFY — adversarial checking of results (catch hallucinations)
5. SYNTHESIZE — combine verified results into final output

Designing Good Workflows

Fan-Out Rules

Each parallel piece must be:

• Independent — doesn't need results from another piece
• Bounded — clear scope, defined deliverable
• Verifiable — output can be checked against source material

GOOD fan-out: "Research X from 5 different source types"
  → Agent 1: academic papers on X
  → Agent 2: industry blog posts on X
  → Agent 3: GitHub implementations of X
  → Agent 4: community discussions about X
  → Agent 5: competitor products using X

BAD fan-out: "Build the auth system"
  → Why bad? Steps are sequential (design → implement → test), not parallel