SDD Framework

Tasks, Implementation & Quality Gates

Generate ordered task breakdowns with dependency tracking and use quality gates to validate implementation at every stage.

How spec-tasks Works

After the design document is approved, /kiro:spec-tasks [feature] decomposes the design into ordered implementation tasks. Each task includes:

  • Task ID: Hierarchical numbering (1.1, 1.2, 2.1, etc.)
  • Description: What to implement, precisely
  • Priority: P0 (sequential, blocks other tasks) or P1 (parallelizable)
  • Dependencies: Which task IDs must complete before this one
  • Requirement tracing: Which REQ-xxx this task satisfies

The priority system enables efficient execution. P0 tasks form the critical path and must execute sequentially. P1 tasks can run in parallel once their dependencies are met.

Example Task Breakdown: Authentication System

text
Task 1.1 [P0] Create auth database schema
  Dependencies: none
  Satisfies: REQ-001, REQ-002

Task 1.2 [P0] Implement password hashing service
  Dependencies: 1.1
  Satisfies: REQ-001

Task 1.3 [P1] Build login API route
  Dependencies: 1.2
  Satisfies: REQ-002, REQ-003, REQ-004

Task 1.4 [P1] Build registration API route
  Dependencies: 1.2
  Satisfies: REQ-005, REQ-006

Task 1.5 [P0] Implement session management
  Dependencies: 1.3
  Satisfies: REQ-002, REQ-007

Task 1.6 [P1] Build password reset flow
  Dependencies: 1.2
  Satisfies: REQ-008, REQ-009, REQ-010

Task 1.7 [P1] Build MFA verification
  Dependencies: 1.5
  Satisfies: REQ-011

Task 1.8 [P0] Create login UI component
  Dependencies: 1.3
  Satisfies: REQ-002

Task 1.9 [P0] Integration and end-to-end tests
  Dependencies: 1.3, 1.4, 1.5, 1.6, 1.8
  Satisfies: all REQs (verification)

Note: 1.3 and 1.4 are both P1 and depend only on 1.2 — they can run in parallel. 1.6 and 1.7 can also run in parallel once their dependencies are met.

How spec-impl Works

/kiro:spec-impl [feature] [task-ids] implements the specified tasks:

  1. AI reads the requirements.md and design.md for context
  2. AI reads all steering files for conventions
  3. AI writes code for the specified tasks
  4. AI writes tests for the implemented code
  5. AI validates the implementation against the specific requirements each task satisfies
  6. AI checkpoints (saves progress) after each task

You review at completion. If a task's output is not correct, you can re-run it with more specific guidance.

Quality Gates Explained

Quality gates are explicit human verification checkpoints:

validate-gap (before design, brownfield only): Catches "I'm about to build something that already exists" or "I'm missing an existing dependency."

validate-design (before tasks): Catches "The architecture I proposed conflicts with the existing codebase" or "I missed a requirement."

validate-impl (after implementation): Catches "The code doesn't fully satisfy the requirements" or "The implementation diverged from the design."

Each gate catches a different category of error at the lowest possible cost to fix.

The "Bolts Not Sprints" Concept

Traditional sprints have significant overhead: sprint planning, daily standups, sprint reviews, retrospectives. Much of this ceremony exists to coordinate work that AI can now execute in hours.

The AI-DLC replaces sprint ceremonies with:

  • Steering (once): Equivalent to architecture and convention alignment across the whole team
  • Spec review (per feature): Equivalent to sprint planning for that feature
  • Validate gates (per stage): Equivalent to code review and QA
  • Bolt (execution phase): Intensive hours/days of AI implementation with human oversight

A feature that took a 2-week sprint with human developers can often be completed in 1-3 days with the SDD pipeline. The time savings come from: no context-switching, no coordination overhead, no waiting on dependencies between developers.

Key Takeaways

  • spec-tasks decomposes the design into ordered tasks with dependencies and requirement tracing
  • P0 tasks are sequential (block other work); P1 tasks can run in parallel
  • spec-impl implements specific tasks while reading requirements, design, and steering files
  • The three quality gates: validate-gap (before design), validate-design (before tasks), validate-impl (after code)
  • "Bolts not sprints" — intensive focused cycles replace ceremony-heavy sprint processes

Example

markdown
# tasks.md Example Structure

# Feature: User Profile Editing

## Task Breakdown

### Phase 1: Foundation
Task 1.1 [P0] — Create user_profiles database migration
  Depends: none | REQ-001, REQ-002

Task 1.2 [P0] — Create profile service with CRUD operations
  Depends: 1.1 | REQ-001, REQ-003

### Phase 2: API (parallel)
Task 2.1 [P1] — GET /profile/:userId endpoint
  Depends: 1.2 | REQ-002

Task 2.2 [P1] — PATCH /profile/:userId endpoint
  Depends: 1.2 | REQ-003, REQ-004, REQ-005

Task 2.3 [P1] — POST /profile/:userId/avatar (upload)
  Depends: 1.2 | REQ-006, REQ-007

### Phase 3: UI
Task 3.1 [P0] — ProfileView component
  Depends: 2.1 | REQ-002

Task 3.2 [P0] — ProfileEditForm component with validation
  Depends: 2.2 | REQ-003, REQ-004, REQ-005

Task 3.3 [P1] — AvatarUpload component with crop
  Depends: 2.3 | REQ-006, REQ-007

### Phase 4: Tests
Task 4.1 [P0] — Unit tests for profile service
  Depends: 1.2 | all REQs

Task 4.2 [P0] — Integration tests for API routes
  Depends: 2.1, 2.2, 2.3 | all REQs
Try it yourself — MARKDOWN