tasks

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（实现）