用途：为结构化功能开发实现 Spec-Driven Development（SDD）生命周期，覆盖 Intent（意图）、Requirements（需求）、Design（设计）、Tasks（任务）、Build（构建）。核心理念是清晰先于代码：需求与设计获批前不生成代码；通过 Req → Design → Tasks 迭代细化；事实依据在 markdown 文件中而非聊天记录。
主要能力：在项目根目录执行命令（spec/ 与 steering/ 所在处）。init 搭建 SDD 目录结构与模板文件，若 spec/ 已存在则跳过或询问后再覆盖，创建 spec/ 与 steering/，生成 spec/intent.md，并把技能 templates/ 目录（与 SKILL.md 同目录，或复制到 ~/.cursor/skills/sdd/ 后的安装路径）中的模板复制为 spec/requirements.md、spec/design.md、spec/tasks.md 及 steering/coding-standards.md。reqs 读取 spec/intent.md 与 steering/*.md，将意图转为 EARS 需求并加 Properties（不变量）章节，写入 spec/requirements.md，继续前请求用户批准。design 读取需求与 steering 文档，产出架构、数据模型、组件接口、错误处理、安全等技术设计并应用设计检查清单，写入 spec/design.md，继续前请求批准。tasks 读取设计，生成最多两级的顺序任务列表，每项链接需求 ID（如 REQ-001），写入 spec/tasks.md，继续前请求批准。status 列出 spec/（及可选 steering/）文件，若有 tasks.md 则统计未勾选 [ ] 与已勾选 [x] 并汇总。
EARS 模板：Ubiquitous 为 <system> shall <response>；Event-Driven 为 WHEN <trigger> [precondition] the <system> shall <response>；Unwanted 为 IF <unwanted condition> THEN the <system> shall <response>；State-Driven 为 WHILE <system state>, the <system> shall <response>；Optional 为 WHERE <feature is included>, the <system> shall <response>，使用 [REQ-001] 类 ID。设计检查清单要求精简去过度设计、检查循环依赖并通过接口抽取、分层或事件修复、确保与 steering 文档一致。任务规则要求最多两级、顺序执行、可追溯（如 Traceability: Implements REQ-001）。更完整框架细节见 reference.md。
适用场景：需要先明确需求与设计、再据文档生成代码的结构化功能开发。
限制：资料未提供收费、价格、平台支持范围与具体构建步骤等细节。