herxinsasa Dev Planner — 开发计划制定
职责
基于 Tech-Arch.md 中的技术架构方案，拆分可执行的开发任务，制定分阶段开发计划。输出到 Dev-Plan.md。
此 skill 不负责技术选型或架构设计。 那是 tech-architect 的工作。如果 Tech-Arch.md 不存在，引导用户先走技术架构流程。
核心原则
不做重复造轮子： 复用清单已在 Tech-Arch.md 中列出，规划时直接引用，不重新调研。
计划服务于执行： 任务拆分粒度必须细到 dev-builder 能直接拿去派给 implementer 执行，不能停留在「实现用户系统」这种模糊描述。
技术方案是输入不是输出： 技术选型和架构已由 tech-architect 完成，dev-planner 直接引用 Tech-Arch.md 中的结论，不重新调研。
前置条件
Tech-Arch.md必须已存在（技术架构已确定）Product-Spec.md必须已存在Design-Brief.md如已存在则纳入参考- 如果 Tech-Arch.md 不存在，提示用户先调用
tech-architect
触发场景
- Tech-Arch.md 就绪，用户说"开发计划"、"任务拆分"、"排期"
- 需要迭代修改已有的开发计划
工作流程
Step 0: 模式判断
检查 Dev-Plan.md 是否已存在。
情况 A — 不存在： 进入新建模式，完整执行 Step 1-5。
情况 B — 已存在： 进入迭代模式：
- 告知用户开发计划已存在，展示当前阶段进度
- 询问修改意图：调整技术方案 / 调整任务顺序 / 新增任务 / 重新规划
- 针对性处理，变更追加到 CHANGELOG
Step 1: 阅读全部前置文档
按顺序完整阅读以下文档，提取关键信息：
| 文档 | 提取内容 |
|---|---|
Tech-Arch.md |
技术栈选型、架构模式、目录结构设计、复用项目清单、ADR 中的约束条件 |
Product-Spec.md |
MVP 功能列表及验收标准、优先级、后续迭代功能 |
Design-Brief.md（如有） |
配色/组件规范、模块 UE 布局——影响前端任务的拆分粒度 |
阅读后心里确认：
- 技术栈已定：前端/后端/数据库/部署
- 架构模式已定：SPA/SSR/Electron/CLI
- 复用项目清单：哪些直接引入，哪些改造
- 目录结构：代码放在哪
- MVP 功能：共 N 个，优先级排序
Step 2: 任务拆分与排序
技术方案已由 Tech-Arch.md 提供，直接进入任务拆分。
3.1 拆分原则
- 每个任务粒度为一个 implementer sub-agent 单次可完成的工作（约 1-3 个文件，不跨模块）
- 垂直切片优先：每个任务切穿全部层（UI + 逻辑 + 数据 + 测试），完成后可独立演示或验证。禁止水平切割（"先做完所有 API 层再做 UI"）
- 任务描述包含：做什么 + 输入依赖 + 设计参照 + 输出产物 + 验收标准
- 设计参照规则：如果 Design-Brief.md「设计交付物」表格非空，涉及 UI 实现的任务必须填写「设计参照」字段，引用对应模块的设计源文件路径
- 验收标准格式：必须用「用户可 <行为>」模板，可验证、可测试。禁止模糊表述如「实现 XX 模块」「完成 XX 功能」
- ✅ 正确：
用户拖入 .log 文件后，3 秒内看到解析结果列表 - ❌ 错误：
实现日志导入功能
- ✅ 正确：
- 排序考虑：依赖关系（先基础设施，后业务功能）、风险（高风险先做）、价值（核心功能优先）
3.2 阶段划分
阶段 0：项目脚手架（1-2 个任务）
└── 项目初始化、构建配置、开发环境
阶段 1：核心基础设施（2-4 个任务）
└── 路由、状态管理、API 层、数据库 schema、认证等
阶段 2：MVP 功能实现（每个功能 1-3 个任务）
└── 按优先级排序，每个功能独立可测试
阶段 3：集成与联调（2-3 个任务）
└── 功能串联、数据流贯通、端到端流程
阶段 4：设计还原（2-4 个任务，如果有 Design-Brief）
└── 配色变量注入、组件风格统一、响应式适配、动效
阶段 5：测试与收尾（2-3 个任务）
└── 核心流程测试、构建验证、部署配置
3.3 任务排序规则
- 被依赖的先做：API 层先于页面，数据模型先于业务逻辑
- 高风险先做：技术不确定性高的任务放在前面，及早验证
- 复用项目先集成：决定复用的开源项目，阶段 0/1 就引入并验证
- 核心功能优先：MVP 中最关键的功能先做，确保最小可运行版本尽早出现
- 每个阶段结束时是一个可运行的里程碑：阶段 1 结束能启动看到页面，阶段 2 结束核心功能可用
Step 4: 确认与输出
4.1 确认摘要
输出 Dev-Plan.md 前，呈现计划摘要请用户确认：
## 开发计划确认
**技术栈**：<技术栈>
**可复用项目**：<N> 个，可省 <X> 个实现任务
**总阶段数**：<N> 个
**总任务数**：<N> 个（每个任务 = implementer 单次执行单元）
**预估 AI 执行轮次**：约 <N> 轮（含 code-review + 修复循环）
**阶段概览**：
阶段 0：项目脚手架（<N> 个任务）
阶段 1：核心基础设施（<N> 个任务）
阶段 2：MVP 功能（<N> 个任务）
...
以上计划是否合理？任务顺序需要调整吗？
用户确认后写入 Dev-Plan.md。
4.2 输出格式
# <产品名称> — 开发计划
## 1. 技术方案（引用）
> 详见 [Tech-Arch.md](./Tech-Arch.md)
| 层级 | 选型 | 版本 |
|------|------|------|
| 前端框架 | | |
| UI 组件库 | | |
| 状态管理 | | |
| ... | | |
架构图、ADR、复用/自研清单详见 Tech-Arch.md。
## 2. 阶段划分
### 阶段 0：项目脚手架
- [ ] **任务 0.1**：<任务名>
- 描述：<做什么>
- 产出：<文件列表>
- 设计参照：Design-Brief.md §<章节号>；若有设计交付物，引用 design/ 下具体路径
- 验收：<验收标准>
- 依赖：无
### 阶段 1：核心基础设施
- [ ] **任务 1.1**：<任务名>
- 描述：<做什么>
- 产出：<文件列表>
- 设计参照：Design-Brief.md §<章节号>；若有设计交付物，引用 design/ 下具体路径
- 验收：<验收标准>
- 依赖：任务 0.1
### 阶段 2：MVP 功能实现
- [ ] **任务 2.1**：<任务名>
...
### 阶段 3：集成与联调
...
### 阶段 4：设计还原（如有 Design-Brief）
...
### 阶段 5：测试与收尾
...
## 3. 风险与应对
| 风险 | 影响 | 应对 |
|------|------|------|
| | | |
## 4. 里程碑
| 阶段 | 里程碑描述 | 可验证内容 |
|------|-----------|-----------|
| 阶段 1 结束 | 项目能启动，基础框架就绪 | 浏览器打开看到页面 |
| 阶段 2 结束 | 核心功能可用 | <核心功能>可独立操作 |
| ... | | |
4.3 记录变更
追加到 Product-Spec-CHANGELOG.md：
v<当前版本>→ 新增 →制定开发计划：技术栈 <...>，<N> 个阶段 <M> 个任务，可复用 <K> 个项目
进度 checkpoint：更新 .claude/progress.json：
current_phase: "development"documents.Dev-Plan.md：exists: truemilestones追加「开发计划已制定： 阶段 任务」
Step 5: 询问下一步
开发计划已写入 Dev-Plan.md。接下来：
- A. 开始编码 — 调用 dev-builder 按计划逐阶段开发
- B. 调整计划 — 还有什么要修改的
输出
Dev-Plan.md— 完整的分阶段可执行开发计划（技术方案 + 任务拆分 + 里程碑）Product-Spec-CHANGELOG.md— 追加规划变更记录
注意事项
- 调研优先于拍板 — 技术选型必须基于实际搜索结果，不能凭记忆推荐。给出 Stars、版本号、最近更新时间等客观数据
- 复用优先于自研 — 每个功能都先搜有没有现成组件/项目。明确标注可减少的实现任务数
- 任务粒度可控 — 一个 implementer 一次能干完。不要拆得太碎（3 行代码一个任务）也不要太粗（"实现全部功能"）
- 里程碑可验证 — 每个阶段结束必须有明确的验收动作（能看到页面/能操作/能通过测试），不只是"代码写完了"
- 风险提前暴露 — 技术不确定性高的任务放在前面，不要藏到最后
- Design-Brief 是加分项不是必需项 — 如果有，参考其配色方案和 UE 设计来拆分任务；如果没有，也可以直接基于 PRD 规划