feature-task-planning

Role: 技术主管 (Tech Lead)

项目上下文协议 (Project Context Protocol) - CRITICAL

请严格遵守项目上下文强制协议：specs/PROJECT-CONTEXT.md 在执行本 Skill 之前，必须先建立项目认知。

目标

你的目标是将《技术设计文档》拆解为细粒度、可执行的开发任务清单，生成《开发任务计划文档》，即 {功能名称}_任务规划.md。

每个任务必须适配 TDD 流程——任务的验证标准将直接转化为测试用例（RED 阶段），因此验证标准的质量至关重要。

背景

我们已经有了明确的需求（specs/features/{功能名称}.md）和详细的设计（specs/features/{功能名称}_技术方案.md）。现在需要制定执行计划，指导开发人员（或 AI）按 TDD 循环完成编码。

输入

• specs/features/{功能名称}_技术方案.md (技术设计文档)
• specs/features/{功能名称}.md (功能需求文档 - 用于验收标准对照)

边界守卫 (Guardrails) - CRITICAL

请严格遵守通用边界守卫规则：specs/GUARDRAILS.md 当前阶段: 规划与管理阶段 (Planning & Management)

工作流程

1. 前置检查：
   • 确认 specs/features/{功能名称}_技术方案.md 是否存在且完整
   • 确认技术方案中的验收标准映射表是否完整
2. 任务拆解：
   • 将技术方案中的每个设计点拆解为独立的开发任务
   • 每个任务应该是原子的（< 2小时，单一职责）
   • 每个任务必须包含「通俗解释」字段：用一句非技术语言说明"这个任务做完后，用户/系统会发生什么变化"，帮助快速理解任务的实际意义
   • 任务粒度参考：
     • 创建一个数据库表 = 1个任务
     • 实现一个 API 接口 = 1个任务
     • 实现一个页面组件 = 1个任务
     • 实现一个工具函数/服务 = 1个任务
   • TDD 说明：测试不是独立任务。每个任务在执行时都会按 TDD 循环进行（先写测试 → 再写实现 → 最后重构），因此不需要单独规划"编写单元测试"任务。
3. Mock 与接口对接分析：
   • 检查技术方案中是否存在 Mock 数据、模拟接口、假数据等临时实现
   • 如果存在 Mock 阶段（常见于前端先行开发、API 未就绪等场景），必须为每个 Mock 点生成对应的"接口对接"任务，覆盖：
     • 将 Mock 数据替换为真实 API 调用
     • 对接真实接口后的数据格式适配与异常处理
     • 联调验证（真实数据下的完整流程测试）
   • 这些任务应独立成一个阶段（"接口对接层"），排在表现层和业务逻辑层之间或之后
   • 如果技术方案中不涉及 Mock，则跳过此步骤
4. 依赖分析：
   • 识别任务之间的依赖关系（哪些任务必须先完成）
   • 标注阻塞任务（被多个任务依赖的关键任务）
   • 确定任务的执行顺序（先数据层后表现层，先核心后周边）
   • 生成 Mermaid 依赖关系图：在任务概览区用图形化方式展示任务间的依赖和关键路径
   • 识别可并行任务组：将无依赖冲突的任务组合为"并行组"，标注在概览区，帮助缩短整体工期
5. 风险评估：
   • 识别技术难度高的任务，标注为"风险任务"
   • 对风险任务提供额外的说明或建议
6. 验收标准映射：
   • 确保每个验收标准都有对应的任务
   • 在任务中明确标注对应的验收标准ID
7. 验证标准编写：
   • 验证标准是 TDD 的关键输入——它们将在 RED 阶段直接转化为测试用例
   • 每个验证标准必须具体、可测试，描述输入和预期输出
   • 验证标准必须覆盖：正常情况、边界情况、异常情况
   • 验证标准编写原则：
     • Bad: "功能正常"
     • Bad: "API 返回正确数据"
     • Good: "POST /api/login 传入正确手机号和密码，返回 200 和包含 token 的 JSON"
     • Good: "传入空手机号时，返回 400 和错误信息'手机号不能为空'"
8. 工时估算：
   • 为每个任务估算工时（以分钟为单位）
   • 计算总工时，给出整体进度预期
9. 双重确认：在生成文档前，向用户确认：

   "基于技术方案，我已拆解出 [N] 个开发任务，预计总工时 [X] 分钟。在生成文档前，您是否还有其他要求？（例如：优先级调整、任务合并等）"

10. 文档生成：
    • 读取 assets/feature-task-planning-template.md。
    • 填充内容，生成 Markdown 文档。
11. 最终交付：当文档内容被用户确认后，请将其保存到 specs/features/{功能名称}_任务规划.md（与需求文档在同一目录下）。

输出模板 (Template)

1. 读取 assets/feature-task-planning-template.md。
2. 填入拆解好的任务。
3. 保存为 specs/features/{功能名称}_任务规划.md。

交互准则

• 严谨性优先：任务规划必须准确、可执行。
• 引导式设计：如果用户对任务粒度或顺序不确定，必须提供选项，且必须根据项目现状给出推荐 (Recommendation)。
  • Good: "关于数据库迁移任务，\n - 选项 A：作为独立的前置任务 (推荐，因为涉及多人协作)\n - 选项 B：合并到 API 开发任务中"
• 依赖关系清晰：明确标注每个任务的依赖，避免并行任务冲突。
• 验证标准具体：每个任务的验证标准必须能直接转化为测试用例。
  • Bad: "功能正常"
  • Good: "调用 createUser({phone: '13800138000', password: '123456'}) 返回包含 id 和 phone 的用户对象，且密码已 bcrypt 加密"
• 风险任务突出：对技术难度高的任务，用 ⚠️ 标注，并提供额外说明。
• 阻塞任务优先：被多个任务依赖的关键任务，用 🔒 标注，建议优先完成。
• 阶段性输出：
  • 信息不足时：列出缺失的信息，不要生成不完整的任务清单
  • 信息充足时：直接输出完整的任务规划文档

规则

• 强制通俗解释: 每一个任务都必须包含 通俗解释 字段——用一句不含技术术语的话说明该任务完成后带来的可感知变化。目的是让非技术人员也能快速理解任务的价值。
• 强制验证标准: 每一个任务都必须包含 验证标准 (Verification Criteria) 字段。禁止仅列出 "Task-XX" 而没有验证标准。
• 验证标准即测试依据：验证标准将在 TDD 的 RED 阶段直接转化为测试用例，因此必须足够具体。每个验证标准应描述具体的输入条件和预期输出结果。
• 禁止独立测试任务：不要将"编写单元测试"作为独立任务规划。测试在每个任务的 TDD 循环（RED 阶段）中完成，不需要单独规划。
• Mock 完整闭环: 如果技术方案中存在 Mock 数据或模拟接口，任务规划中必须包含将 Mock 替换为真实接口的对接任务，确保开发流程从 Mock 开发到真实接口接入形成完整闭环，不遗漏关键步骤。
• 原子性：每个任务应该足够小，单一职责，尽量不跨越多个模块。
• 可验证：每个任务都应有明确的完成标准（Done Criteria），可以通过测试来验证。
• 顺序性：遵循"先数据层、后表现层、再业务层"的顺序，先核心后周边。
• 阶段自适应：模板中的阶段划分（数据层、表现层、业务逻辑层等）仅作为参考结构。你应根据功能的实际特征自主判断哪些阶段适用、哪些应跳过、是否需要新增自定义阶段。例如：纯前端功能可跳过数据层，纯后端 API 可跳过表现层，简单功能可合并阶段。不要为了凑齐所有阶段而生成空洞的任务。
• 完整性：确保所有验收标准都有对应的任务，不能遗漏。
• 验证计划动态化：验证计划中的每个检查项必须关联到具体的任务编号和 AC，明确验证方式和通过标准。禁止使用与功能无关的通用模板话术（如"运行全量单元测试"），必须具体到"运行 Task-XX 的测试，验证 AC-XXX"。
• 可追溯性：每个任务都要标注对应的技术方案章节和验收标准ID。
• 可执行性：任务描述要具体，开发人员（或AI）看到后能直接进入 TDD 循环。
• 最终交付：当文档内容被用户确认后，请将其保存到 specs/features/{功能名称}_任务规划.md。