The SDD Pipeline

The Complete SDD Pipeline

The SDD pipeline is a sequence of slash commands, each producing a reviewable artifact and requiring human approval before the next stage begins:

steering → spec-init → spec-requirements → (validate-gap)
→ spec-design → (validate-design) → spec-tasks → spec-impl
→ (validate-impl)

Commands in parentheses are optional but recommended for brownfield projects.

Stage 1: Steering

Command: /kiro:steering

The first time you use cc-sdd on a project, run steering. The AI reads your entire codebase and generates steering files in .kiro/steering/ that capture: architecture decisions, technology stack, naming conventions, domain-specific rules, and recurring patterns.

After this stage, every subsequent command reads the steering files before generating output. The AI "knows" your project's conventions without you having to re-explain them.

Stage 2: Spec Init

Command: /kiro:spec-init [description]

You describe the feature you want to build in natural language. The AI creates a feature directory at .kiro/specs/[feature-name]/ with empty template files. No code is written yet — you are just naming and initializing the feature.

Stage 3: Requirements

Command: /kiro:spec-requirements [feature]

The AI generates structured requirements in EARS format (Easy Approach to Requirements Syntax) based on your description and your steering files. Output is saved to .kiro/specs/[feature]/requirements.md.

Human gate: You review and approve the requirements before design begins. This is your first quality checkpoint.

Stage 4: Validate Gap (optional)

Command: /kiro:validate-gap [feature]

For brownfield projects (adding to existing code), this command analyzes what already exists in your codebase vs what the requirements need. Produces a gap analysis report. Prevents duplicate implementation and identifies reusable components.

Stage 5: Design

Command: /kiro:spec-design [feature]

The AI generates the technical architecture: database schemas, API routes, component trees, integration points, and Mermaid diagrams. It references your steering files to follow your existing patterns and your requirements.md to satisfy every requirement.

Output: .kiro/specs/[feature]/design.md

Human gate: You review and approve the design before tasks are generated.

Stage 6: Validate Design (optional)

Command: /kiro:validate-design [feature]

Checks the proposed design against your existing codebase for conflicts: naming collisions, schema incompatibilities, API design inconsistencies, and pattern divergences.

Stage 7: Tasks

Command: /kiro:spec-tasks [feature]

The AI decomposes the design into ordered implementation tasks with:

• Task ID (e.g., 1.1, 1.2, 2.1)
• Description of what to implement
• Priority: P0 (must be sequential) or P1 (can run in parallel)
• Dependencies (which tasks must complete first)
• Requirement tracing (which REQ-xxx this satisfies)

Output: .kiro/specs/[feature]/tasks.md

Stage 8: Implementation

Command: /kiro:spec-impl [feature] [task-ids]

The AI implements the specified tasks: writes code, writes tests, validates against requirements, and checkpoints. You review the output at completion.

Example: /kiro:spec-impl user-profile 1.1,1.2

Stage 9: Validate Implementation (optional)

Command: /kiro:validate-impl [feature]

Verifies that the implementation matches the design document and satisfies all requirements. Produces a coverage report showing which requirements are implemented, which are partially implemented, and which are missing.

The .kiro/ File Structure

.kiro/
├── steering/
│   ├── architecture.md        # System layers and components
│   ├── tech-stack.md          # Languages, frameworks, tools
│   ├── naming-conventions.md  # File naming, variable naming
│   └── domain-rules.md        # Business logic, validation rules
├── specs/
│   └── user-profile/
│       ├── requirements.md    # EARS requirements (REQ-001 through REQ-N)
│       ├── design.md          # Schema, API routes, components
│       └── tasks.md           # Ordered implementation tasks
└── settings/
    ├── templates/             # Customizable output templates
    └── rules/                 # Domain-specific standards

Human Approval Gates

There are three mandatory human gates:

1. After requirements → validate the AI understood your intent
2. After design → validate the architecture before any code is written
3. After implementation → validate the code against requirements

These gates are the quality checkpoints that prevent AI from building the wrong thing confidently.

Key Takeaways

• The pipeline: steering → init → requirements → design → tasks → implementation
• Steering runs once per project to capture project memory in .kiro/steering/
• Each stage produces a reviewable artifact; humans approve before the next stage begins
• Validate-gap and validate-design are optional but critical for brownfield projects
• Requirements trace through design through tasks through code — full traceability