From BMAD Planning & Orchestrator
Converts a linear story backlog into conflict-free parallel waves using dependency DAG analysis and topological sorting. Use after stories are ready-for-dev and architecture exists.
How this skill is triggered — by the user, by Claude, or both
Slash command
/bmad-planning-orchestrator:bmad-parallel-planThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Convert a linear backlog into **waves** of stories that can be developed at the same
Convert a linear backlog into waves of stories that can be developed at the same time without colliding — then describe exactly how to merge them back together. This skill produces a plan. Your external dev tools execute it.
Persona flavor: Winston (Architect) reasons about isolation; the workflow does the math.
git.parallelization-plan.md (plus an
optional dependency-graph.json / waves.json for traceability).| Artifact | Path (under output folder) | Used for |
|---|---|---|
| Sprint status | sprint-status.yaml | story ids, epic, status, dependency lists |
| Ready stories | stories/{epic}.{story}.{slug}.story.md | Owned File/Module Scope + Dependency Maps |
| Architecture | architecture.md | semantic-conflict prevention (boundaries, shared modules) |
| Config | userConfig.maxParallel (default 3) | wave width cap |
Only stories at status ready-for-dev (or later) are eligible for a wave.
Lean on architecture for semantic safety. Read architecture.md. Architecture is
what makes parallelism safe — clean module boundaries mean two stories touching
different components won't create a hidden semantic conflict even if the files differ.
Note any shared/cross-cutting modules (auth, config, DB schema, shared types); stories
that touch them are high-conflict and rarely parallelizable.
Read each story's Owned File/Module Scope. Every ready story declares the explicit
list of paths it may touch. Collect {story_id -> [paths]}. A missing or empty scope
is a planning blocker — flag it; do not guess.
Build the dependency DAG, then topologically sort into waves. Edges come from three conflict classes (see REFERENCE.md):
depends_on).Topologically sort: wave N = all stories whose dependencies are already satisfied by
waves < N AND that are pairwise file-disjoint AND pairwise semantically safe. Cap each
wave at maxParallel; overflow rolls to the next wave (lowest id first).
Emit parallelization-plan.md. For each wave, list the ready-for-dev stories; give
each an isolated git-worktree branch name and its disjoint file scope. Then give the
ordered merge sequence: lowest story id first into an integration branch, an
integration review checkpoint, then a single PR integration -> main.
done, re-sort remaining).maxParallel; report drift.State the intent, then proceed.
Both scripts are deterministic and read-only. Resolve paths via ${CLAUDE_PLUGIN_ROOT}.
# 1) Build the dependency DAG (edges + conflict class) from status + story scopes
python3 "${CLAUDE_PLUGIN_ROOT}/skills/bmad-parallel-plan/scripts/build-dependency-graph.py" \
--status "<output>/sprint-status.yaml" \
--stories "<output>/stories" \
--out "<output>/dependency-graph.json"
# 2) Topologically sort into capped waves
python3 "${CLAUDE_PLUGIN_ROOT}/skills/bmad-parallel-plan/scripts/plan-parallel-waves.py" \
--graph "<output>/dependency-graph.json" \
--max-parallel 3 \
--out "<output>/waves.json"
# 3) (Optional) cross-check two scope lists for overlap — shared orchestrator helper
bash "${CLAUDE_PLUGIN_ROOT}/scripts/scope-conflict-check.sh" \
"<output>/stories/2.1.foo.story.md" "<output>/stories/2.2.bar.story.md"
Then render waves.json into the human-facing plan using
templates/parallelization-plan.template.md
and write it to <output>/parallelization-plan.md.
story/{epic}.{story}-{slug} (one worktree each, fully isolated).integration/wave-{N}.integration/wave-{N}.integration/wave-{N} -> main. Wave N+1 branches off the merged main.<output>/parallelization-plan.md — the deliverable.<output>/dependency-graph.json, <output>/waves.json — traceability (optional).<output>/decision-log.md noting maxParallel, wave count,
and any stories deferred for missing scope.depends_on.maxParallel; the dev tool enforces real concurrency, the plan must not exceed it.See REFERENCE.md for the wave algorithm, conflict classes, and merge-order rationale.
Part of the BMAD Planning & Orchestrator plugin — a Claude Code harness for the BMAD Method by the BMAD Code Organization (https://github.com/bmad-code-org/BMAD-METHOD). Implements the spirit of
bmad-parallel-plan. All methodology credit belongs to the BMAD Code Organization.
npx claudepluginhub aj-geddes/claude-code-bmad-skills --plugin bmad-planning-orchestratorEmits and maintains sprint-status.yaml as a sequencing system-of-record. Orders stories by epic and dependency, assigns parallel-set waves, and drives status lifecycle.
Decomposes plans into file-dependency tasks, groups into parallel Waves, outputs Mermaid graphs and split TODO directories. Use to parallelize implementation and visualize deps.
Generates PRDs from task descriptions, manages parallel story execution with dependency resolution, and provides context-filtered agents for multi-story development.