Plan - 实施计划技能
将已确认的 spec 文档转化为可执行落地的详细实施计划与任务清单。
核心原则
- 不猜测：代码侧的技术细节遇到不确定的，必须向用户澄清
- 不模糊：每个 TODO 子项必须描述清楚做什么、影响哪些文件、验收标准是什么
- 不写代码：不写详细实现代码，但可以描述接口签名、数据结构、模块职责
- 固定产出：输出到项目既有的需求目录；若无统一约定，建议使用
spec/<spec-name>/plan.md
前置条件
- 对应功能的
spec.md必须已存在且状态为"已确认" - 如果项目有统一文档目录，遵循现有约定；如果没有，建议使用
spec/<spec-name>/spec.md - 如果 spec 不存在，提示用户先执行
/spec
工作流程
第一步：阅读上下文
- 阅读对应功能的
spec.md - 阅读项目级背景文档（如 PRD、roadmap、里程碑文档；如果存在）
- 阅读现有代码结构，理解当前架构、模块划分、命名规范
- 阅读已有的其他 plan，理解整体技术方向一致性
第二步：技术澄清
- 识别 spec 中在代码层面仍有歧义的点
- 使用当前环境可用的提问方式向用户澄清技术选型、方案偏好
- 反复澄清直到所有技术决策确定
第三步：撰写 Plan
按照下方固定模板撰写，写入对应功能的 plan.md。
第四步：用户确认
将产出交给用户确认，根据反馈修订直到用户满意。
固定模板
# <功能名称> 实施计划
> 关联 Spec：<spec 文档路径>
> 创建日期：YYYY-MM-DD
> 状态：草稿 | 已确认
## 1. 技术方案概述
用 1-3 段话概述整体技术实现思路。
## 2. 技术决策
### 2.1 方案选型
如有多种实现方案，列出各方案的优劣对比，并标注最终选择及理由。
### 2.2 外部依赖
列出需要引入的第三方库、服务、SDK、引擎能力或工具。
### 2.3 内部依赖
列出依赖的内部模块、已有接口、资源或数据结构。
## 3. 任务拆解
### 3.1 核心逻辑 / Runtime / 运行时模块（按项目实际情况命名）
- [ ] **TODO-S1: <任务标题>**
- **描述**：详细说明要做什么
- **涉及模块**：对应子系统、运行时模块或核心逻辑层
- **涉及文件**：预估需要新建或修改的文件路径
- **依赖**：依赖哪些前置 TODO（如 TODO-S0）
- **验收标准**：完成后如何验证
- [ ] **TODO-S2: ...**
### 3.2 表现层 / Tooling / 工具模块（按项目实际情况命名）
- [ ] **TODO-C1: <任务标题>**
- **描述**：详细说明要做什么
- **涉及模块**：对应 UI 层、编辑器工具、页面、交互模块或辅助工具模块
- **涉及文件**：预估需要新建或修改的文件路径
- **依赖**：依赖哪些前置 TODO
- **验收标准**：完成后如何验证
- [ ] **TODO-C2: ...**
### 3.3 共享 / 通用模块
- [ ] **TODO-G1: <任务标题>**
- **描述**：类型定义、工具函数、配置、共享资源等通用部分
- **涉及文件**：...
- **依赖**：...
- **验收标准**：...
## 4. 依赖关系与执行顺序
用文字或 ASCII 图描述 TODO 之间的依赖关系，标明哪些可以并行。
示例：
- TODO-G1 → TODO-S1（G1 完成后 S1 才能开始）
- TODO-S2 ‖ TODO-C1（可并行）
## 5. 测试标准
### 5.1 单元测试标准
逐条列出每个 TODO 需要的单元测试覆盖点。
### 5.2 集成 / 场景验证标准
描述完整流程的集成测试或场景验证，包括：
- 前置条件
- 操作步骤
- 期望结果
- 异常场景
## 6. 风险与缓解
| 风险 | 影响 | 缓解措施 |
|------|------|---------|
## 7. 开放问题
列出所有尚未解决的技术问题。如全部已解决则标注"无"。关键约束
- TODO 颗粒度：每个 TODO 应该是一个开发者能在 1-4 小时内完成的工作单元
- 并行友好：不同层次或模块的 TODO 应尽量解耦，方便并行开发
- 测试先行：每个 TODO 必须附带验收标准，测试标准章节必须完整
- 不写实现代码：可以描述"创建一个 XxxManager / System / Service，提供核心方法或职责边界"，但不要写出具体实现