dev-planner

name	dev-planner
description	制定开发计划。阅读前置文档 + 调研技术方案 + 复用开源项目，输出分阶段可执行的 Dev-Plan.md。

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 — 已存在： 进入迭代模式：

1. 告知用户开发计划已存在，展示当前阶段进度
2. 询问修改意图：调整技术方案 / 调整任务顺序 / 新增任务 / 重新规划
3. 针对性处理，变更追加到 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 任务排序规则

1. 被依赖的先做：API 层先于页面，数据模型先于业务逻辑
2. 高风险先做：技术不确定性高的任务放在前面，及早验证
3. 复用项目先集成：决定复用的开源项目，阶段 0/1 就引入并验证
4. 核心功能优先：MVP 中最关键的功能先做，确保最小可运行版本尽早出现
5. 每个阶段结束时是一个可运行的里程碑：阶段 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: true
• milestones 追加「开发计划已制定： 阶段 任务」

---

Step 5: 询问下一步

开发计划已写入 Dev-Plan.md。接下来：

• A. 开始编码 — 调用 dev-builder 按计划逐阶段开发
• B. 调整计划 — 还有什么要修改的

输出

• Dev-Plan.md — 完整的分阶段可执行开发计划（技术方案 + 任务拆分 + 里程碑）
• Product-Spec-CHANGELOG.md — 追加规划变更记录

注意事项

• 调研优先于拍板 — 技术选型必须基于实际搜索结果，不能凭记忆推荐。给出 Stars、版本号、最近更新时间等客观数据
• 复用优先于自研 — 每个功能都先搜有没有现成组件/项目。明确标注可减少的实现任务数
• 任务粒度可控 — 一个 implementer 一次能干完。不要拆得太碎（3 行代码一个任务）也不要太粗（"实现全部功能"）
• 里程碑可验证 — 每个阶段结束必须有明确的验收动作（能看到页面/能操作/能通过测试），不只是"代码写完了"
• 风险提前暴露 — 技术不确定性高的任务放在前面，不要藏到最后
• Design-Brief 是加分项不是必需项 — 如果有，参考其配色方案和 UE 设计来拆分任务；如果没有，也可以直接基于 PRD 规划