Execute a written plan across parallel workstreams

Genuine independence, derived from the dependency graph rather than assumed, decides what can run in parallel -- and mechanical and architectural dispatches are tiered deliberately where the cost matters.

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. Mechanical and architectural dispatches are tiered deliberately where the cost matters, 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, choosing a model tier per dispatch where the cost matters, and prove each workstream on its own rather than trusting the aggregate result.

Needssuperpowers, zirkel, andon

Beats

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

1. superpowers:executing-plans

   Execute in a separate session with review checkpoints -- checkpoints cannot be retrofitted onto a run that's already in flight.

2. zirkel:zirkel-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

   break this plan into independent workstreams -- tell me what actually depends on what and what can truly run in parallel

3. superpowers:subagent-driven-development

   Fresh implementer per task with review after each; recommends specifying the model explicitly when dispatching a subagent, since an omitted model inherits the session's, possibly most expensive, tier.

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

5. andon:andon-verifyalso in 15 other recipes

   • Audit supply-chain pinning and dependencies
   • Finish and integrate a development branch
   • Investigate a job that reports success but changed nothing
   • Investigate a fix that did not stick
   • Investigate tests that pass while the code is broken
   • Root-cause a bugfix from a tracked issue
   • Build a new feature in an existing codebase
   • Collapse duplication hand-synced across N sites
   • Fix an existing dashboard without breaking it
   • Migrate a return shape or type representation
   • Propagate a vendored artifact to N copies
   • Audit your own agent and skill definitions for loop-reliability defects
   • Rework a plugin to the official Anthropic standard
   • Do oracle engineering and numerical V&V
   • Whole-branch review without re-trusting the branch's own self-assessment

   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.
• ✓Choose the model tier per dispatch where the cost matters -- an omitted model inherits the session's, possibly most expensive, tier by design.
• ✓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 fan out a dozen mechanical dispatches on an inherited expensive tier without noticing -- tier them deliberately.
• ×Don't let a partial parallel result pass as complete -- it reads exactly the same until each wire is checked on its own.