The SDD Lifecycle

From idea to running code — one phase at a time

Day 2 · Session 10 — with BMAD V6 as our worked method

Session 9: what a spec is and why it beats prompting.
This session: the pipeline — so when Lab 4 starts,
you're not guessing what to write, you're following a process.

One Pipeline, Many Names

You'll meet several SDD toolkits. They're the same pipeline with different labels.

Principles → What → How → Units → Build → Verify

  • GitHub Spec Kit: Constitution → Specify → Plan → Tasks → Implement → Analyze
  • BMAD V6: project-context → Planning → Solutioning → Implementation
  • AI-DLC: guardrails → Inception → Construction → Operations

Learn the pipeline once. The tool names stop mattering.
We'll use BMAD V6 as our hands-on method.

The Canonical Pipeline (our reference)

CONSTITUTION   project-wide, non-negotiable principles      [persists]
     │
     ▼
SPECIFICATION  the WHAT & WHY — user journeys, success        [per feature]
     │
     ▼
PLAN           the HOW — stack, architecture, contracts       [per feature]
     │
     ▼
TASKS / STORIES  small, testable units of work                [per feature]
     │
     ▼
IMPLEMENT      generate code, one unit at a time              [per feature]
     │
     ▼
VERIFY         check output against spec & constitution       [gate]

Each layer constrains the next. You validate at every gate before advancing.
Your role: steer and verify — the agent generates, you ensure it's right.

Part 1 — The Phases

Phase 0 — Constitution

WHY — without project-wide rules, the agent re-decides conventions every feature and drifts.

WHAT — the non-negotiable principles: stack standards, security posture, conventions, governance.

HOW (BMAD V6) — a project-context.md file that "works like a constitution for your project, guiding implementation decisions across all workflows." Generated from your architecture/codebase or written by hand.

It outranks everything. Same idea as Day 1's CLAUDE.md, scaled to the whole project.
(Optional but strongly recommended — set it before building features.)

Phase 1 — Analysis (optional)

WHY — for fuzzy ideas, exploring the problem space first prevents building the wrong thing.

WHAT — validate the idea before committing to planning.

HOW (BMAD V6) — workflows like bmad-brainstorming, market/technical/domain research, bmad-product-brief → a product-brief.md.

WHEN — skip it for well-understood work (that's what the Quick Flow is for). Use it for genuinely new territory.

For StackLog you can skip this — you already know the product. Mentioned so you know it exists.

Phase 2 — Planning (the Specification)

WHY — the what & why must be explicit before any how.

WHAT — define what to build and for whom: requirements, success criteria, scope, out-of-scope.

HOW (BMAD V6) — bmad-prd produces prd.md (+ addendum.md, decision-log.md). Optionally bmad-ux for DESIGN.md + EXPERIENCE.md.

This is the Specification layer of the canonical pipeline.
One skill, three intents: Create / Update / Validate a PRD.

Phase 3 — Solutioning (the Plan + the Units)

WHY — once the what is fixed, decide how, then break it into buildable pieces.

WHAT — technical decisions made explicit, then requirements split into stories.

HOW (BMAD V6):

  • bmad-create-architecture → architecture.md with ADRs (the Plan)
  • bmad-create-epics-and-stories → epic files with stories (the Units)
  • bmad-check-implementation-readiness → a PASS / CONCERNS / FAIL gate

This collapses the canonical Plan + Tasks layers into one phase.
The readiness gate is the checkpoint before any code is written.

Phase 4 — Implementation

WHY — build in small, validated increments, not one giant dump.

WHAT — implement story by story, with review built in.

HOW (BMAD V6):

  • bmad-sprint-planning → sprint-status.yaml (once per project)
  • bmad-create-story → prepare the next story
  • bmad-dev-story → implement it (working code + tests)
  • bmad-code-review → validate quality (approved / changes requested)
  • bmad-correct-course → handle mid-sprint changes

This is Implement + Verify. Review isn't a final step — it runs per story.

The Quick Flow (the escape hatch)

Not every task deserves the full pipeline.

HOW (BMAD V6) — bmad-quick-dev: one unified flow that clarifies intent, plans, implements, reviews, and presents → produces spec-*.md + code.

This is the simplicity principle from Day 1, in the method itself:
small, well-understood work skips Phases 1–3. Match process to stakes.

Part 2 — The Agents (Personas as Subagents)

V6 Named Agents

In V6, each persona is a named agent, invoked as a skill:

Agent Role Owns
Analyst (Mary) explore & validate brainstorming, research, brief
Product Manager (John) define what PRD, epics & stories, readiness
Architect (Winston) decide how architecture + ADRs
Developer (Amelia) build & review dev story, code review, sprint
UX Designer (Sally) design experience UX design
Tech Writer (Paige) document docs, diagrams, explanations

You don't need all six for StackLog. The spine is PM → Architect → Developer.

The Bridge — Still Subagents

Session 2: an orchestrator directing subagents.
Session 9: BMAD personas are those subagents.
Session 10: V6 just gives them names and skill IDs.

You are the orchestrator.
You switch agents; each runs the phase it owns; you verify the handoffs.

The thinking from Day 1 hasn't changed — only the scope and the tooling around it.

Context Is the Whole Point

Why the pipeline produces documents at all:

Each document becomes the context for the next phase.
The PRD tells the architect what constraints matter.
The architecture tells the dev agent which patterns to follow.
The story gives focused, complete context for one unit of code.

Without this structure, agents make inconsistent decisions.
The artifacts ARE the context engineering.

How You'll Run It (V6 mechanics)

  • BMAD installs into your project; each agent is a skill (e.g. bmad-agent-pm).
  • Invoke by trigger code (e.g. PRD, CA, DS) — the agent loads the workflow and prompts you through it.
  • Works with any AI coding assistant that supports custom context — including Antigravity.
  • Lost? The bmad-help skill guides you to the next step.

You'll install and drive this in Lab 4. For now, know the shape: invoke an agent → run its workflow → validate the artifact → hand off to the next.

Anchor This

The SDD lifecycle is one pipeline:
Constitution → Spec → Plan → Units → Implement → Verify.

BMAD V6 is how we run it: a constitution file, four phases
(Analysis · Planning · Solutioning · Implementation),
named agents invoked as skills, validated at every gate.

You are the orchestrator. The agents are your subagents.
Next: Lab 4 — you write StackLog's spec.

References

  • BMAD Method V6 — docs.bmad-method.org (Workflow Map, Agents, Project Context)
  • BMAD repo — github.com/bmad-code-org/BMAD-METHOD
  • GitHub Spec Kit (canonical SDD vocabulary) — github.com/github/spec-kit
  • AI-DLC (lifecycle framing) — specs.md