| 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 未完成
- 验证失败 → 展示错误 + 修复建议，等用户确认
- 用户说"跳过" → 标记跳过，继续下一个
