generate-tasks

Generate Task List

为一个功能创建按依赖排序的实现任务。默认产物：docs/tasks/<feature-id>-tasks.md。

语言与边界

• 默认使用中文撰写；保留文件路径、命令、代码符号、接口名和 feature id 原文。
• 任务要小到一个 agent session 可以完成并验证。
• 不写产品新需求；发现 spec 或 plan 缺口时记录冲突或待确认项。
• 默认只创建或更新任务文档，不修改业务代码。

工作流

1. 识别目标 feature id；无法从请求、spec 文件或 PRD 推断时再提问。
2. 读取 docs/specs/<feature-id>.md。
3. 如果存在 docs/tasks/<feature-id>-plan.md，读取它作为主要实施依据；否则读取 docs/PRD.md 补充背景。
4. 将工作拆成依赖有序、可独立评审、可验收的任务。
5. 覆盖实现、测试、文档、配置、迁移/回填、验证命令和发布前检查。
6. 如果已有任务文件，保留已完成任务的 ID 和历史记录，除非用户要求重写。
7. 创建或更新 docs/tasks/<feature-id>-tasks.md。

任务格式

使用复选框和稳定任务 ID：

- [ ] T01: 简短任务标题
  - 目标：
  - 涉及文件或模块：
  - 前置依赖：
  - 验收标准：
  - 验证方式：
  - 复杂度：S/M/L

拆解规则

• T01、T02 等任务 ID 要稳定；更新已有清单时不要无故重排已引用的 ID。
• 前置任务必须先出现，避免后续实现时需要跨任务跳跃。
• 每个任务只能有一个主要目标；如果验收范围过宽，拆成多个任务。
• 验证方式优先写实际命令，例如 npm test、swift test、pod lib lint；未知时写需要人工确认的验证路径。
• 测试任务不要集中到最后，尽量跟随对应行为改动。

质量标准

• 避免“实现功能”“处理边界情况”这类不可验收任务。
• 每个任务都要包含停止条件：完成到什么程度即可交给 implement-feature。
• 如果 plan 和 spec 不一致，新增“冲突/待确认”任务或备注，不要静默选择一边。
• 完成后说明任务数量、首个建议执行任务和任何阻塞问题。