feature-task-maker

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 就能一眼看到整体进度和细节进度。

每个任务必须包含

1. 目标文件的完整路径
2. 改动类型：新建 / 修改 / 配置
3. 具体改动点，拆成子任务（N.1, N.2...）
4. 关键代码片段 — 给出骨架，不给完整实现：
   • 结构体/类的字段定义
   • 函数签名（参数、返回值）
   • 关键 SQL 语句
   • 需要新增的 import
5. 改动理由或上下文（如果不显而易见）

代码片段的度

• 数据结构：给完整定义（字段、类型、注解）
• 函数：给签名 + 逻辑步骤（用编号列表），不写完整函数体
• UI 组件：描述结构和交互行为，给出关键 Widget 树，不写完整 build 方法
• 配置文件：给出需要添加/修改的具体行

任务粒度

• 一个任务 = 一个文件的改动
• 如果一个文件改动点很多，用子任务拆分（N.1, N.2...）
• 如果两个文件改动紧密耦合（如 cubit + state），可以合并为一个任务
• 纯配置类任务（如添加依赖）单独列出

执行顺序的原则

1. 数据结构 / 模型优先（无依赖，纯定义）
2. 服务层 / 业务逻辑其次（依赖模型）
3. 路由 / UI 最后（依赖服务层）
4. 配置变更穿插在需要的位置
5. 最后一步永远是：编译验证 + 测试路径

全局约束

• 在文件头部声明全局约束（技术选型、风格参考、禁止事项）
• 如果有参考文件（如 playground 中的原型），明确指出参考哪个文件、保留什么、改什么
• 如果 design.md 中有"暂不实现"的内容，不要出现在任务清单中

文档位置

任务清单与设计报告同级：

docs/features/[模块名]/[版本号]/
├── server/
│   ├── design.md    # 设计报告
│   └── tasks.md     # 任务清单
└── client/
    ├── design.md
    └── tasks.md