// Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
| name | dispatching-parallel-agents |
| description | Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies |
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.
Use when:
Don't use when:
Group failures by what's broken:
Each domain is independent - fixing X doesn't affect Z tests.
Each agent gets:
Using runSubagent tool:
runSubagent(
prompt: "Fix the failing tests in src/components/ComponentA.test.ts...",
description: "Fix ComponentA tests"
)
runSubagent(
prompt: "Fix the failing tests in src/hooks/useHookB.test.ts...",
description: "Fix useHookB tests"
)
runSubagent(
prompt: "Fix the failing tests in src/services/ServiceC.test.ts...",
description: "Fix ServiceC tests"
)
// All three run concurrently
When agents return:
Good agent prompts are:
Fix the 3 failing tests in src/components/ImageUploader.test.tsx:
1. "should handle file upload correctly" - expects onUpload to be called
2. "should validate file type" - jpeg not accepted
3. "should show error for large files" - no error displayed
These are likely state management or event handling issues. Your task:
1. Read the test file and understand what each test verifies
2. Identify root cause - component bug or test setup issue?
3. Fix by:
- Fixing component bugs if found
- Adjusting test expectations if testing changed behavior
- Use systematic-debugging skill
Do NOT just add timeouts - find the real issue.
Return: Summary of what you found and what you fixed.
❌ Too broad: "Fix all the tests" - agent gets lost ✅ Specific: "Fix ImageUploader.test.tsx" - 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 change production code" or "Fix tests only"
❌ Vague output: "Fix it" - you don't know what changed ✅ Specific: "Return summary of root cause and changes"
Related failures: Fixing one might fix others - investigate together first Need full context: Understanding requires seeing entire system Exploratory debugging: You don't know what's broken yet Shared state: Agents would interfere (editing same files, using same resources)
After agents return:
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when you have a written implementation plan to execute with review checkpoints
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when executing implementation plans with independent tasks in the current session