bmad-planning-orchestrator/skills/bmad-sprint-planning/SKILL.md
Orchestration handoff bridge: emits and maintains sprint-status.yaml as the project's sequencing system-of-record. Orders stories by epic then dependency, assigns parallel-set (wave) membership, and drives the status lifecycle (backlog → ready-for-dev → in-progress → review → done) as a view — never as a metric. Use when the user says "sequence the stories", "build the sprint status", "plan the waves", "create sprint-status.yaml", "assign parallel sets", "order stories by dependency", "what can run in parallel", "set up story sequencing", "initialize sprint tracking", "ready the backlog", or "prepare for dev handoff". Also triggers on "sprint planning" when the project already has epics defined. SCOPE: SEQUENCING AND ORCHESTRATION ONLY. No velocity, no burndown, no committed points, no coverage metrics. Capacity is expressed as wave width (concurrent story count), not points. The final artifact is a ready-for-dev handoff manifest; implementation is delegated to external dev tools.
npx skillsauth add aj-geddes/claude-code-bmad-skills bmad-sprint-planningInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Role: Sequencing & Handoff Bridge — Phase 4 orchestration
System-of-record: bmad-output/sprint-status.yaml
bmad-output/.parallel_set (wave) — stories in the same wave have no mutual dependencies and can run concurrently.bmad-output/sprint-status.yaml using the canonical template.ready-for-dev; all others remain backlog.This skill does not write application code, run tests, lint, build, or review diffs.
| Intent | Trigger phrase | Action |
|--------|---------------|--------|
| Create | "initialize sprint status", "first time" | Scaffold fresh sprint-status.yaml from template |
| Update | "re-sequence", "story X is done", "add story", "update wave" | Mutate existing sprint-status.yaml in-place |
| Validate | "check sequencing", "are dependencies correct", "show wave plan" | Read and report without writing |
Load planning artifacts
Glob: bmad-output/**/*.md, bmad-output/**/*.yaml
Priority order: epics.md → prd.md → architecture.md → individual story files.
Extract epics and stories
{epic}.{story}.{slug}.story.md (e.g., 2.1.stripe-integration.story.md)epics.md or prd.mdBuild dependency graph
dependencies[] from each story's frontmatter or Dev Notes sectionInitialize sprint-status.yaml
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-sprint-planning/scripts/init-sprint-status.sh
Then populate with sequenced data (see template).
Sequence stories
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-sprint-planning/scripts/sequence-stories.sh
Set initial statuses
status: ready-for-devstatus: backlogstatus: in-progress if any child story is ready-for-dev; else backlogEmit handoff summary — list wave 1 stories by owned_scope for conflict-free parallel dispatch
When a story moves to done:
dependencies[] lists where it appearsready-for-devsprint-status.yamlWave width (how many stories can run at once) is not a fixed number — it is the size of the dependency-free frontier at each topological level. There is no points budget or velocity ceiling.
Wave 1: all stories with no dependencies
Wave 2: all stories whose only dependencies are in wave 1
Wave N: all stories whose dependencies are fully in waves 1…(N-1)
Stories within a wave MUST have non-overlapping owned_scope to be safe for parallel dispatch. If two stories in the same wave share a file, split them into separate waves or document the conflict.
backlog → ready-for-dev → in-progress → review → done
| Track | Story count | Sprint-status behavior | |-------|-------------|----------------------| | Quick Flow | 1–15 | Single wave pass; minimal epic structure | | BMAD Method | 10–50+ | Full wave assignment; epic grouping | | Enterprise | 30+ | Multi-phase wave planning; dependency map documented in REFERENCE |
Track is confirmed with the user before generating the status file.
Pattern: Parallel dependency analysis
Use when: 15+ stories across 3+ epics
| Agent | Task | Output |
|-------|------|--------|
| Agent 1 | Parse all story files, extract dependency declarations | bmad-output/context/dependency-raw.yaml |
| Agent 2 | Parse epic ordering from PRD/epics.md | bmad-output/context/epic-order.yaml |
| Agent 3 | Identify owned_scope conflicts within candidate waves | bmad-output/context/scope-conflicts.md |
Main context: merge outputs, run topological sort, write sprint-status.yaml.
Task: Extract dependencies from all story files
Context: Read all *.story.md files under bmad-output/stories/
Objective: For each story, output its id and its dependencies[] list
Output: Write YAML list to bmad-output/context/dependency-raw.yaml
Format:
- id: "2.1.stripe-integration"
dependencies: ["1.3.user-auth"]
- id: "2.2.payment-webhook"
dependencies: ["2.1.stripe-integration"]
init-sprint-status.shScaffolds bmad-output/sprint-status.yaml from the template if it does not exist.
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-sprint-planning/scripts/init-sprint-status.sh \
[project-name] [output-dir]
sequence-stories.shOrders stories: epics first (by epic number), then stories within each epic by dependency
(topological), then assigns parallel_set integers.
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-sprint-planning/scripts/sequence-stories.sh \
[sprint-status-file]
${CLAUDE_PLUGIN_ROOT}/skills/bmad-sprint-planning/templates/sprint-status.template.yaml
Fields: epics[], stories[] (with id, title, status, dependencies, parallel_set,
owned_scope). The template contains no velocity, burndown, or points fields.
sprint-status.yaml before writingready-for-dev stories and their owned_scopebmad-output/decision-log.md
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-sprint-planning. All methodology credit belongs to the BMAD Code Organization.
testing
Solutioning-phase UX planning skill (optional; activate when the project has a UI). Produces TWO planning documents: DESIGN.md (the visual system — design tokens, color palette, typography, spacing, component specs, WCAG 2.1 AA contract) and EXPERIENCE.md (user journeys, flow diagrams, screen states, error/empty/loading handling). Use when the user says "design the UX", "create UX planning docs", "define the design system", "map the user flows", "UX for this feature", "wireframe the flows", "what are the user journeys", "accessibility design", "WCAG compliance", "design tokens", "responsive design plan", "mobile-first design", or "create DESIGN.md / EXPERIENCE.md". Runs after architecture is drafted and before stories are created. Supports Create / Update / Validate intents.
testing
Quick Flow lightweight technical specification for small-scope work (1-15 stories). Replaces the full PRD + architecture pair when scope is small and requirements are clear. Produces bmad-output/tech-spec.md as the single planning artifact before story creation. Use when the user says: "write a tech spec", "create a technical specification", "I need a tech spec for this feature", "quick spec", "small project spec", "we don't need a full PRD", "just a tech spec", "spec out this change", "document this feature". QUICK FLOW TRACK ONLY (1-15 stories). If scope grows beyond ~15 stories or involves multiple teams / external integrations at scale, stop and redirect to bmad-prd + bmad-architecture instead — those skills are built for that complexity. Supports three intents: Create (new spec), Update (revise an existing tech-spec.md), Validate (review a draft for completeness against BMAD criteria).
development
Distills ANY messy input — brain dump, transcript, long PRD, stakeholder notes, feature request, voice memo — into a tight five-field SPEC.md kernel that any downstream planning skill can consume. The five fields are: Problem, Capabilities, Constraints, Non-Goals, Success Metrics. Use when the user says "create a spec", "write a spec for", "distill this into a spec", "I have a brain dump", "turn this into something structured", "clean up these notes", "make a SPEC from", "I want to define the problem", "help me scope this", "summarize what we're building", "I have a PRD but need a kernel", "what are we actually solving?", or drops raw text/transcript and asks for structure. Also use when starting any new initiative and a clean shared definition is missing.
development
Conducts market, competitive, domain, and technical research using live web sources, producing a cited research-report.md to inform BMAD planning decisions. Use when the user says: - "research [topic/market/technology]" - "competitive analysis" or "who are the competitors" - "market size" or "market landscape" - "technical research" or "evaluate [technology/framework]" - "domain research" or "industry analysis" - "what does the market look like" - "find out about [technology/space]" - "I need research before we plan" - "gather information on [topic]" Supports three modes: Create (new research), Update (refresh existing report with new sources), Validate (cross-check claims in an existing report against live sources). Output lands in bmad-output/ as a cited research-report.md ready for downstream planning skills (business-analyst, product-manager, system-architect).