Menü
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | dispatching-parallel-agents |
| description | Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies |
You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
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.
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:
Don't use when:
Group failures by what's broken:
Each domain is independent - fixing tool approval doesn't affect abort tests.
Each agent gets:
// 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
When agents return:
Good agent prompts are:
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.
❌ 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 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)
Scenario: 6 test failures across 3 files after major refactoring
Failures:
Decision: Independent domains - abort logic separate from batch completion separate from race conditions
Dispatch:
Agent 1 → Fix agent-tool-abort.test.ts
Agent 2 → Fix batch-completion-behavior.test.ts
Agent 3 → Fix tool-approval-race-conditions.test.ts
Results:
Integration: All fixes independent, no conflicts, full suite green
Time saved: 3 problems solved in parallel vs sequentially
After agents return:
From debugging session (2025-10-03):
The cascade method is a structured three-phase approach for parallel investigation where the goal is a single coherent output assembled from multiple independent explorations.
Dispatch N agents with independent, focused scopes. Each agent gets a clear, narrow question or investigation area. The key constraint: agents must not need each other's results to do their work.
Design each agent's prompt to:
Gather results from all agents. As results come in, actively note:
Merge results into a single coherent output. Resolve conflicts by:
Scenario: Users report intermittent 500 errors on checkout. The checkout flow touches three subsystems: payment processing, inventory reservation, and order creation.
Fan-Out:
Agent 1 → "Investigate payment processing for sources of 500 errors during
checkout. Check error logs, exception handlers, and external API
call timeouts. Return: error patterns found, frequency, and
suspected root causes."
Agent 2 → "Investigate inventory reservation for sources of 500 errors during
checkout. Check for race conditions in stock decrement, deadlocks,
and failed rollbacks. Return: error patterns found, frequency, and
suspected root causes."
Agent 3 → "Investigate order creation for sources of 500 errors during
checkout. Check for validation failures, database constraint
violations, and transaction isolation issues. Return: error patterns
found, frequency, and suspected root causes."
Collect:
inventory_locks table under concurrent writes, causing ~35% of 500sSynthesize:
| Signal | Approach | Why |
|---|---|---|
| Tasks share no files or state | Parallelize | No merge conflicts, no coordination needed |
| Tasks read same files but don't write | Parallelize | Read-only access is safe to share |
| Tasks write to same files | Sequential | Concurrent writes cause conflicts |
| Task B depends on Task A's output | Sequential | Data dependency requires ordering |
| Exploration/research with independent scopes | Parallelize | Investigation is inherently parallelizable |
| Fewer than 3 tasks | Usually sequential | Dispatch overhead exceeds time savings |
| Tasks require different expertise domains | Parallelize | Specialized agents perform better in isolation |
| Tasks share complex state (database, external API) | Sequential | Shared mutable state is dangerous |
Use when executing implementation plans with independent tasks in the current session
Formal evaluation framework for Claude Code sessions implementing eval-driven development (EDD) principles
Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code.
Use when context is growing large, responses are slow, or you need to optimize token budget across system prompt, background processes, and model selection
A comprehensive verification system for Claude Code sessions.
Use when implementing any feature or bugfix, before writing implementation code