cc-sdd: Spec-Driven Development as Agent Skills

Most "spec-driven development" tooling requires you to adopt a heavyweight framework, a stateful CLI, or a hosted service. gotalab/cc-sdd skips all of that — a single npx command installs an SDLC workflow as Agent Skills on your coding agent, with explicit phases you walk through one at a time.

Why This Skill Matters

The workflow is six phases: kiro-discovery → kiro-spec-init → kiro-spec-requirements → kiro-spec-design → kiro-spec-tasks → kiro-impl. Each phase produces a documented artefact (brief.md from discovery, then spec files for requirements / design / tasks), and kiro-impl runs autonomous implementation with per-task independent review.

The tool is explicitly framework-agnostic — it installs as skills rather than tying to a specific framework. The philosophy in the README is "boundaries are not overhead; they are what lets you move freely inside while protecting the outside." Existing Kiro specs remain compatible and portable.

Compatibility: Claude Code and Codex are stable; Cursor, Copilot, Windsurf, OpenCode, Gemini CLI, and Antigravity are marked Beta. Legacy command modes (--claude, --cursor, etc.) are deprecated and --codex is blocked. License is MIT.

Installation

One command installs the full skill set into your supported agent:

npx cc-sdd@latest

Follow the prompts to pick the target agent. After install, the kiro-* slash commands become available.

Real Workflow: Build a Photo-Album Feature From a One-Line Intent

You want to add a photo-album feature with upload, tagging, and sharing. You do not have a spec, so the workflow starts from discovery.

Step 1. In your agent, run discovery:

/kiro-discovery Photo albums with upload, tagging, and sharing

The skill writes brief.md capturing the scope, constraints, and a high-level shape. If the project warrants multiple specs, it also writes roadmap.md and points you to the next command.

Step 2. Initialize the spec:

/kiro-spec-init Photo albums v1

The skill creates a spec directory and seeds metadata.

Step 3. Walk through requirements, design, and tasks:

/kiro-spec-requirements
/kiro-spec-design
/kiro-spec-tasks

Each phase produces a versioned artefact in the spec directory. Review each before moving to the next; the skills do not auto-progress.

Step 4. Run implementation:

/kiro-impl

kiro-impl reads the tasks file and runs autonomous implementation with per-task independent review. Each task gets its own review pass, not a single end-of-run review.

Step 5. After implementation, review the diff. If a task produced something you want changed, you can re-run individual phases (for example, edit the tasks file, then re-run kiro-impl).

Real Workflow: Extend an Existing System With the Skill Workflow

You already have a system in production and want to add a feature to it. The workflow has an entry point for that path.

Step 1. Start by giving the workflow your existing project's conventions:

/kiro-steering

The steering phase captures your project's existing architectural decisions, libraries, and conventions so later phases use them instead of guessing.

Step 2. Discover the new feature:

/kiro-discovery Add a bulk-import path that accepts a CSV and creates draft items per row

Step 3. If you are working on an existing codebase with its own partial spec, validate the gap before designing:

/kiro-validate-gap

The skill compares the existing code and any partial spec to the new intent and surfaces the delta you need to address.

Step 4. Walk through design and tasks as in the greenfield workflow, then implement. The steering context carries your project's conventions into the new spec.

Step 5. After implementation, the new feature integrates with the existing architecture because the steering phase fed it the conventions up front.

Tips

• Use kiro-steering whenever you extend an existing system; skipping it makes later phases guess at conventions.
• Treat each phase as a checkpoint — do not skip ahead. The per-phase artefacts are what kiro-impl reads.
• For Claude Code and Codex, the install is stable; for Cursor / Windsurf / OpenCode / Gemini CLI / Antigravity, expect some edge cases.
• Avoid the legacy command modes (--claude, --cursor, --codex) — --codex is blocked and the others are deprecated.
• The kiro-impl review is per-task, not per-batch — re-running on the same tasks produces a fresh review each time.

When Not to Use This

If the change is small enough to skip spec-driven process — a one-file refactor or a single test addition — the six-phase workflow is overhead. Reserve cc-sdd for features with multiple tasks, architectural decisions, or audit needs. Also, if your agent is not Claude Code or Codex, weigh the Beta status: the README explicitly says "edge cases may still surface" for the other supported agents.

See the leaderboard for more spec-driven workflows.