with one click
dispatching-parallel-agents
Use multiple Claude agents to investigate and fix independent problems concurrently
Menu
Use multiple Claude agents to investigate and fix independent problems concurrently
Standard for authoring product PRDs in docs/prd/: state the problem, users, requirements, and success; assign PRD-{AREA}-{NN} IDs; link down to specs.
Standard for authoring engineering behavior-contract specs in docs/specs/: scope subsystems, assign stable IDs, structure docs, manage lifecycle.
Complete circuit breaker enforcement patterns with examples and remediation
Pause session and save current work state for later resume
Load context from paused session
Pause session and save current work state for later resume
| name | Dispatching Parallel Agents |
| description | Use multiple Claude agents to investigate and fix independent problems concurrently |
| when_to_use | when facing 3+ independent failures that can be investigated without shared state or dependencies |
| version | 2.0.0 |
| progressive_disclosure | {"entry_point":{"summary":"Dispatch one agent per independent problem domain to solve multiple unrelated failures concurrently","when_to_use":"When you have 3+ independent failures in different test files/subsystems with no shared state or dependencies","quick_start":"1. Identify independent domains 2. Create focused agent tasks 3. Dispatch in parallel 4. Review summaries 5. Verify no conflicts and integrate"},"references":["coordination-patterns.md","agent-prompts.md","examples.md","troubleshooting.md"]} |
| effort | medium |
SCOPE: ORCHESTRATOR / PM-LEVEL ONLY (#581). This skill describes the top-level orchestrator (PM) capability to spawn parallel agents via the
Agent/Tasktool. Subagents do not have access to the Agent tool and cannot spawn sub-subagents — agent-spawning is harness-enforced at the top level. If you are a subagent (engineer, qa, research, etc.), this skill does not apply to you: complete your assigned scope and return results to the PM. (This skill is intentionally not deployed to subagents; seeconfig/skill_to_agent_mapping.yaml.)
When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
Core principle: Dispatch one agent per independent problem domain. Let them work concurrently.
Activate this skill when you're facing:
Don't use when:
One agent, one problem domain, one clear outcome.
Never overlap scopes. Never share state. Always integrate consciously.
Problems must be truly independent - no shared files, no related root causes, no dependencies between fixes.
Each agent gets narrow scope: one test file, one subsystem, one clear goal. Broad tasks lead to confusion.
Every agent must return a summary: what was found, what was fixed, what changed. No silent fixes.
Don't blindly merge agent work. Review summaries, check conflicts, run full suite, verify compatibility.
Group failures by what's broken:
File A tests: Tool approval flow
File B tests: Batch completion behavior
File C tests: Abort functionality
Each domain is independent - fixing tool approval doesn't affect abort tests.
Each agent gets:
→ agent-prompts.md for prompt templates and examples
// In Claude Code / AI environment
Task("Fix agent-tool-abort.test.ts failures")
Task("Fix batch-completion-behavior.test.ts failures")
Task("Fix tool-approval-race-conditions.test.ts failures")
// All three run concurrently
→ coordination-patterns.md for dispatch strategies
When agents return:
→ troubleshooting.md for conflict resolution
Multiple failures?
└→ Are they independent?
├→ NO (related) → Single agent investigates all
└→ YES → Can they work in parallel?
├→ NO (shared state) → Sequential agents
└→ YES → Parallel dispatch ✓
STOP immediately if:
When in doubt: Start with one agent, understand the landscape, then dispatch if truly independent.
Prerequisite: Basic understanding of problem domains and test structure Complementary: pm-workflow for coordinating multiple agents Domain-specific: Testing skills for understanding test failures
From debugging session (2025-10-03):
→ examples.md for detailed case study