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.
Fan out independent work across parallel subagents instead of working serially
Trigger phrases
Phrases that activate this skill when typed to Claude Code:
these are independentparallelize thisdispatch agents in parallel
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-worktreesso 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 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
- Identify candidate tasks — list everything that needs doing.
- 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.
- Dispatch one agent per independent task — each gets a scoped brief, the relevant files, and a clear deliverable.
- Wait for all agents to return — don’t merge partials. The reconciliation step needs the full set.
- Review for conflicts — even “independent” tasks sometimes touch shared infrastructure (a shared util, a shared type). Catch this before integration.
- 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.
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.