| name | tasks |
| description | 当用户要拆任务、任务清单、排期，或 plan 技术方案完成后使用。把方案拆成2-5分钟一条的可执行小任务，产出 tasks.md。关键词：拆任务、任务清单、tasks、排期、拆解、todo。
|
tasks — 任务拆解（按什么顺序做）
触发词
拆任务、任务清单、tasks、排期、拆解、todo、任务列表、拆活
概述
把 plan.md 的技术方案拆成一条条具体的、可执行的小任务。原本笼统的"做一个看板"，到这里变成几十条明确的活，每条 agent 都能单独下手。
SDD 四台阶的第 3 阶。产物存 .agents/specs/{feature}/tasks.md。
何时该用
- plan.md 已对齐，需要拆成可执行任务
- 已有 tasks 但需要调整顺序/增删
前置条件
.agents/specs/{feature}/plan.md 已存在且用户已确认- 若无 plan，先回 spec/plan
工作流
1. 读 spec.md + plan.md
确认要实现什么、用什么技术。任务必须覆盖 plan 的所有模块，对照 spec 的所有功能。
2. 拆成 2-5 分钟一条的小任务
每条任务写清三件事：
- 改哪些文件（具体路径）
- 具体做什么（明确的动作，不是"实现登录"这种笼统话）
- 怎么验证（这条做完怎么知道对了）
任务粒度标准：一条任务 agent 能在不回头问用户的情况下独立完成。太大就拆。
3. 排顺序
按依赖关系排：
- 先搭骨架（项目结构、配置、依赖安装）
- 再做数据层（表/模型/迁移）
- 再做业务逻辑（接口/服务）
- 再做界面/交互
- 最后做集成测试/收尾
每条标注依赖（依赖哪些前置任务）。
4. 产出 tasks.md
在 .agents/specs/{feature}/tasks.md 写入：
# {功能名} 任务清单
## 阶段 1：骨架
- [ ] T1：{具体任务} | 文件：{路径} | 验证：{方式}
- [ ] T2：{具体任务} | 依赖：T1 | 文件：{路径} | 验证：{方式}
## 阶段 2：数据层
- [ ] T3：{具体任务} | 依赖：T1 | 文件：{路径} | 验证：{方式}
## 阶段 3：业务逻辑
- [ ] T4：{具体任务} | 依赖：T3 | 文件：{路径} | 验证：{方式}
## 阶段 4：界面
- [ ] T5：{具体任务} | 依赖：T4 | 文件：{路径} | 验证：{方式}
## 阶段 5：收尾
- [ ] T6：集成验证 | 依赖：T1-T5 | 验证：{端到端流程}
5. 让用户过目 + 主动建议下一步
tasks.md 已拆好，共 N 条。建议先跑 analyze 做一致性检查（spec/plan/tasks 交叉比对），或直接进 implement。要哪个？
坑点清单（Gotchas）
- 任务太大："实现用户系统"不是一条任务，要拆成"建 users 表""写注册接口""写登录接口"等。
- 没写文件路径：只写"实现登录"，agent 不知道改哪个文件。
- 没写验证方式：做完不知道对不对。每条都要有可验证的检查。
- 没排依赖：T3 依赖 T1 但排在 T1 前面 = 死锁。
- 漏覆盖：tasks 没覆盖 plan 的某个模块 / spec 的某个功能。
- 不存档：只口头说任务清单没存 tasks.md，下次会话就丢。
关键规则
- 必须每条任务写明：文件路径 + 具体动作 + 验证方式。
- 必须排依赖顺序。
- 必须覆盖 plan 的所有模块和 spec 的所有功能。
- 必须存到
.agents/specs/{feature}/tasks.md。
- 任务粒度：2-5 分钟，agent 能独立完成。
参考
- 上游 skill：
plan（技术方案）
- 下游 skill：
analyze（一致性检查）/ implement（实现）
