vibe-parallel-task-decomposition
npx machina-cli add skill ash1794/vibe-engineering/parallel-task-decomposition --openclawvibe-parallel-task-decomposition
Large tasks are often collections of independent subtasks hiding behind a sequential mental model. Find the parallelism.
When to Use This Skill
- Facing a task with 5+ subtasks
- Multiple files need changes that don't depend on each other
- Implementation plan has steps that could run concurrently
- User asks to "speed this up" or "parallelize"
When NOT to Use This Skill
- Tasks with fewer than 3 subtasks
- All subtasks depend on each other sequentially
- Changes are all in the same file
- The overhead of coordination exceeds the benefit
Steps
-
List all subtasks from the plan or requirements
-
Build dependency graph — For each pair of tasks, ask:
- Do they modify the same file? → dependent
- Does task B need output from task A? → dependent
- Do they share mutable state? → dependent
- Otherwise → independent (can parallelize)
-
Group into batches:
- Batch 0: Tasks with no dependencies (run first, in parallel)
- Batch 1: Tasks that depend only on Batch 0 (run after Batch 0, in parallel)
- Batch N: Continue until all tasks assigned
-
Set parallelism limit — Max 4-6 concurrent agents (beyond this, coordination overhead dominates)
-
Create dispatch plan:
Output Format
Parallel Task Decomposition
Total Tasks: X Batches: Y Max Parallelism: Z agents Estimated Speedup: ~Nx vs sequential
Dependency Graph
Task A ──→ Task D
Task B ──→ Task D
Task C (independent)
Task D ──→ Task F
Task E (independent)
Dispatch Plan
| Batch | Tasks | Parallelism | Dependencies |
|---|---|---|---|
| 0 | A, B, C, E | 4 | None |
| 1 | D | 1 | A, B |
| 2 | F | 1 | D |
Per-Task Assignments
- Task A: [files], [description], [acceptance test]
- Task B: [files], [description], [acceptance test]
Integration Order
After all batches complete, integrate in order: [A, B, C, E] → D → F
Source
git clone https://github.com/ash1794/vibe-engineering/blob/master/skills/parallel-task-decomposition/SKILL.mdView on GitHub Overview
Vibe parallel-task-decomposition identifies independent subtasks within a larger task and organizes them into a DAG-based dispatch plan. By revealing parallelism and dependencies, teams can safely run tasks concurrently, reducing total delivery time.
How This Skill Works
Start by listing all subtasks, then build a dependency graph by analyzing which subtasks touch the same files, rely on each other's outputs, or share mutable state. Group independent tasks into batches (Batch 0 has no dependencies; Batch 1 depends only on Batch 0; continue until complete) and cap parallelism at 4–6 concurrent agents to minimize coordination overhead. The result is a concrete dispatch plan and a clear path to maximum parallelism.
When to Use It
- Facing a task with 5+ subtasks.
- Multiple files require changes that don't depend on one another.
- Implementation steps could be executed concurrently.
- You want to speed this up or explicitly parallelize.
- You need a DAG-based plan to maximize resource utilization across tasks.
Quick Start
- Step 1: List all subtasks from the requirements or plan.
- Step 2: Build a dependency graph by evaluating file touches, outputs, and shared state.
- Step 3: Group tasks into batches, apply a 4–6 agent parallelism limit, and generate the dispatch plan.
Best Practices
- List every subtask before analyzing dependencies.
- Verify independence by checking file touches, outputs, and mutable state across subtasks.
- Limit parallelism to 4–6 to balance speed and coordination costs.
- Explicitly encode dependencies and expected outputs to prevent race conditions.
- Validate the plan with a small pilot run and adjust as needed.
Example Use Cases
- Orchestrating a multi-module build where edits touch different modules; batch 0 runs A, B, C, E in parallel and Batch 1 runs D after A and B, followed by F.
- ETL pipelines where transforms operate on separate datasets, enabling parallel execution of independent transforms.
- Frontend refactors across components with no shared mutable state, allowing parallel updates.
- CI/CD pipelines with independent deployment steps that can run concurrently to different environments.
- Documentation updates across files that don’t cross-reference, enabling parallel edits to speed up release notes and guides.
