# dispatching-parallel-agents

> A Claude Code skill that decides when to fan out work across parallel subagents — triggers on 3+ independent failures or tasks with no shared state, dispatches one agent per problem domain, then reconciles their outputs.

**Use case**: Fan out independent work across parallel subagents instead of working serially

**Canonical URL**: https://agentcookbooks.com/skills/dispatching-parallel-agents/

**Topics**: claude-code, skills, subagents, planning

**Trigger phrases**: "these are independent", "parallelize this", "dispatch agents in parallel"

**Source**: [Jesse Vincent](https://github.com/obra/superpowers/tree/main/skills/dispatching-parallel-agents)

**License**: MIT

---

## What it does

`dispatching-parallel-agents` decides when fanning work out across multiple subagents is faster than doing it serially, and orchestrates the dispatch when it is. The trigger is concrete: 2+ tasks (the skill's own threshold) that share no state and have no sequential dependency between them. The skill scopes each subagent to one problem domain, runs them in parallel, then reconciles the outputs into a single integration step.

The point is to fight the default of working sequentially when you don't have to. Five broken tests in five unrelated files isn't five problems in series; it's five problems in parallel that should land in the time of the slowest one.

## When to use it

- Multiple test failures across unrelated files — investigate them in parallel, not one by one
- Refactors where each module's changes are independent (e.g., updating five callers of a deprecated function)
- Audits across multiple subsystems — one agent per subsystem
- Any "do X to all of Y" where the Xs don't share state
- Pairing with `using-git-worktrees` so each agent has its own isolated checkout

When *not* to reach for it:

- Two tasks where one's output is the other's input — that's serial, not parallel
- Anything touching shared state, shared files, or shared types — merge conflicts will eat the time savings
- Tiny tasks where dispatch overhead exceeds the work
- Investigations where the agents need to talk to each other mid-flight

## Install

From the [obra/superpowers](https://github.com/obra/superpowers) repo at `skills/dispatching-parallel-agents/`. Composes with `subagent-driven-development` (which handles the per-agent execution discipline) and `using-git-worktrees` (which gives each agent isolated state).

## What a session looks like

1. **Identify candidate tasks** — list everything that needs doing.
2. **Check independence** — for each pair, ask: does either depend on the other's output? Do they touch the same files? Do they share types? If yes to any, they're not independent.
3. **Dispatch one agent per independent task** — each gets a scoped brief, the relevant files, and a clear deliverable.
4. **Wait for all agents to return** — don't merge partials. The reconciliation step needs the full set.
5. **Review for conflicts** — even "independent" tasks sometimes touch shared infrastructure (a shared util, a shared type). Catch this before integration.
6. **Integrate** — apply the agent outputs in an order that lets the test suite pass after each.

The discipline that makes it work: step 2. Mistaking a serial dependency for an independent one is the failure mode that turns parallel dispatch into a merge-conflict bonfire.

## Receipts

_TODO — to be filled in from a real parallel-dispatch session. Once the skill has been used to fan out 3+ tasks across subagents, this section will capture: number of agents dispatched, wall-clock vs. serial estimate, how many "independent" tasks turned out to share state, and how the reconciliation step handled conflicts._

## Source and attribution

From [Jesse Vincent's superpowers repository](https://github.com/obra/superpowers/tree/main/skills/dispatching-parallel-agents).

License: MIT.

The skill is part of a broader subagent methodology — `dispatching-parallel-agents` decides *whether* to fan out, `subagent-driven-development` describes *how* to brief and review each subagent's work, and `using-git-worktrees` gives them somewhere isolated to do it.