Specs-Driven Development

Specs-driven development (SDD) is the core methodology of Buildpad’s AI workflow, in every AI IDE. You describe what you want in plain English, your AI generates three structured documents — requirements.md, design.md, tasks.md — and you review each one before any code is written. Implementation then proceeds task by task against the approved spec.

This workflow works the same everywhere. In Kiro it’s built in via the native Specs feature. In every other AI IDE — GitHub Copilot, Claude Code, Antigravity — the Buildpad starter bundles spec skills (/buildpad-spec-*) that run the identical workflow with the identical artifacts, so a project can move between IDEs without converting anything.

The Three Spec Stages

Each stage produces one document. You approve it before the next stage starts.

Stage	Document	What’s in it	What to review
1. Requirements	`requirements.md`	User stories and acceptance criteria (EARS format)	Are all the user-facing features listed? Anything missing?
2. Design	`design.md`	Technical architecture, data models, page structure	Does the shape match your mental model? Are the data models reasonable?
3. Tasks	`tasks.md`	Numbered, discrete implementation steps grouped by checkpoint	Does the task list cover every requirement? Are checkpoints in sensible places?

The artifacts live in your project under .kiro/specs/<feature-name>/:

- - - requirements.md
    - design.md
    - tasks.md

Checkpoints in `tasks.md`

tasks.md is a numbered list of discrete work items. Tasks are grouped by checkpoints — natural pause points where you stop, run the app, and verify what’s built before continuing. The Vibe Coder tutorial uses checkpoints at Tasks 3, 8, and 15 to separate the data layer, UI layer, and access-control layer.

Run tasks sequentially. Don’t skip ahead — each checkpoint depends on the previous one being verified.

How to Use Specs in Kiro

Open the Kiro pane (the ghost icon in the activity bar).
Click the + button under Specs.
Describe what you want to build in plain English.
When prompted, choose Feature, then Requirements-First.
Kiro generates requirements.md. Review it; ask Kiro to revise if anything is missing.
Approve to move to Design, then to Tasks.
Run tasks one at a time via the Run task button, stopping at each checkpoint to verify.

How to Use Specs in Other IDEs

The starter bundles the spec workflow as slash-command skills (adapted from cc-sdd , producing Kiro-compatible artifacts). In Copilot Chat, Claude Code, or the Antigravity agent panel:


/buildpad-discovery <idea>            # unsure if it's one spec, many, or none? start here
/buildpad-spec-init <description>     # initialize the spec
/buildpad-spec-requirements <feature> # generate requirements → review & approve
/buildpad-spec-design <feature>       # generate design → review & approve
/buildpad-spec-tasks <feature>        # generate tasks → review & approve
/buildpad-impl <feature>              # implement task-by-task with TDD + review
/buildpad-spec-status <feature>       # check progress anytime

For a single small feature you can take the fast path with /buildpad-spec-quick <description>. Supporting skills cover steering (/buildpad-steering), validation (/buildpad-validate-design, /buildpad-validate-gap), review (/buildpad-review), and debugging (/buildpad-debug).

Don’t let the AI skip the review steps. The whole point of specs-driven development is to catch missing requirements before code lands — the cost of fixing a missed acceptance criterion in requirements.md is a sentence; the cost in deployed code is a refactor.

Why Specs-First

Catch missing requirements while cheap — issues found in requirements.md cost a sentence to fix; issues found in deployed code cost a refactor
AI accuracy on bounded scope — generating code from an approved tasks.md is far more reliable than generating from an open-ended prompt
Shared review artifact — requirements.md is something a non-technical stakeholder can read and approve, the same way they’d approve a wireframe
Reproducible plan — re-read requirements.md and design.md at any time to remember why something was built the way it was
IDE-portable — the artifacts are plain Markdown in .kiro/specs/, readable by Kiro natively and by every other IDE via the bundled skills

Development Methodology — the full engineering loop this workflow sits inside
Kiro setup — install Kiro and connect to your Buildpad backend
Tutorial: Plan Your App with AI — a hands-on walkthrough of creating your first spec
Kiro Specs documentation — the official feature reference
cc-sdd — the open-source project the Buildpad spec skills are adapted from