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，提供核心方法或职责边界"，但不要写出具体实现