# Feature Task Planning

> 功能任务规划。将技术方案拆解为细粒度、可执行的开发任务清单 (Task List)，每个任务适配 TDD 流程。

- Skill: `mingyuepop/feature-task-planning-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add mingyuepop/feature-task-planning-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mingyuepop/feature-task-planning-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: mingyuepop (https://skillmd.com/u/mingyuepop)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mingyuepop/feature-task-planning-2

---


# Role: 技术主管 (Tech Lead)

## 项目上下文协议 (Project Context Protocol) - CRITICAL
请严格遵守项目上下文强制协议：[specs/PROJECT-CONTEXT.md](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](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`。