Phase 3 — Solutioning

Planning told you what to build and why. Solutioning answers the next question a builder always asks at the whiteboard: how?

This is the phase where the plan becomes a structure you can actually hand to a coding agent. You establish the load-bearing technical decisions, break the work into epics and small shippable stories, and then run one honest check that everything lines up before a single story goes into development.

The temptation here is to over-design — to draw the whole cathedral before laying a brick. Resist it. Good solutioning is about deciding the few things that are expensive to change later, and deliberately deferring everything else to the moment you actually know more. Boring technology, chosen on purpose, tends to outlast clever technology chosen under pressure.

The role that owns this phase: Winston 🏗️, the System Architect. Winston runs the architecture and the epic/story breakdown; the readiness gate is a shared checkpoint the whole hybrid team signs off on.

The goal

Turn the plan (PRD + UX) into a buildable structure without over-engineering it. Concretely, Phase 3 produces three things:

1. An architecture spine — the invariants that everything downstream must respect.
2. Epics and stories — the plan sliced into small, independently-shippable units of work.
3. A readiness verdict — a gate that confirms the PRD, UX, architecture, and stories all agree with each other before you start building.

Two principles run through all of it:

• Bias toward boring technology. Prefer the well-understood option that your team and your coding agents already know how to reason about. Novelty is a cost you pay in every future story; spend it only where it buys real value.
• Tie every decision to value. An architectural choice that no requirement asks for is speculation. If you can't trace a decision back to something in the PRD, it's a candidate to defer.

The architecture "spine"

Run this with /bmad-architecture.

Think of the architecture not as a stack of diagrams but as a spine: the small set of invariants that keep everything built from it consistent. Where does state live? How do modules talk to each other? What are the boundaries no story is allowed to cross? Those decisions are the vertebrae. Everything else — the individual features, epics, and stories — hangs off that spine and inherits its shape.

The value of writing the spine down is that it keeps independently-built parts from diverging. When you (and several coding agents) implement stories in parallel, each one makes a hundred small local choices. Without a shared spine, those choices drift apart and you pay for it later in integration. The spine is the cheapest possible agreement that keeps parallel work coherent.

It scales to the work

A spine is not a fixed deliverable size — it right-sizes to the project:

• A quick spine for a small or well-understood project: a page or two naming the invariants and the boring-technology choices, and little else.
• A full architecture for something larger or riskier: component boundaries, data flow, integration contracts, and the reasoning behind each.
• Brownfield: ratify what exists. On an existing codebase, /bmad-architecture doesn't invent a new architecture — it reads the current one and ratifies it, writing down the invariants already in force so new work respects them instead of fighting them.

When to run it

Reach for the architecture spine when:

• Requirements exist and you're ready to move from what to how. Once there's a PRD (and a UX design, if the project has a UI), you have enough to decide structure.
• Independently-built parts risk diverging. Any time work is about to fan out across multiple stories, agents, or contributors, a spine is what keeps them pointed the same way.

ADRs — the decisions worth remembering

As you make load-bearing calls, capture the meaningful ones as Architecture Decision Records (ADRs) — short notes that record what was decided, why, and what was traded away. An ADR is cheap insurance: six months later, when someone (human or agent) asks "why on earth is it built this way?", the answer is written down instead of lost. ADRs live alongside the architecture in your planning artifacts.

Trade-off — keep the spine lean. Architect the invariants; defer the rest. Every decision you lock in now is a decision you can't cheaply revisit once stories are building against it. So decide only the things that are expensive to change later — the boundaries, the data model, the contracts — and leave the genuinely reversible choices to the story that actually needs to make them. A lean spine that holds beats an exhaustive one that goes stale before the first story ships.

Epics and stories

Run this with /bmad-create-epics-and-stories.

With the spine in place, you slice the plan into work. The hierarchy is simple and it's the same shape the board reads:

• An epic is a meaningful, coherent chunk of the product — a capability that delivers value on its own.
• A story is a small, independently-shippable slice of an epic — the unit a coding agent actually picks up and implements.

The whole art of this step is making stories small and self-contained. A good story can be built, reviewed, and shipped without waiting on three others. And crucially, each story carries the context the dev agent needs: the relevant requirement, the acceptance criteria, the pieces of the architecture it must respect. That context is what lets a coding agent implement the story faithfully in Phase 4 — the story spec is the brief.

A well-formed story earns its keep by carrying everything the build needs, so the coding agent never has to guess:

• A clear outcome — what "done" means, in one or two sentences.
• Acceptance criteria — the concrete, checkable conditions that prove it works.
• The context it touches — the requirement it serves and the architectural invariants it must respect.
• A single, shippable scope — small enough to build and review on its own, with no hidden dependency on a sibling story.

Epics and stories get globally continuous numbering (for example story-flow-1-2, meaning epic 1, story 2), so every piece of work has a stable identifier the board and the terminal both understand.

How the board reads this: BMAD Board renders your epics and stories directly. The Epics view groups the work; the Stories view lets you open any story, read its spec, and launch its next phase. You're not maintaining a separate task tracker — the board is a view onto these artifacts. See Epics and stories in the board.

Check implementation readiness

Run this with /bmad-check-implementation-readiness.

This is the gate. Before any story enters development, you run one check that asks a single blunt question: do the PRD, the UX, the architecture, and the epics/stories all agree with each other?

It's easy for these four artifacts to drift apart while you write them — a requirement the architecture never accounts for, a UX flow with no story behind it, a story that assumes an invariant the spine never declared. The readiness check surfaces exactly those seams. It produces a readiness report naming what's aligned and what still has a gap.

The economics here are simple: a misalignment caught at this gate costs a conversation. The same misalignment caught halfway through implementation costs rework across every story that built on the wrong assumption. This gate is the cheapest place in the whole method to be wrong.

If the report finds gaps, you loop back — tighten the spine, adjust an epic, add the missing story — and re-run. When it comes back clean, the runway is clear for Phase 4.

Artifacts and where they land

Everything Phase 3 produces is written to _bmad-output/planning-artifacts/:

You can read and edit every one of these in BMAD Board's Documents view, which renders the markdown and keeps automatic file versions (a snapshot is taken before each overwrite, so any edit is one click from being restored). The epics and stories additionally drive the Epics and Stories views — the same file, shown as a working board.

How to run it in BMAD Board

Solutioning is a sequence of BMAD commands, and BMAD Board launches each one for you. From the embedded Terminal — or the Command Palette (Cmd+K) — run them in order:

/bmad-architecture                     # build (or ratify) the spine
/bmad-create-epics-and-stories         # slice the plan into epics + stories
/bmad-check-implementation-readiness   # the alignment gate

Each command opens a conversation with the agent that owns it, writes its output into _bmad-output/planning-artifacts/, and returns you to the board — where the epics and stories you just created are already rendered, ready for the story cycle. Pick your coding agent (Claude Code, Codex CLI, Gemini CLI, Cursor, Aider, Open Code, or any other terminal agent that supports the BMAD method) when you launch; the method is the same whichever one you drive.

Prerequisite: Phase 3 assumes a PRD from Planning (and a UX design, if your project has a UI). If you don't have those yet, run that phase first — /bmad-architecture builds on the plan, it doesn't replace it.

Next steps

You've decided how to build it and confirmed everything lines up. Now you build it, one story at a time.

→ Phase 4 — Implementation: sprint planning, then the repeating story cycle — Create Story → Dev Story → Code Review — with a retrospective at each epic's close.

See also

• Phase 2 — Planning — the PRD and UX that feed this phase (previous)
• The method — overview — the four phases, end to end
• Epics and stories in the board — how BMAD Board renders the work you just structured
• Slash-command reference — every /bmad-* command in one place