cc-sdd: Spec-Driven Implementation for Eight AI Coding Agents

The problem cc-sdd targets: specs that agents ignore

Most spec-driven development tooling produces a document the agent reads once and then drifts away from. cc-sdd takes the opposite position. The README states that it treats the spec as a contract between parts of the system, not a master command document handed to the agent, and that code remains the source of truth. Specs exist to make the boundaries between parts of the code explicit so humans and agents can work in parallel without constant synchronization.

The audience is therefore narrower than the tagline suggests. This is for teams already running an AI coding agent on real repositories, where more than one person or more than one agent touches the same code, and where the cost of an agent quietly changing a module's interface is higher than the cost of writing requirements down. A solo developer prototyping a weekend script gets very little from a phase-gated requirements and design pipeline. The project's own philosophy note is referenced in the README as covering when to use and when not to use it, which is a fair signal that the authors know the workflow does not fit every job.

One design decision is worth naming plainly: the spec is not the deliverable. Code ships. The spec is the artifact humans approve so that the code that ships does not surprise anyone.

How the 17 skills and /kiro-impl actually work

The mechanism is Agent Skills, loaded on demand. Each install ships 17 skills, and the README describes the loading model as progressive disclosure: the agent sees skill metadata and pulls in the full skill only when the task calls for it. There are no external dependencies, and subagents are spawned through each platform's native primitive rather than through a cc-sdd runtime. That is why the same skill set can ship to eight different agents.

The entry point in v3.0 is /kiro-discovery. The README says it routes new work into one of five outcomes: extend an existing spec, implement directly with no spec, create one new spec, decompose into multiple specs, or a mixed decomposition. It writes brief.md, and roadmap.md when the work is multi-spec, so a workstream can be resumed without re-explaining scope. That routing step is the part most spec tools skip, and it is the reason the command list is not simply a linear pipeline.

Implementation is where the architecture gets interesting. /kiro-impl gives each task a fresh implementer running TDD in RED then GREEN order behind a feature flag, an independent reviewer, and an auto-debug pass that investigates root causes in a clean context when the implementer is blocked or the reviewer rejects twice. It runs one task per iteration and the README states it is safe to re-run after interruption. Learnings from earlier tasks propagate forward through an Implementation Notes section in tasks.md.

The boundary discipline shows up in the artifacts. design.md includes a File Structure Plan that drives task boundaries, and tasks carry boundary and dependency annotations. Review and validation look for boundary violations, not just style issues. That is a concrete difference from tools whose review step is a lint pass with a model attached.

Installing cc-sdd and running a first spec

Installation is a single npx invocation run inside your project directory. The README's quick start gives exactly this:

cd your-project
npx cc-sdd@latest

The default installs Claude Code Skills with English docs. To choose another agent or language, the README gives these variants:

npx cc-sdd@latest --codex-skills --lang ja
npx cc-sdd@latest --cursor-skills --lang zh-TW

The project states it supports 8 AI coding agents and 13 languages. After install, you work from inside your agent rather than the shell. The README's photo albums example walks the full path:

/kiro-discovery Photo albums with upload, tagging, and sharing
/kiro-spec-init photo-albums
/kiro-spec-requirements photo-albums
/kiro-spec-design photo-albums
/kiro-spec-tasks photo-albums
/kiro-impl photo-albums

Discovery writes brief.md and suggests the next command, so you do not have to memorize the sequence. The README states the spec outputs typically take under 10 minutes and land as requirements.md in EARS format with acceptance criteria, design.md with Mermaid diagrams and a File Structure Plan, and tasks.md with boundaries and dependency annotations. Then /kiro-impl runs the tasks autonomously. If you are unsure which path applies, the README's advice is to start with kiro-discovery and let it tell you what to run next.

Where cc-sdd gets in your way

The workflow is phase-gated, and that is a cost, not a feature you can ignore. Requirements, design and tasks are separate commands with separate approvals. If you want an agent to take a paragraph of intent and start editing files, cc-sdd is the wrong tool and the README effectively says so by offering direct implementation with no spec as one of the discovery routes. Use that route, or use something else.

Platform stability is uneven. The README is explicit that Claude Code and Codex are stable while Cursor, Copilot, Windsurf, OpenCode, Gemini CLI and Antigravity are in beta. All eight ship the same 17-skill set, but the README frames the difference as how much real-world usage each platform integration has seen. If your team standardizes on a beta target, you are on the less-traveled path by the project's own description.

Legacy command modes still exist. The README lists /kiro:* command modes as available but deprecated, with Codex legacy mode marked blocked, and points to a migration guide for the upgrade path. Anyone arriving from a v1.x or v2.x setup has a migration step, not a drop-in replacement.

The dependency on each platform's native subagent primitive is a structural limitation. cc-sdd does not ship its own orchestrator, so the quality of per-task spawning and review isolation is bounded by what the host agent exposes. That is a deliberate trade for portability, but it means a platform change is not free.

cc-sdd vs GitHub Spec Kit and Kiro

The related searches around this project pair it with GitHub Spec Kit, and the comparison is real: both push a spec-first workflow into an AI coding agent. The difference is where the process lives. Spec Kit centers on a command set you run in a repository; cc-sdd ships as Agent Skills with progressive disclosure, one skill set installed per agent, and it routes through /kiro-discovery before anything is written. The multi-spec path is the sharper distinction: /kiro-spec-batch turns a roadmap into multiple specs in parallel with cross-spec review for contradictions, duplicated responsibilities and interface mismatches. A single-spec workflow has no equivalent step, because there is nothing to reconcile.

Kiro is the other reference point, and cc-sdd describes itself as Kiro-inspired, with the same spec-driven agentic SDLC style. The README states existing Kiro specs remain compatible and portable. The practical difference is the host: Kiro is an IDE, while cc-sdd installs into whichever of the eight supported agents you already use, which is what makes the same workflow available to a team that is not going to switch editors.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-05-20. The most recent release listed is v3.0.2 on 2026-04-13, following v3.0.1 and v3.0.0 earlier the same month. That is a v3 line that has been patched twice since the major rework, and the README documents a migration guide for anyone coming from v1.x or v2.x, including a specific section for v2.x to v3.0.

Upgrade cost is concentrated in the command names and the install flags. Legacy /kiro:* modes remain available but deprecated, and the README marks Codex legacy mode as blocked, so a v2-era setup that depended on legacy Codex commands has no legacy path forward. Plan for the skills-mode flags instead.

The licence is MIT, stated in the README badge and present as a LICENSE file at the repository root. MIT is permissive and imposes no copyleft obligation on your own code. That is the extent of what the repository supports saying here; it is not legal advice, and if your organization has specific requirements around attribution or redistribution, read the LICENSE file itself.

Editorial conclusion

Adopt cc-sdd if you already work in an agent that supports Agent Skills and you want the spec to be an approved contract rather than a prompt: Claude Code and Codex are the stable paths, and the 17-skill set installs with one npx command. Do not adopt it if you want the agent to read a design document and start editing files immediately, or if your team will not sit at the phase gates, because the workflow's value sits in that approval step. Before committing, verify three things in your own repository: that your agent's skills directory matches the variant you install, that /kiro-discovery routes your kind of request the way you expect, and that your platform is not one of the six beta integrations if you need the integration itself to be battle-tested.

Frequently asked questions

Official sources

1. gotalab/cc-sdd on GitHub
2. Issues
3. License: MIT
4. README
5. Releases