Level 9Lesson 0⏱️ 120 min

Level 9 Capstone

Spec your own small app end-to-end - constitution, EARS requirements, architecture, and stories - with an interactive Spec Builder

Write the Blueprint, Not Just the Bricks

Across eight lessons you learned to stop vibe-coding and start specifying: EARS requirements, the SDD toolbox, BMAD's agent team and workflow (with a full build), and LID's enforced traceability. This capstone has you produce a complete spec pack for an app of your own - the deliverable a coding agent could actually build from.

No code required. In spec-driven development, a great spec is the work.

Your Mission

Pick a small app you'd genuinely like to exist, then produce a complete spec pack with five parts:

1. CONSTITUTION   - 4-6 governing principles (stack, testing, rules)

2. PRD            - purpose + functional requirements in EARS form
                    + non-functional requirements (speed/security/a11y)

3. ARCHITECTURE   - the main components, the data model, and one or
                    two "always do it this way" rules

4. STORIES        - shard the PRD into small, checkable stories, each
                    with embedded acceptance tests and an out-of-scope line

5. METHOD & FIT   - which method (Spec Kit / BMAD / LID) you'd use and
                    WHY - and an honest note on whether SDD even fits

🏆 Capstone Project Helper

Use the SDD Spec Builder to generate parts 1, 2, and 4 in one shot. Name your app, pick a methodology, list your features and constraints - it writes a constitution, an EARS PRD (with greppable IDs), a story list, and the exact workflow steps for your chosen method. Copy it out as your starting spec-pack.md.

📐 SDD Spec Builder

Describe your app and pick a method. It generates a constitution, an EARS PRD, a story list, and the workflow steps - ready to copy into your project.

Add an app name, a purpose, and at least one feature to generate your spec pack.
spec-pack.md
# (App name) - Spec Pack
Methodology: BMAD

## Constitution (governing principles)
- Every feature ships with tests.
- A human approves each step before the next.
- All artifacts (spec, plan, stories) are committed to Git.

## PRD
Purpose: (one-line purpose)

### Functional requirements (EARS)


### Non-functional requirements
NFR-1  The app shall persist data across refreshes.
NFR-2  Every action shall be reachable by keyboard.

## Stories / tasks (one small, checkable unit each)


## BMAD workflow
PHASE 1 - Agentic Planning (no code yet):
  Analyst → brief   PM → this PRD   Architect → architecture
  Product Owner → alignment check + shard into the stories below
PHASE 2 - Context-Engineered Development (loop per story):
  Scrum Master writes one rich story file → Developer builds it on a
  branch with tests → QA + automated checks review → human approves → merge.
Keep dev agents lean: give each only its story + the relevant architecture.
Then make it yours: the generator gives you a clean, correct skeleton - but the judgment is the point. Tighten the EARS wording, add acceptance criteria, and cut any feature that doesn't earn its place. A generated spec you edited thoughtfully beats a generated spec you didn't read.

Finish Parts 3 and 5 by Hand

Part 3 - Architecture (from Lessons 77-78)

Sketch the components, the data model for one record, and one or two rules that keep the codebase clean (like "only the Store module touches storage").

Part 5 - Method & fit (from Lesson 80)

State which method you'd use and why, and be honest: is this app big and long-lived enough to deserve full SDD, or would light SDD do? Defend your call.

What "Great" Looks Like

A strong submission:
  • Requirements are in real EARS form - each one a single, checkable claim with a clear trigger and response.
  • Includes non-functional requirements, not just features.
  • Stories are small, with acceptance tests and explicit out-of-scope lines.
  • Picks a method deliberately and justifies it - and isn't afraid to say "this one's small enough to go light."
  • Reads like a blueprint a teammate (human or agent) could build from without guessing.

What You Have Learned in Level 9

  • L73 - Vibe coding vs SDD; intent gaps; the Spec → Plan → Tasks → Implement loop
  • L74 - Writing specs that don't lie: EARS, FRs vs NFRs, acceptance criteria
  • L75 - The SDD toolbox: Spec Kit, Kiro, OpenSpec, Tessl; read-once vs living specs
  • L76 - BMAD's AI product team and two phases
  • L77 - The BMAD workflow, the sharded story file, the control manifest
  • L78 - A full small-app build with BMAD, end to end
  • L79 - LID: the arrow, greppable IDs, the CI gate, failing-first tests
  • L80 - Best practices and anti-patterns; matching process to stakes
You can now make an AI build the right thing. You've closed the loop on the last three levels: specs pin down intent, context (Level 8) feeds the agent the right slice of it, and loops (Level 7) execute and verify it. That's the modern craft of building software with AI - not typing cleverer prompts, but designing intent, context, and process so the machine builds what you actually meant.

Spec the blueprint. Stay the architect.

🧠 Check your understanding

5 quick questions on Level 9. Answer each, then check your score.

1. Spec-Driven Development (SDD) means...
2. What is EARS?
3. BMAD's two phases are...
4. LID's core idea ("the arrow") is that...
5. A key SDD anti-pattern is...
💬

How was Level 9?

Your feedback helps improve this course. Takes 30 seconds.

Overall rating *

Select a star rating to submit.

← Best Practices & Anti-Patterns