implementation-planning

name	implementation-planning
description	实施计划技能。当用户要求根据 spec 制定实施计划、拆分任务、评估改动范围时使用。适用于执行 spec-plan 命令时触发，或用户要求"做个实现计划""拆下任务"时使用。

实施计划

将已分析的 spec 转化为可执行的实施计划，包括改动范围、步骤、依赖关系和风险评估。

执行步骤

1. 理解现有代码结构（调用 codebase-survey deep 模式）
   • 调用 skills/codebase-survey/SKILL.md，传入参数 mode: deep
   • 侦察报告输出包含：
     • 改动文件清单（精确到文件 + 关联 FR）
     • 调用链分析
     • 接口影响
     • 已有设计模式（必须遵循）
     • 影响范围风险
   • 侦察结果将合并到 plan 的：
     • 「改动范围」 章节
     • 「关键代码参考」 章节
     • 「实施步骤」 中每个 Step 的「参考代码」字段
   • 如果 spec 已有「关键代码参考」（来自阶段零的 light 侦察），deep 侦察应扩展而非重做
2. 映射需求到代码变更
   • 每个功能需求（FR）对应哪些文件的新增或修改
   • 识别共享的基础变更（如新数据结构被多个 FR 依赖）
   • 确定是否需要新增文件/目录
3. 确定实施顺序
   • 根据依赖关系排列步骤顺序
   • 基础设施优先（数据结构、接口定义）
   • 核心逻辑其次，辅助功能最后
4. 评估风险
   • 识别对现有代码的影响范围
   • 标注可能影响其他模块的接口变更
   • 列出不确定的技术决策
5. 输出计划

输出格式

### Implementation Plan: [Story ID]

**改动范围**：
| 操作 | 文件 | 说明 |
|------|------|------|
| 新增 | [路径] | [做什么] |
| 修改 | [路径] | [改什么] |

**实施步骤**：

**Step 1**: [描述]
- 文件：[涉及的文件]
- 原因：[为什么先做这步]
- 详情：[具体做什么]

**Step 2**: [描述]
...

**依赖关系**：
- Step 2 依赖 Step 1 的 [具体产物]

**风险**：
- [风险描述和应对方式]

**待确认**：
- [需要人确认的决策点]

**预估复杂度**：低 / 中 / 高

注意事项

• Plan 不是代码，不要在 plan 中写具体实现
• 改动范围不能超出 spec 范围
• 大 spec 建议拆分为多个可独立实施的阶段
• 每个步骤应小到可以一次完成并验证