Agent skill · product strategy · aj-geddes
bmad-parallel-plan
Turns a sequential, ready-for-dev story backlog into conflict-free CONCURRENT WAVES. Builds a dependency DAG from epic order, per-story dependency maps, and Owned File/Module Scope overlaps, then topologically sorts it into parallel waves of mutually disjoint, dependency-satisfied stories (capped by maxParallel), and emits a parallelization-plan.md with per-story git-worktree branch names and an ordered merge sequence. Use when the user says "plan parallel work", "which stories can run in parallel", "parallelize the backlog", "build the wave plan", "parallelization plan", "conflict-free workstreams", "what can we run concurrently", "split into worktrees", "dependency graph for the stories", "merge order", or "how do I fan this backlog out to multiple dev agents". Run AFTER stories are ready-for-dev (scrum-master) and an architecture exists. This skill PLANS parallelism only — it does NOT run agents, spawn worktrees, write code, run tests, or perform git operations.
Why this skill is useful
Adds a detailed methodology for planning concurrent development waves that the AI wouldn't reliably generate on its own.
What it needs
About 4k tokens when loaded. Last updated 2026-06-20. 471 stars on the source repository.
What this skill does
BMAD Parallel Plan 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. Scope (read first) This skill plans concurrency. It NEVER spawns worktrees, runs dev agents, writes application code, runs tests, lints, or runs git. Inputs are planning artifacts. The only output is parallelization-plan.md (plus an optional dependency-graph.json / waves.json for traceability). Branch names and merge order are recommendations the dev tool/human carries out. Inputs 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. The four steps 1. 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. 2. Read each story's Owned File/Module Scope. Every ready story declares the explicit list of paths it may touch. Collect {storyid -> [paths]}. A missing or empty scope is a planning blocker — flag it; do not guess. 3. Build the dependency DAG, then topologically sort into waves. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aj-geddes/bmad-parallel-plan