dispatching-parallel-agentslisted

# Dispatching Parallel Agents Use parallel subagents only for truly independent work. ## Decision Check Use parallel dispatch when all are true: - Problems have separate root causes. - Tasks do not edit the same files. - Tasks do not require shared intermediate state. If any condition fails, run sequentially. **Do not use when:** - Failures are related — fixing one might fix others. - The task is exploratory — you don't know what's broken yet. - Agents would edit the same files or shared resources. - Understanding the problem requires seeing the full system state. - The task is content relay — fetching raw content (file contents, web pages, API responses) to bring back to the parent session. Agent results are compressed; raw content will be lost. Fetch it directly instead with Read (local files) or `curl` (URLs). ## Procedure 1. Split work into independent domains. 2. Write one focused prompt per domain. 3. Dispatch all agents in a **single message** with multiple parallel Agent tool calls. Do not dispatch sequentially across multiple messages — staggered dispatch delays start times, burns cache TTL, and undermines the parallelism. 4. Collect summaries and changed files. 5. Resolve conflicts between summaries and changed files. 6. Run integration verification: execute the full project test suite plus any cross-domain checks. Do not mark the wave complete until integration passes. ## Context Isolation Never forward parent session context or history to subagents. Const