| name | parallel-planner |
| description | Analyze multi-step tasks to identify which steps can run in parallel, build dependency graphs, detect conflicts (write-write, read-write, resource contention), and produce optimized execution plans. Triggers on 3+ independent steps, 'speed up', 'run simultaneously', 'parallelize', 'optimize' or any task where sequential execution wastes time. |
Parallel Planner Protocol
Analyze task steps — which ones must wait for each other, which ones can run simultaneously? Build a dependency graph, form parallel groups, and prevent conflicts.
Core principle: Sequential is safe but slow. Parallel is fast but requires care. Making the right distinction is this skill's job.
Parallelization Criteria
A step can run in parallel only if all conditions are met:
- Not dependent on another step's output
- Does not write to a resource another step reads (no write conflict)
- Does not modify shared state (global variable, same file)
- If it fails, it does not block other parallel steps
A step must run sequentially if any of these apply:
- Its input is another step's output
- It writes to the same file / DB table / API resource
- Order matters for correctness (e.g., schema before data)
- Must be atomic (inside a transaction)
Parallelizable Work Types
| Type | Parallel When | Sequential When |
|---|
| Web search | Different topics/sources | Result of search A needed for search B |
| Code generation | Writing to different files | File B imports from file A |
| API calls | Reading from same or different resources | Auth token needed first |
| Data processing | Different data slices | Normalization before analysis |
| Independent subtasks | No shared output/resource | Test depends on module |
Conflict Detection
After identifying parallel candidates, check for conflicts:
Write-Write Conflict
Two steps write to the same resource → cannot be parallel.
Solution: Run sequentially OR write to separate files, then merge.
Read-Write Conflict
One step reads while another writes to the same resource → cannot be parallel.
Solution: Read first, then write (sequential).
Resource Contention
Shared rate limits or connection pools → limit parallel count.
Solution: Cap at 3 parallel, run in batches.
Output Format
PARALLEL PLANNER
Total steps: N | Parallel groups: N | Sequential steps: N
Estimated speedup: ~X% faster
## Dependency Graph
[mermaid or text visualization]
## Execution Plan
### Group 1 — Parallel (N steps)
- [ ] #A: [step]
- [ ] #B: [step]
- [ ] #C: [step]
-> All complete, then proceed to Group 2
### Group 2 — Sequential
- [ ] #D: [step] (requires: #A, #B)
- [ ] #E: [step] (requires: #D)
## Conflict Warnings
[If any — blocked parallel candidates and reason]
## Steps Kept Sequential
| Step | Reason | Depends On |
|------|--------|------------|
| #D | Uses #A output | #A |
Speed Estimate
Sequential total = Sum(all step durations)
Parallel total = Sum(longest step per group)
Speedup = (Sequential - Parallel) / Sequential * 100
Complexity-based estimates when duration is unknown:
- Simple (file read, short code): ~1 unit
- Medium (API call, analysis): ~3 units
- Heavy (web research, large code): ~5 units
When to Skip
- 2 or fewer steps — parallelization is meaningless
- All steps are sequentially dependent
- User said "do it step by step"
- Transaction-bound operations (must be atomic)
Guardrails
- Never parallelize write operations to the same resource — even if it seems safe.
- Always show the dependency graph — the user must see why steps are ordered this way.
- Cross-skill: works with
task-decomposer (provides the step list) and tool-selector (optimizes tool usage within groups).
