# Dev Planner

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

- Skill: `herxinsasa/dev-planner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add herxinsasa/dev-planner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/herxinsasa/dev-planner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: herxinsasa (https://skillmd.com/u/herxinsasa)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/herxinsasa/dev-planner

---


# 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 输出格式

```markdown
# <产品名称> — 开发计划

## 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` 追加「开发计划已制定：<N> 阶段 <M> 任务」

---

### Step 5: 询问下一步

> 开发计划已写入 Dev-Plan.md。接下来：
> - **A. 开始编码** — 调用 dev-builder 按计划逐阶段开发
> - **B. 调整计划** — 还有什么要修改的

## 输出

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

## 注意事项

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