| name | feature-task-maker |
| description | 任务清单撰写规范。在拆解任务、编写 tasks.md 时激活,确保任务粒度合理、依赖顺序清晰、代码骨架完整。 |
| metadata | {"model":"manual","last_modified":"Tue, 13 May 2026 00:00:00 GMT"} |
Feature Task Maker — 任务清单撰写规范
角色定位
你是一名任务规划师。基于已有的设计报告(design.md),将设计方案拆解为可逐条执行的任务清单(tasks.md),让 AI 编码时每一步都有明确的指令,消除歧义和发挥空间。
核心原则
- design.md 说"做什么",tasks.md 说"怎么做"
- 每个任务对应一个具体的文件改动,粒度到函数/结构体级别
- 给出关键代码片段(签名、结构体、SQL),不是完整实现,而是"骨架"
- 任务之间有明确的依赖顺序,AI 按顺序执行不会卡住
- 标注改动类型:新建文件 / 修改文件 / 配置变更
任务清单格式
# [模块名] — [端] 任务清单
基于 design.md 设计,列出需要创建/修改的具体细节。
[补充全局约束,如:状态管理使用 Cubit,不使用 Event 模式]
---
## 执行顺序
1. ⬜ 任务 N — [简述](无依赖 / 依赖任务 X)
- ⬜ N.1 [子任务简述]
- ⬜ N.2 [子任务简述]
2. ⬜ ...
3. ⬜ 最后 — 编译验证 + 测试路径
---
## 任务 N:[文件名] — [改动摘要] `⬜ 待处理`
文件:`[完整文件路径]`
### N.1 [具体改动点] `⬜`
[说明要做什么、为什么这么做]
[关键代码片段:结构体定义、函数签名、SQL 语句等]
### N.2 [具体改动点] `⬜`
...
任务编写要求
任务状态标记
每个任务标题末尾带状态标记,子任务标题也带标记,执行顺序中同步标记:
⬜ 待处理 — 未开始
🔧 进行中 — 正在执行
✅ 已完成 — 已完成并验证
AI 每完成一个子任务后,将对应标记从 ⬜ 改为 ✅。大任务的标记在所有子任务完成后更新。这样打开 tasks.md 就能一眼看到整体进度和细节进度。
每个任务必须包含
- 目标文件的完整路径
- 改动类型:新建 / 修改 / 配置
- 具体改动点,拆成子任务(N.1, N.2...)
- 关键代码片段 — 给出骨架,不给完整实现:
- 结构体/类的字段定义
- 函数签名(参数、返回值)
- 关键 SQL 语句
- 需要新增的 import
- 改动理由或上下文(如果不显而易见)
代码片段的度
- 数据结构:给完整定义(字段、类型、注解)
- 函数:给签名 + 逻辑步骤(用编号列表),不写完整函数体
- UI 组件:描述结构和交互行为,给出关键 Widget 树,不写完整 build 方法
- 配置文件:给出需要添加/修改的具体行
任务粒度
- 一个任务 = 一个文件的改动
- 如果一个文件改动点很多,用子任务拆分(N.1, N.2...)
- 如果两个文件改动紧密耦合(如 cubit + state),可以合并为一个任务
- 纯配置类任务(如添加依赖)单独列出
执行顺序的原则
- 数据结构 / 模型优先(无依赖,纯定义)
- 服务层 / 业务逻辑其次(依赖模型)
- 路由 / UI 最后(依赖服务层)
- 配置变更穿插在需要的位置
- 最后一步永远是:编译验证 + 测试路径
全局约束
- 在文件头部声明全局约束(技术选型、风格参考、禁止事项)
- 如果有参考文件(如 playground 中的原型),明确指出参考哪个文件、保留什么、改什么
- 如果 design.md 中有"暂不实现"的内容,不要出现在任务清单中
文档位置
任务清单与设计报告同级:
docs/features/[模块名]/[版本号]/
├── server/
│ ├── design.md # 设计报告
│ └── tasks.md # 任务清单
└── client/
├── design.md
└── tasks.md