docs/plan/choose-a-planning-path.md
Use this page to decide how much planning a change needs. The answer turns on
one question: is the intent already well defined? If it is, feed it to
bmad-spec, which shapes it to the size of the work, and build. If it is not,
the other pages in this chapter are how you get a defined intent. If the work
belongs to an organization, with a PRD other people must approve and several
engineers building in parallel, read
Plan Inside an Organization first; it
says how this chapter fits the process you already have.
A well-defined intent says what should be true when the work is done, what must not change, and what is out of scope: complete enough that someone else could build it without guessing, and no longer than that. Where it came from does not matter: a sentence, an issue, a forged idea, a research report, a PRD.
Keep the input short. bmad-spec reads everything you give it in one pass,
and the practical ceiling is a few tens of thousands of tokens, roughly a
40-page document. Hand it a pile of raw documents several times that size and
it silently loses the parts that mattered; condense them first. If the spec
says the input is too thin, you are not done on this chapter yet.
bmad-spec with it. A spec that fits one Build
session goes straight to bmad-build; an epic-sized one gets Story Breakdown
and a Build per story. See
Define Requirements and a Specification.bmad-spec. The spec skill writes the contract; it does not
help you figure out what you want.If the change fits one implementation session, you are on the Build page's territory, not this chapter's: Build a Change covers sizing a session and whether a small change needs BMad at all.
:::note[Prerequisites] Install BMad before using Build or another BMad workflow. You don't need BMad for an obvious, low-risk edit. :::
These are independent tools, not stages. Pick the ones the gap calls for, in
any order. None of them build anything. Condense what they produce and hand
bmad-spec the result, not the raw pile.
| The intent is missing | Do this |
|---|---|
| A clear idea at all, or confidence the idea is good | Explore and Validate an Idea |
| Evidence a decision should rest on | Research a Decision |
| A written account of what the product is, for a PRD or a pitch | A brief or PRFAQ: Define Requirements and a Specification |
| Shared decisions several epics or agents must follow | Design UX and Architecture |
| Agreement, ownership, and sign-off among several people or teams | A PRD as the document the organization owns: Plan Inside an Organization |
A short list of decisions is often enough on its own. You need a PRD when more
than one person must agree on what the product is, or more than one epic must
not diverge; otherwise skip it. A multi-epic product runs bmad-spec once per
epic with those documents as sources.
Every skill in this chapter writes a document you can hand on. The table runs
from analysis through planning to solutioning; each chapter page is linked
from the first skill it covers and explains when its skills fit. In an
installed project, bmad-help recommends the next one.
| Skill | Purpose | Produces |
|---|---|---|
bmad-brainstorming | Generate ideas with a facilitated session (Explore and Validate an Idea) | brainstorm.html keepsake plus an optional brainstorm-intent.md |
bmad-forge-idea | Pressure-test an idea until it hardens, proves out, or dies cheaply | forge-report.html every run; forged-idea.md when the idea hardens |
bmad-deep-recon | Research a subject to support a decision (Research a Decision) | Cited research.md plus an optional HTML briefing |
bmad-product-brief | Capture the product vision when the concept is clear (Define Requirements and a Specification) | brief.md + addendum.md |
bmad-prfaq | Stress-test a product concept customer-first, working backwards from the press release | prfaq-<project>.md |
bmad-prd | Create, update, or validate a PRD | Create/update: prd.md, addendum.md, .memlog.md; validate: HTML + .md report |
bmad-ux | Record how the product looks and behaves (Design UX and Architecture) | DESIGN.md, EXPERIENCE.md, .memlog.md |
bmad-spec | Condense any intent into a short contract; break it into stories on request | SPEC.md + companions under specs/spec-<slug>/; optional stories.yaml |
bmad-architecture | Make the technical decisions that keep separately built parts consistent | ARCHITECTURE-SPINE.md by default |
bmad-create-epics-and-stories | Break requirements into epics and stories (Break Work into Stories and Track It) | Epic files with stories |
bmad-sprint-planning | Check readiness before implementation, then track story status | PASS/CONCERNS/FAIL + sprint-status.yaml |
bmad-prd has three intents, create, update, and validate; say which one you
want when you invoke it, or it will ask. bmad-product-brief feeds bmad-prd,
which reads the brief during discovery, but neither requires the other.
The size of the intent decides how many Build sessions follow. One coherent outcome that needs several sessions is an epic. Work that spans several epics, or likely needs roughly 20 or more sessions, is a project. Scope is only one signal: use more planning when the work has high risk, unclear requirements, broad architectural reach, cross-system effects, or coordination between people or teams.
Every path uses the same implementation unit. Larger work adds shared context around that unit and repeats it; it does not switch to a separate delivery system.
Use this path when the work needs several Build sessions but still has one coherent outcome.
Define and divide the epic
bmad-spec with the epic intent. See
Define Requirements and a Specification
for what a spec contains and when it is enough on its own.stories.yaml beside
SPEC.md.The story list is an execution plan, not a promise that nothing will change. Update the spec and re-run Story Breakdown when earlier work reveals a missing constraint, a better division, or a conflict between stories.
Establish the implementation pattern
Implement important, risky, or foundational stories with bmad-build. Early
stories often settle the architecture, initial project structure, and repeated
patterns that later stories will follow. Give those decisions human attention
before automating repetitions of them.
Run Build once per story. Build creates or resumes that story's implementation record under the spec folder and keeps it linked to the parent spec.
Finish the epic
Verify the stories together, not only one at a time. Then run
bmad-retrospective with the spec folder. Retrospective reads stories.yaml
as the epic inventory and judges the combined result against the parent spec.
See Finish an Epic.
Use the full BMad flow for a greenfield product, a multi-epic initiative, or work likely to need roughly 20 or more implementation sessions.
Prepare only the planning the project actually needs from the table above
(Plan Inside an Organization covers who
owns which document and where sign-off happens). Then run bmad-spec per epic,
track the stories with
Break Work into Stories and Track It,
and close each epic with Finish an Epic.
These documents coordinate implementation. They do not replace Build. Each epic still becomes a sequence of one-session units. Independent epic streams can proceed in parallel when their boundaries are explicit. Each stream needs an owner, and all streams stay accountable to the same product intent and architecture. Run integration checks and a retrospective at each epic boundary.
Dividing work can lose information: a requirement weakens, a constraint disappears, or two correct stories fail when combined. The PRD, architecture, and specs exist so later sessions can still see the whole.
bmad-build-auto runs one session without waiting for human input. It does
not choose the next story or own the backlog. Use it after the important
implementation decisions are stable. For the worker contract, see
Autonomous Development Loops.
A path sized to the work: a spec and stories for an epic, or shared product documents plus one spec per epic for a project — each still implemented one Build session at a time.