Dispatching Parallel Agents (obra/superpowers)
## what it does
tl;dr: this is the parallelism skill from obra/superpowers. Core rule: one agent per independent problem domain, all dispatches in the same response so they run concurrently. Use it when you have multiple unrelated failures — different test files, different subsystems — and serial investigation would burn context for nothing.
What it actually does
The SKILL.md (fetched 2026-09-10) walks through four steps:
- Identify independent domains. Group failures by what’s broken: “file A tests = tool approval”, “file B tests = batch completion”. If fixing one might fix the others, they’re not independent and the skill doesn’t apply.
- Create focused agent tasks. Each agent gets a specific scope, a clear goal, constraints (don’t touch other code), and a defined output (a summary of what changed).
- Dispatch in parallel. Multiple subagent calls in one response = parallel execution. One per response = sequential. The README’s worked example is six test failures across three files after a refactor — three agents, three fix summaries, then a full-suite re-run.
- Review and integrate. Read each summary. Check for conflicts. Re-run the full suite. Spot-check — agents make systematic errors.
The “agent prompt structure” section is the load-bearing part: focused, self-contained, specific about output. A bad prompt (“fix all the tests”) gets the agent lost; a good prompt pastes the failing test names, the error messages, and the constraint (“do not change production code”).
When to use, when not to
The skill ships a decision diagram and a checklist:
| Use when | Don’t use when |
|---|---|
| 3+ test files failing with different root causes | Failures are related (fix one might fix others) |
| Multiple subsystems broken independently | Need to understand full state across all of them |
| Each problem can be understood without context from others | Agents would interfere (same files, same resource) |
| No shared state between investigations | It’s exploratory debugging — you don’t know what’s broken yet |
The “exploratory debugging” row is the most-missed one. If you don’t yet know whether the failures are independent, investigate together before dispatching.
When it fires
Frontmatter description: “Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies.” Hosts that load skills metadata (Claude Code, Cursor via plugins) pick this up automatically. On Claude Code, the same using-superpowers bootstrap that injects brainstorming triggers dispatching on independent-failure patterns.
Install
# Claude Code — official Anthropic marketplace
/plugin install superpowers@claude-plugins-official
# Claude Code — Superpowers marketplace (alternative)
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplaceThe README documents eight other install surfaces (Antigravity, Codex App, Codex CLI, Cursor, Devin CLI, Factory Droid, Gemini CLI, GitHub Copilot CLI, Grok Build CLI, Kimi Code, OpenCode, Pi, Hermes Agent). None of them is npx skills add obra/superpowers — that is the skills.sh command for a different ecosystem. Do not invent that name.
To load just this SKILL.md without the rest of the methodology, clone the repo and copy skills/dispatching-parallel-agents/SKILL.md into the host’s skills directory.
Gotchas
- Independent ≠ unrelated. The skill is explicit: “Fixing one might fix others — investigate together first.” The decision diagram treats dependency as a hard off-switch.
- Subagents do NOT inherit your session context. Each prompt must include everything the agent needs to do the work. The skill’s worked example pastes failing test names and error messages directly into the prompt.
- One response = parallel; one per response = sequential. This is the only place the skill is dogmatic about the mechanics. If you want concurrency, you have to batch the dispatches.
- Output contract matters. “Fix it” returns nothing useful. The skill’s template forces “Return: Summary of root cause and changes” so the orchestrator can integrate without re-reading the diff.
- Don’t replace arbitrary timeouts in failing tests with bigger timeouts. The worked example calls this out: agents will reach for sleep(1000) → sleep(5000) → sleep(10000) instead of finding the actual race. Tell the agent in the prompt.
- Review each summary. Agents make systematic errors — same wrong assumption applied to every domain. Spot-check before declaring the suite green.
- Cursor is partial, not full. Cursor’s subagent support is real but the host metadata model is thinner than Claude Code’s; triggers may not fire as reliably. Test before relying on it for a fire-drill.
sandbox_testis untested — we read the file, we did not run a parallel-dispatch drill in the sandbox. Perconfig/skill-safety.md, this staysuntesteduntil a human runs the eval-vs-prompt harness.
Related
- Brainstorming (obra/superpowers) — same superpowers shelf, the upstream step (design must precede the dispatch on the architectural path)
- Anthropic Bash (not a standalone skill) — same shelf, the substrate that most “parallel agent” fixes end up touching
- frontend-design (Anthropic, UI Skills) — both are task-routing skills that hand work to specialized agents
## compatibility
## embed this badge
