---
name: dev-plan
description: 开发流程 - 步骤分解阶段，将设计拆解为可验证的实施步骤
---

# 步骤分解

> 开发流程第三阶段：将设计拆解为可验证的实施步骤，每步提供验收标准。

## 调用方式

`/dev-plan`，也可说"分解步骤"或"制定开发计划"。

## 产出目录

`docs/plans/`

## 执行流程

### Checklist

- [ ] 前置检查：读取需求和设计文档
- [ ] 分析设计，识别实现步骤
- [ ] 定义每个步骤的验收标准
- [ ] 展示完整步骤列表
- [ ] 用户确认并保存

### 1. 前置检查

- 读取 `docs/requirements/` 和 `docs/design/`
- 如果任一目录为空，提示用户先完成对应阶段（可选择跳过）
- 展示需求和设计摘要，确认分解范围

### 2. 分析设计，识别步骤

基于设计文档的模块划分和架构，将实现工作拆解为步骤。

**拆解原则：**
- 每个步骤必须**可独立验证**
- 步骤粒度：一个步骤应能在一次开发会话中完成
- 优先按依赖关系排序：基础模块先于上层模块
- 同一模块的相关任务归为同一步骤

### 3. 定义验收标准

为每个步骤定义验收标准。

**验收标准要求：**
- **可客观判断**：能通过命令执行、文件检查或视觉确认
- **具体明确**：不使用"基本完成"、"大致可用"等模糊描述
- **可演示**：每个步骤完成后都能展示具体成果

**好的验收标准示例：**
```
- [ ] 执行 `npm run build` 无错误
- [ ] 访问 /api/users 返回 200 和用户列表 JSON
- [ ] 用户可以点击"添加"按钮并在列表中看到新条目
```

**不好的验收标准示例：**
```
- [ ] 基本功能可用
- [ ] 接口设计完成
```

### 4. 展示步骤列表

按以下格式展示完整计划：

```markdown
# 实施计划：<项目名称>

> 创建日期：YYYY-MM-DD
> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md
> 对应设计：docs/design/YYYY-MM-DD-xxx.md
> 状态：待执行

## 步骤概览

| # | 步骤名称 | 依赖 | 状态 |
|---|---------|------|------|
| 1 | xxx     | 无   | 待执行 |

---

## 步骤 N：<标题>

**目标**：一句话描述

**具体任务**：
- [ ] 任务项 1
- [ ] 任务项 2

**验收标准**：
- [ ] 标准 1（可验证描述）
- [ ] 标准 2

**涉及文件**：
- src/xxx.ts（新建/修改）

**预估复杂度**：低/中/高

---

## 依赖关系图

步骤 1 → 步骤 2, 3 → 步骤 4
```

### 5. 用户确认

- 展示完整步骤列表
- 询问是否需要调整（合并、拆分、重排序）
- 修改后循环展示直到用户确认
- 保存为 `docs/plans/YYYY-MM-DD-<项目名>.md`
- 提示下一步可调用 `/dev-develop` 开始开发

## 关键行为

- 验收标准是步骤分解的核心，必须可验证
- 步骤之间依赖关系必须明确，无循环依赖
- 不遗漏设计文档中的任何模块或接口
- 步骤数量适中（通常 3-10 个），避免过度拆分