Execute a written plan across parallel workstreams

Genuine independence, derived from the dependency graph rather than assumed, decides what can run in parallel -- and every dispatch, mechanical or architectural, carries an explicit model tier.

Also usessuperpowers

What can run in parallel here is derived from the dependency graph, not assumed from the plan's own layout — a workstream that waits on another's output is sequential work wearing a parallel label. Every dispatch, mechanical or architectural, carries an explicit model tier, and each workstream earns its own andon-verify proof rather than inheriting one from the aggregate result.

Start here

One prompt to start

Break this plan into independent workstreams -- tell me what actually depends on what, from the real dependency graph rather than how the plan happens to be laid out -- then dispatch everything that's genuinely parallel in one message with an explicit model tier per dispatch, and prove each workstream on its own rather than trusting the aggregate result.

Needssuperpowers, compass, andon

Beats

Run these in order. Each prompt is copy-pasteable straight into Claude Code.

superpowers:executing-plans
Execute in a separate session with review checkpoints -- checkpoints cannot be retrofitted onto a run that's already in flight.
compass:compass-decompose-chainalso in 1 other recipe
- Diagnose a pipeline red across several jobs
Derives which workstreams are genuinely independent from the dependency graph rather than by guess; a workstream that waits on another's output is a sequential step wearing a parallel label.
Run this beat on its own
prompt
```
break this plan into independent workstreams -- tell me what actually depends on what and what can truly run in parallel
```
superpowers:subagent-driven-development
Fresh implementer per task with review after each; carries the rule verbatim: always specify the model explicitly when dispatching a subagent, since an omitted model silently inherits the most expensive tier.
superpowers:dispatching-parallel-agentsalso in 2 other recipes
- Triage an incident under time pressure
- Propagate a vendored artifact to N copies
Multiple dispatch calls in one response is what parallel execution actually means here -- one per response is sequential, no matter the intent.
andon:andon-verifyalso in 13 other recipes
Per-workstream proof; a partial parallel result reads exactly like a complete one until something checks each wire on its own.

Worked example

Grounded in — why this beat order is trustworthy

This is where plugins/takt/hooks/hooks.json belongs in the telling: one PreToolUse hook (matcher Skill|Task|Agent|Write|Edit|MultiEdit, inert until .claude/takt.local.md exists) that denies a dispatch running ahead of its declared beat -- a hook, not a skill, so it is named here in prose and never appears in a beats: list.

Do / Don't

Derive which workstreams are genuinely independent from the dependency graph, not from how the plan happens to be laid out.
Send every parallel dispatch in the same response -- one call per response runs sequentially regardless of intent.
Always specify the model explicitly per dispatch -- an omitted model silently inherits the session's, usually most expensive, tier.
Give each workstream its own andon-verify proof rather than letting the aggregate result inherit one shared verdict.
Set up review checkpoints before the run starts -- they cannot be retrofitted onto a run already in flight.

Don't treat a workstream that waits on another's output as parallel -- it's a sequential step wearing a parallel label.
Don't split dispatches across multiple responses expecting parallel execution -- one call per response is sequential, no matter the intent.
Don't omit the model tier on a dispatch -- it silently inherits the most expensive tier instead of the one the task actually needs.
Don't let a partial parallel result pass as complete -- it reads exactly the same until each wire is checked on its own.