Spec-Driven Implementation

Spec-Driven Implementation

Overview

After a Design Document is approved by the Design Bar Raiser, you do NOT jump directly to code. Instead, you decompose the macro design into N vertical specs—each representing an independently deliverable unit of customer value. Each spec follows the Kiro IDE trio format:

requirements.md → design.md → tasks.md

This intermediate layer exists because macro designs are too coarse for implementation and too abstract for task tracking. A spec bridges the gap: it is precise enough to code against, small enough to deliver in 1–2 weeks, and traceable back to the approved design.

The flow:

Design Document (approved) → Spec 1 → Spec 2 → ... → Spec N → Done
                                 ↓         ↓              ↓
                            Implement  Implement      Implement
                                 ↓         ↓              ↓
                             Deploy     Deploy         Deploy

Each spec is a complete vertical slice: from customer-facing behavior at the top to infrastructure at the bottom. No spec depends on "the rest being finished" to deliver observable value.

When to Use

Important: This skill is invoked as the final phase of the design command (/design), after the system Design Document is approved. It is NOT part of /build. By the time /build starts, all specs must already exist with approved requirements, design, and tasks.

• After the Design Document has been approved by the Design Bar Raiser
• Before incremental-implementation begins on any slice
• When the approved design covers more than a single deployable unit of work
• When multiple engineers will work in parallel on different parts of the system
• When requirements need to be formalized into testable acceptance criteria
• As the last step of /design — creating the specs that /build will execute

Do NOT use for:

• Trivial changes (< 2 hours of work)—go directly to implementation
• Bug fixes with clear root cause—use incremental-implementation directly
• Changes already covered by an existing spec
• Prototype/spike work (use wb-test-and-iterate instead)