| name | sdd-implement |
| description | 按规格文档的 Ticket 逐个实现代码,每个 Ticket 独立上下文避免幻觉。内置 todo 进度追踪,支持 LSP 诊断、worktree 隔离、子智能体委派等按需升级。Use when user says "implement ticket", "实现这个任务", "sdd implement", "开始实现", or wants to execute tasks from a spec. Reads .plan/spec.md for task breakdown. |
| argument-hint | Ticket number or 'all' to implement sequentially |
| disable-model-invocation | true |
SDD Implement — 按 Ticket 独立实现
按 .plan/spec.md 的任务拆解,逐个 Ticket 实现代码。
第一原则:复用优先
实现任何 Ticket 之前,先回答三个问题:
- 项目里有没有已经解决过类似问题的代码? — grep 搜索关键词、函数名、模式
- 现有的工具/组件/服务能不能组合出我要的功能? — 读 spec 中的复用清单,找相似实现
- 如果要新建,是真的没有,还是我没找到? — 多搜一层再决定写新代码
判断顺序:直接调用 > 组合适配 > 参考模式 > 新建。
常见反模式(禁止):
- 项目已有
formatDate 工具函数,Ticket 里再写一个
- 已有分页组件,换个模块又从零实现一套
- 已有错误处理中间件,新接口自己 try-catch 一套不同风格的
- 已有配置加载逻辑,新模块又写一份
实现要点:每个 Ticket 完成后报告中必须注明「复用情况」——用了什么现有代码、或为什么确认没有可复用的。
输入
.plan/spec.md — 必须存在,否则提示先运行 /sdd-spec
- 用户指定 Ticket 编号 — 实现特定 Ticket 或全部
工作流程
第 0 步:读取规格并初始化进度
读取 .plan/spec.md,解析任务列表,用 todo_write 建立进度追踪:
找到 N 个 Ticket:
1. <任务名> [依赖: 无]
2. <任务名> [依赖: Ticket 1]
...
将所有 Ticket 写入 todo 列表(全部 pending),第一个设为 in_progress。
第 1 步:实现单个 Ticket
1.1 上下文准备
- 读取 Ticket 的目标、涉及文件、实现要点
- 读取依赖的前序 Ticket 产出物
- 读取需修改的现有文件(只读建上下文)
- 不加载无关文件
1.2 实现
- 先查复用清单和代码库,找到可复用的现有代码后优先使用
- 按 Ticket 实现要点编写代码,只新建确实不存在的部分
- 遵循项目现有代码风格
- 不做 Ticket 要求之外的"改进"
1.3 验证
- 运行 Ticket 指定的验收方式
- 有测试框架则编写/运行测试
- 有 linter/type checker 则运行
1.4 对齐检查
- 回读 spec.md 中该 Ticket 的描述
- 确认实现与规格一致,无遗漏
- 发现不一致时停下来和用户讨论,不自行改规格
1.5 发现记录
- 实现中发现的新事实、矛盾、风险,追加到 spec.md 的「决策日志」表
- 格式:
| D-N | <发现> | <原因> | <日期> |
- 无新发现则跳过
1.6 更新进度
todo_write:当前 Ticket 标记 completed,下一个设为 in_progress
报告:
✅ Ticket N: <任务名> — 完成
变更文件:...
复用情况:<调用了哪些现有代码,或"无复用对象,新建">
验证结果:...
下一个:Ticket N+1
第 2 步:循环或结束
- "all" 按依赖顺序依次实现,每个 Ticket 完成后暂停等确认
- 失败则停下来报告,不跳过
第 3 步:全部完成
🎉 所有 Ticket 实现完成。
总计:N 个 Ticket,M 个文件变更
建议:运行完整测试套件确认无回归
可选:用 /handoff 保存上下文
复杂度升级(按需,不默认触发)
每个升级都有明确的触发信号和收益判断——不是"能用就用",而是"不用会出问题才用"。
升级 1:LSP 诊断
触发信号:修改了公共接口、类型复杂的代码、用户反馈类型错误
动作:Ticket 完成后调 lsp diagnostics 检查当前文件
收益:在运行测试前捕获类型错误
不触发:纯脚本、配置文件、文档变更
升级 2:Worktree 隔离
触发信号:Ticket 涉及破坏性变更(改接口签名、重构核心模块)、或用户要求并行实现多个 Ticket
动作:enter_worktree 创建隔离分支,在 worktree 中实现,完成后展示 diff
收益:失败不影响主分支,可安全回滚
不触发:常规功能开发、小改动
升级 3:子智能体委派
触发信号:Ticket 独立性很强(无上下文依赖)、且实现复杂度高(>100 行、涉及多文件)
动作:派发「后端架构师」或对应专业子智能体,在子会话中独立完成
收益:隔离上下文,主会话不被污染,可并行
不触发:Ticket 依赖前序上下文、简单改动、需要频繁和用户确认的场景
升级 4:后台监控
触发信号:测试运行时间 >30 秒、需要同时跑 dev server 和测试
动作:run_shell_command 以 is_background: true 运行长任务
收益:不阻塞主流程
不触发:快速测试(<10s)
升级 5:代码审查
触发信号:所有 Ticket 完成后、或用户要求 review
动作:派发「代码审查员」子智能体审查变更
收益:捕获实现阶段遗漏的问题
不触发:用户明确说不需要 review
关键约束
- 复用优先 — 能用现有代码解决的不新建,组合现有能力优于造新轮子
- 一个 Ticket 一个上下文 — 不提前考虑后续 Ticket
- 不改需求 — 发现规格问题停下讨论
- 不加戏 — 不做范围外的重构/优化
- 依赖先行 — 有依赖的 Ticket 必须等前置完成
- 失败即停 — 验证失败报告问题,不强行继续
异常处理
- spec.md 不存在 → 提示先运行
/sdd-spec
- Ticket 依赖的文件不存在 → 提示检查规格,可能前置 Ticket 未完成
- 验证失败 → 展示错误 + 修复建议,等用户确认
- 用户说"跳过" → 标记跳过,继续下一个