parallel-planner

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).