---
name: dev-task-planning
description: "开发规划师使用：把需求、架构、界面设计和原型拆解为独立可验证的开发任务。"
---

# 开发任务规划角色技能

服务于本工作室的开发规划师角色。

## 输入

- `docs/prd.md`
- `docs/tech-architecture.md`
- `docs/ui-design.md`
- `prototype/`

如果任务拆解发现环境、脚手架、框架版本、模块边界、接口、页面路径、验收标准、测试策略或技术约束缺口，必须同步回写对应上游文档，并在 `docs/workflow-state.json` 的 `notes` 记录同步说明；不要只在 `docs/dev-tasks.md` 中静默新增需求。阶段结束前必须在 `docs/dev-tasks.md` 填写 `## 文档同步检查`，至少引用 `docs/prd.md`、`docs/tech-architecture.md`、`docs/ui-design.md`。

## 输出

- `docs/dev-tasks.md`

## 任务拆解原则

1. `docs/dev-tasks.md` 是单文件 Kiro 风格实施计划，不新增 `docs/dev-tasks/` 目录，不引入 OpenSpec change 目录。
2. 使用 `- [ ] 1. 任务名` 形式生成连续编号任务，任务完成后可直接勾选。
3. 每个编号任务必须是最小可执行粒度，只处理一个清晰目标，通常对应 1 个文件、1 个类/组件、1 个方法、1 条接口或 1 组紧密相关的小文件。
4. 每个任务下保留 3-6 条具体动作，不写长篇任务卡；动作必须能直接指导开发。
5. 每个任务最后必须包含测试/验收动作，完成该动作后才能进入下一个编号任务。
6. 每个任务必须用 `_需求: Mx-Fx, ..._` 追溯 PRD 功能编号；工程准备任务可写 `_需求: 工程准备_`。
7. 环境配置、项目骨架、依赖、测试框架、模块数据结构、数据访问、业务逻辑、接口/页面入口、回归测试都要拆成独立编号任务。
8. 实施计划开始前必须锁定技术基线：语言版本、框架版本、包管理器、脚手架创建命令、依赖安装命令、启动命令和测试命令。
9. 如果上游没有明确包管理器、版本或脚手架方式，必须列为阻塞确认项，不得自行默认；例如不得把用户要求的 `uv` 改成 `requirements.txt`，不得绕过 Next.js 官方脚手架手写项目骨架。
10. 任务中发现的上游缺口必须回写上游文档，不能只在任务里新增范围。
11. 文档同步检查必须覆盖技术基线、环境、脚手架、模块任务、接口、测试策略和验收标准；计划阶段修正前文时必须列出回写文档。

## 检查表

- 是否覆盖所有 P0 功能。
- 是否采用 Kiro checklist 形式，并且每个编号任务都有 3-6 条具体动作。
- 是否每个任务都有 `_需求: ..._` 追溯。
- 是否每个任务都有测试/验收动作，并要求通过后才能继续。
- 是否明确语言/框架版本、包管理器、依赖文件形态、脚手架命令、安装/启动/测试命令。
- 是否禁止未确认的包管理器、依赖文件和手工脚手架方案。
- 是否避免“实现完整模块、完成全部接口、搭建整个项目、创建所有测试”这种过粗任务。
- 是否没有 `待补充`、`TODO`、`类似上一步`、`写相关测试`、`处理边界情况` 等空泛语句。
- 是否完成 `## 文档同步检查`，并能追溯 PRD、架构、UI 来源文档。
