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

parallel-planner