cc-sdd：把"规格驱动开发"装进 Agent Skills

多数"spec-driven development"工具都要你接一套重量级框架、一个有状态的 CLI、或者一项托管服务。gotalab/cc-sdd 都不需要——一条 npx 命令把整套 SDLC 流程作为 Agent Skills 装到你的编程 agent 上，明确分阶段、一个阶段一个阶段地走。

为什么这个 skill 重要

工作流是六个阶段：kiro-discovery → kiro-spec-init → kiro-spec-requirements → kiro-spec-design → kiro-spec-tasks → kiro-impl。每个阶段产出一个文档化的产物（discovery 阶段产出 brief.md，之后是需求/设计/任务的 spec 文件），kiro-impl 做自治实现，并对每个任务独立评审。

工具明确不绑框架——它以 skill 形式装，不锁定任何特定框架。README 的理念是"边界不是负担；边界是让你在内自由、在外受保护的前提"。已有的 Kiro 规格保持兼容、可迁移。

兼容性：Claude Code 与 Codex 是 stable；Cursor、Copilot、Windsurf、OpenCode、Gemini CLI、Antigravity 标为 Beta。老的命令模式（--claude、--cursor 等）已废弃，--codex 模式被阻断。License 是 MIT。

安装

一条命令把全套 skill 装进你的支持 agent：

npx cc-sdd@latest

按指示选目标 agent。装好后 kiro-* slash 命令即可用。

真实工作流：从一行意图搭一个相册特性

你要做一个"相册"特性，支持上传、打标签、分享。手上没有规格，工作流从发现开始。

第一步。在 agent 里跑发现：

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

skill 写出 brief.md，记下范围、约束和高层的形态。如果项目需要拆多个 spec，它还会写 roadmap.md，并指向下一条命令。

第二步。初始化规格：

/kiro-spec-init Photo albums v1

skill 建出 spec 目录，填好元数据。

第三步。走过需求、设计、任务三阶段：

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

每个阶段在 spec 目录里产出一个带版本的产物。每个阶段审完再走下一个；skill 不会自动跳。

第四步。跑实现：

/kiro-impl

kiro-impl 读任务文件，做自治实现，并对每个任务独立评审。每个任务有自己的评审，不是最后一次性评审。

第五步。实现完，review diff。如果某个任务你想调整，改 tasks 文件，然后重跑 kiro-impl。

真实工作流：用 skill 工作流扩展已有系统

你已经有一个生产系统，想往里面加一个特性。工作流有专门为这条路径准备的入口。

第一步。先把你的项目约定喂给工作流：

/kiro-steering

steering 阶段捕捉项目已有的架构决策、库选型、约定，之后的阶段就会用它们，不会瞎猜。

第二步。发现新特性：

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

第三步。如果在已有 codebase 上做，项目里可能已有部分 spec，先验证差距：

/kiro-validate-gap

skill 把已有代码与部分 spec 跟新意图对比，把需要补的 delta 摆出来。

第四步。和 greenfield 工作流一样过设计与任务，再实现。steering 的上下文把项目约定带进新 spec。

第五步。实现完之后，新特性自然集成进已有架构，因为 steering 阶段一开头就把约定喂进来了。

技巧

• 在已有系统上加特性就用 kiro-steering；跳过它会让之后的阶段去猜约定。
• 把每个阶段当作 checkpoint——不要跳。每阶段的产物是 kiro-impl 读的输入。
• Claude Code 与 Codex 上是 stable；在 Cursor / Windsurf / OpenCode / Gemini CLI / Antigravity 上要预期一些边界情况。
• 避开老的命令模式（--claude、--cursor、--codex）——--codex 已被阻断，其他都已废弃。
• kiro-impl 的评审是 per-task，不是 per-batch——重跑同一组任务，每次都会重新评审。

何时不要用

如果改动小到可以跳过规格驱动流程——单个文件的重构或者一条测试添加——六阶段流程就是开销。把 cc-sdd 留给"多任务、有架构决策、要审计"的特性。同时，如果你的 agent 不是 Claude Code 或 Codex，要权衡 Beta 状态：README 明确说"edge cases may still surface"。

在 leaderboard 查看更多规格驱动工作流。