
Dispatching Parallel Agents
Spin up one concurrent agent per independent failure domain so unrelated test or subsystem bugs get fixed in parallel instead of serial triage.
Overview
Dispatching Parallel Agents is an agent skill most often used in Ship (also Operate, Build) that assigns one concurrent agent per independent failure domain so unrelated bugs and test failures are investigated in paralle
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill dispatching-parallel-agentsWhat is this skill?
- Decision flow for when failures are independent versus related shared-state problems
- One agent per problem domain with explicit parallel versus sequential dispatch
- Targets 3+ test files or multiple broken subsystems without cross-context coupling
- Core principle: do not serialize investigations that do not need each other's state
- Works with any agent runtime that supports multiple concurrent sessions
Adoption & trust: 473 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have several unrelated red tests or subsystem failures and one agent chewing through them one-by-one burns time you do not have before ship.
Who is it for?
Pre-release test suites with multiple unrelated failures, or post-deploy when several services broke for different reasons and you can isolate work per domain.
Skip if: A single root cause affecting many tests, failures that require sequential shared-state fixes, or one-file bugs where parallel agents add coordination overhead.
When should I use this skill?
Facing 2+ independent tasks that can be worked on without shared state or sequential dependencies.
What do I get? / Deliverables
After routing, each independent problem has a dedicated agent investigation running concurrently, shortening time-to-green without mixing unrelated contexts in one thread.
- Parallel investigation plans per domain
- Isolated fix proposals or patches per agent branch
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill is written around multiple failing tests and pre-release debugging, where parallel investigation saves the most calendar time. Testing is the primary trigger in the SKILL.md (3+ test files, different root causes), which maps directly to automated test failure triage before release.
Where it fits
CI reports five failing specs across auth, billing, and UI with unrelated stack traces—dispatch three agents instead of one serial thread.
Production alerts from two services with no shared dependency—parallel agents investigate logs per service.
Local integration tests fail in API and worker packages independently—split agents by package boundary.
PR checks show lint and unrelated unit failures—one agent on style, one on logic without blocking each other.
How it compares
Use instead of a single mega-debug session when failures are provably independent—not as a replacement for systematic root-cause analysis on one linked incident.
Common Questions / FAQ
Who is dispatching-parallel-agents for?
Solo and indie builders running agentic coding workflows who routinely hit multiple independent failures during test runs or integration checks.
When should I use dispatching-parallel-agents?
Use during Ship when 3+ test files fail for different reasons, during Operate when several subsystems need isolated triage, or during Build when parallel integration bugs do not share state—never when one fix unblocks everything.
Is dispatching-parallel-agents safe to install?
It is community-sourced prompt guidance with no bundled executables; review the Security Audits panel on this Prism page before trusting the source repo.
SKILL.md
READMESKILL.md - Dispatching Parallel Agents
# Dispatching Parallel Agents ## Overview 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. ## When to Use ```dot digraph when_to_use { "Multiple failures?" [shape=diamond]; "Are they independent?" [shape=diamond]; "Single agent investigates all" [shape=box]; "One agent per problem domain" [shape=box]; "Can they work in parallel?" [shape=diamond]; "Sequential agents" [shape=box]; "Parallel dispatch" [shape=box]; "Multiple failures?" -> "Are they independent?" [label="yes"]; "Are they independent?" -> "Single agent investigates all" [label="no - related"]; "Are they independent?" -> "Can they work in parallel?" [label="yes"]; "Can they work in parallel?" -> "Parallel dispatch" [label="yes"]; "Can they work in parallel?" -> "Sequential agents" [label="no - shared state"]; } ``` **Use when:** - 3+ test files failing with different root causes - Multiple subsystems broken independently - Each problem can be understood without context from others - No shared state between investigations **Don't use when:** - Failures are related (fix one might fix others) - Need to understand full system state - Agents would interfere with each other ## The Pattern ### 1. Identify Independent Domains 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. ### 2. Create Focused Agent Tasks Each agent gets: - **Specific scope:** One test file or subsystem - **Clear goal:** Make these tests pass - **Constraints:** Don't change other code - **Expected output:** Summary of what you found and fixed ### 3. Dispatch in Parallel ```typescript // 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 ``` ### 4. Review and Integrate When agents return: - Read each summary - Verify fixes don't conflict - Run full test suite - Integrate all changes ## Agent Prompt Structure Good agent prompts are: 1. **Focused** - One clear problem domain 2. **Self-contained** - All context needed to understand the problem 3. **Specific about output** - What should the agent return? ```markdown Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts: 1. "should abort tool with partial output capture" - expects 'interrupted at' in message 2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed 3. "should properly track pendingToolCount" - expects 3 results but gets 0 These are timing/race condition issues. Your task: 1. Read the test file and understand what each test verifies 2. Identify root cause - timing issues or actual bugs? 3. Fix by: - Replacing arbitrary timeouts with event-based waiting - Fixing bugs in abort implementation if found - Adjusting test expectations if testing changed behavior Do NOT just increase timeouts - find the real issue. Return: Summary of what you found and what you fixed. ``` ## Common Mistakes **❌ Too broad:** "Fix all the tests" - agent gets lost **✅ Specific:** "Fix agent-tool-abort.test.ts" - focused scope **❌ No context:** "Fix the race condition" - agent doesn't know where **✅ Context:** Paste the error messages and test names **❌ No constraints:** Agent might refactor everything **✅ Constraints:** "Do NOT chan