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
2026-05-05 — Classifying 160 skill .md files into 3 buckets
Dispatched a single Explore agent to read each ## Receipts section across 160 skill files (grep for the heading, then read the next 30–50 lines) and classify into firsthand / TODO / generic. Wall time ~3 minutes; the agent burned ~70K tokens against an estimated ~150K if the read had stayed in main context.
Bucket counts came back as expected on the import waves: TODO=18 (matched exactly — 4 Osmani + 8 personas + 5 obra + 1 ppt-master), generic=137, firsthand=5. The TODO and total counts were greppable and held up under follow-up verification. The firsthand=5 claim didn’t — a verification grep for the agent’s marker phrase (“Pattern that works:”) returned 142 files, meaning the agent’s classifier was effectively “specificity in surrounding context,” not phrase-presence.
Lesson: parallel dispatch protects context but inherits whatever rubric the prompt encodes. Numeric tallies (count files matching pattern X) work well — the rubric is grep. Semantic classifications need explicit evidence requirements in the brief (must cite a date, must reference a receipts-drafts/<slug>.md, must name a commit) or the agent fills the gap with judgment that won’t survive verification.
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.