| name | parallel-dispatch-decomposition |
| description | Decomposes broad tasks into MECE, parallelizable sub-tasks with explicit scope cards. Core skill for intra-domain parallel dispatch. Produces scope cards consumed by parallel-dispatch-dag, parallel-dispatch-ownership, and parallel-dispatch-merge skills. |
Parallel Dispatch: Task Decomposition
Break a broad task into parallelizable, MECE sub-tasks. Each sub-task gets a scope card that defines its boundaries, deliverables, and dependencies.
When to Invoke
- Before dispatching multiple instances of the same agent type within a primitive
- When a single agent's workload spans multiple independent feature slices
- When the orchestrator identifies >1 natural cluster of work within a domain
Decomposition Strategies by Phase
| Phase | Decomposition Axis | Example Scopes |
|---|
| SCOUT | Investigation area (feature, subsystem, technology) | [auth], [tasks], [notifications] |
| DESIGN | Architectural concern (contracts, data model, boundaries) | [api-contracts], [data-model], [component-boundaries] |
| PRE-MORTEM | Risk domain (failure modes, blast radius, recovery) | [failure-modes], [blast-radius], [recovery-paths], [threat-model] |
| BUILD | Feature slice (vertical feature boundaries) | [auth], [tasks], [lists] |
| TEST | Test suite domain (E2E suite, contract suite) | [auth-e2e], [task-e2e], [api-contract] |
| REVIEW | Review dimension or feature scope | [auth-review], [security-dim], [test-coverage] |
| REMEDIATE | Mirrors BUILD decomposition (fix what you built) | Same scopes as BUILD findings |
| OPTIMIZE | Performance domain (CPU, memory, I/O, queries) | [query-opt], [cache], [concurrency] |
| REFACTOR | Module boundary or code smell cluster | [user-module], [task-module] |
Decomposition Protocol
Step 1: Inventory
List all concrete deliverables for this primitive. Be specific: files, modules, endpoints, tests.
Step 2: Cluster
Group deliverables by natural boundaries. Prefer feature-based clustering over technical-layer clustering.
Correct (feature-based):
Cluster: auth → handler, service, repository, middleware, tests
Cluster: tasks → handler, service, repository, tests
Wrong (layer-based):
Cluster: handlers → auth handler, task handler, list handler
Cluster: services → auth service, task service, list service
Feature-based clustering produces naturally independent sub-tasks. Layer-based creates cross-cutting dependencies.
Step 3: MECE Validate
- Mutually Exclusive: No file appears in two clusters. Check by listing all files per cluster and verifying zero intersection.
- Collectively Exhaustive: Union of all clusters equals total scope. No deliverable left unassigned.
If either check fails → re-cluster.
Step 4: Dependency Scan
For each cluster, identify:
- Inputs: What must exist before this sub-task can start? (API contracts, types, schemas)
- Outputs: What does this sub-task produce that others consume?
- Shared reads: Files this sub-task reads but does not modify (types, interfaces, configs)
Mark dependencies as:
hard → cannot start without this input (blocks parallel execution)soft → benefits from this input but can proceed with assumptions (parallelizable)
Step 5: Scope Card
Produce one scope card per sub-task:
### Scope Card: @<agent-type>[<scope>]
- **Deliverables**: <list of concrete outputs>
- **File Allowlist**: <glob pattern for exclusive write access>
- **Shared Reads**: <glob patterns for read-only access>
- **Hard Dependencies**: <scope cards that must complete first>
- **Soft Dependencies**: <scope cards that are beneficial but not blocking>
- **Blocked By**: <list of scope card names>
- **Blocks**: <list of downstream scope card names>
Step 6: Parallelism Cap Check
Count sub-tasks per agent type. If >5 instances of the same agent type:
- Warn the user: "Decomposition produced N instances of @. This exceeds the soft cap of 5."
- Present options:
- Continue with N instances (maximum parallelism)
- Cap at 5 (merge smallest clusters)
- Cap at custom number
- Wait for user decision before proceeding.
Scope Card Rules
- Every scope card MUST have at least one concrete deliverable
- Every scope card MUST have a file allowlist (even if broad)
- File allowlists between write-agents MUST be disjoint (enforced by parallel-dispatch-ownership)
- Scope names use kebab-case:
[auth], [task-crud], [user-profile]
- Scope cards for read-only agents define read scope, not write scope
- Empty scope cards are invalid → merge with adjacent cluster
Anti-Patterns
| Anti-Pattern | Why It Fails | Fix |
|---|
| Layer-based decomposition | Creates cross-cutting deps, every sub-task touches every feature | Use feature-based clustering |
| Shared write access | Two agents editing same file → merge conflicts guaranteed | One writer per file, extract shared code to contract layer |
| Scope too small (<1 file) | Overhead exceeds benefit, context fragmentation | Merge into adjacent cluster |
| Scope too broad (entire domain) | No parallelism gained, single bottleneck | Break into feature slices |
| Missing MECE validation | Gaps → missed deliverables, overlaps → conflicts | Always run Step 3 |
| Decomposing without design output | No contracts → agents make incompatible assumptions | DESIGN before BUILD decomposition |
Read-Only Agent Decomposition
Read-only agents (scout, qa-analyst, security-engineer, ux-reviewer, incident-responder) use MECE scoping for coverage guarantees, not conflict prevention:
- Each instance covers a disjoint area of the codebase or investigation space
- Union of all instances covers 100% of the relevant scope
- If deeper perspective is needed on a specific topic, add another parallel agent for that topic specifically
Integration Sub-Task Pattern
Some files inherently aggregate contributions from multiple features (routers, registries, main entry points, config files). Handle with a dedicated integration sub-task:
### Scope Card: @<agent-type>[integration]
- **Deliverables**: Wire all feature modules into application entry point
- **File Allowlist**: <aggregation files only>
- **Hard Dependencies**: All parallel sub-tasks for this agent type
- **Blocks**: REVIEW phase
Integration sub-tasks always run after all parallel sub-tasks complete. They merge last.
Related Skills
- parallel-dispatch-dag — consumes scope cards, builds execution DAG
- parallel-dispatch-ownership — validates MECE file boundaries from scope cards
- parallel-dispatch-merge — merges completed worktree branches
- research-methodology — topic decomposition for SCOUT phase
