技能（Skill）：分解任务
目的 (Purpose)
将已验证设计文档变成有序的、可跟踪的任务列表。每个任务都有依赖性、验收标准和受让人（或人工智能执行提示），以便可以毫无歧义地进行实施。
核心目标（Core Objective）
任务目标：根据设计文档生成任务文档（例如tasks.md），以便每个可实施的单元都是一个具有明确依赖性、验收标准和所有权的任务。
成功标准（必须满足所有要求）：
- ✅ 任务文档存在：写入商定的路径（例如
docs/process-management/tasks/YYYY-MM-DD-<topic>.md或项目tasks.md）并提交 - ✅ 设计可追溯性：每项任务至少映射到设计的一部分（部分或验收标准）
- ✅ 依赖关系明确：任务顺序或依赖关系列表清晰（无循环依赖关系）
- ✅ 每个任务的接受标准：每个任务都有具体的“完成”标准
- ✅ 受让人或执行提示：每个任务都有所有者（人/角色）或AI执行提示（例如要运行哪个技能或步骤）
- ✅ 用户确认：用户明确批准或调整任务列表
验收测试：执行者（人或代理）可以仅使用此文档和设计来选择下一个任务，实施它并验证完成情况吗？
范围边界（范围边界）
本技能负责：
- 设计文档 → 有序任务列表（tasks.md 或同等文件）
- 任务之间的依赖关系；每项任务的验收标准；受让人或AI执行提示
- 将任务列表作为活的产品进行持久化，以进行实施跟踪
本技能不负责：
- 创建或验证设计（使用“设计解决方案”或“头脑风暴设计”）
- 验证需求（使用“分析需求”）
- 执行任务（实施技巧、运行修复循环等）
- 日程安排或容量规划（使用项目/里程碑工具）
转交点：当任务列表被批准并保留后，移交给执行（例如按顺序运行任务，或输入待办/板）。
使用场景（用例）
- 设计后规划：设计获得批准；在编码之前你需要一个清晰的实施计划。
- 可追溯性：您希望每个设计决策都映射到一个或多个具体任务。
- 人工智能辅助执行：您希望每个任务都包含提示（例如“使用技能 X”或“编辑文件 Y”），以便代理可以执行计划。
行为（行为）
交互（互动）政策
- 默认：需要设计文档（路径或内容）；使用项目规范作为输出路径（如果存在）
- 选择选项：当设计不明确时，一次提出一个澄清问题
- 确认：用户必须批准或调整任务列表才能转交
第 1 阶段：摄取设计
- 加载设计：阅读设计文档（例如设计.md或docs/design-decisions/*.md）。
- 提取结构：识别暗示工作的部分（架构、组件、数据流、错误处理、测试等）。
- 确认范围：如果用户指定了一个子集（例如“仅后端”），则将任务限制为该子集。
第 2 阶段：派生任务
- 每个可实施单元一项任务：每项任务都应在一次焦点会议中完成；当 X 很大时，避免模糊的“实施 X”。
- 按依赖关系排序：列出任务，使依赖关系排在第一位； 明确的文档依赖性（例如“取决于：T1，T2”）。
- 验收标准：对于每项任务，说明“完成”是什么样的（可测试或可验证）。
- 受让人或提示：对于每个任务，设置受让人（人员/角色）或 AI 执行提示（例如“为模块 Y 运行设计解决方案”、“根据设计§3 编辑 src/foo.ts”）。
第三阶段：坚持并移交
- 解析路径：优先选择项目规范（例如docs/ARTIFACT_NORMS.md）；否则
docs/process-management/tasks/YYYY-MM-DD-<topic>.md或项目约定tasks.md。 - 编写任务文档：使用一致的格式（见下文）；如果项目使用它，则包含 front-matter（
created_by:分解任务、lifecycle:living、设计源路径）。 - 用户批准：呈现摘要并请求批准或编辑。
- Handoff：建议从第一个未阻塞的任务开始执行。
输入与输出 (Input & Output)
| 角色 | 内容 |
|---|---|
| 输入 | 设计文档（路径或内容）；用户的可选范围/优先级 |
| 输出 | 任务文档位于 docs/process-management/tasks/YYYY-MM-DD-<topic>.md 或项目 tasks.md；每个任务都有 ID、标题、依赖项、接受标准、受让人/提示 |
推荐的任务列表格式
# Implementation tasks: [Topic]
**Source design:** [path or title]
**Created:** YYYY-MM-DD
| Id | Task | Depends on | Acceptance criteria | Owner / Hint | Status |
| :--- | :--- | :--- | :--- | :--- | :--- |
| T1 | ... | — | ... | ... | Todo |
| T2 | ... | T1 | ... | ... | Todo |状态生命周期 (Status Lifecycle)
本技能仅负责将所有派生任务的初始状态设置为 Todo。 下游实施与执行技能（如具体的开发执行 agent）、任务看板同步工具或开发人员，负责在实施期间维护并更新该状态（例如流转为 In Progress、Blocked、Done 或 Cancelled）。本技能不负责在此后持续变更任务状态。
可选：在顶部添加简短的“摘要”和“设计可追溯性”（任务 → 设计部分）。
限制（限制）
硬边界（Hard Boundaries）
- 设计优先：设计缺失或未经批准时请勿运行；交给“设计解决方案”或“头脑风暴设计”。
- 无实施：不编写代码或运行实施技巧；只产生任务列表。
- 无循环依赖：任务顺序必须是非循环的。
技能边界 (Skill Boundaries)（避免重叠）
不要做这些（其他技能可以处理它们）：
- 需求分析或验证→“分析需求”
- 设计探索或批准→
设计解决方案 - 执行任务或修复循环→实施技能或“运行修复循环”
自检（Self-Check）
- 任务文档存在并已提交
- 设计可追溯性：每项任务至少映射到设计的一部分
- 依赖关系明确：任务顺序或依赖列表清晰，无循环依赖
- 每个任务都有接受标准（可测试或可验证）
- 每个任务都有受让人或 AI 执行提示
- 每一项任务都配置了初始状态（如
Todo）并包含在表格状态列中 - 用户批准或明确接受的任务列表
示例（示例）
示例 1：标准设计到任务流程
调用：“我们在 docs/design-decisions/2026-03-16-core-v1.md 中有设计。将其分解为任务。”
代理：使用分解任务；读设计；导出具有部门和验收标准的有序任务；写入 docs/process-management/tasks/2026-03-16-core-v1.md；获得用户认可；建议从第一个任务开始。
示例 2：边缘情况 — 超大设计
调用：“我们的平台设计文档非常庞大（多个子系统）。我们现在只需要‘身份验证+用户入门’的任务。”
代理：
- 要求用户确认预期的范围子集（例如设计的第 3 节和第 4 节）。
- 将任务派生限制为该子集，并清楚地注明任务文档中的范围源部分。
- 确保范围之外的依赖项要么作为外部先决条件存根，要么作为显式阻止程序捕获。
- 生成一个任务文件，其第一列将每个任务链接回所使用的特定设计部分，因此将来的运行可以扩展覆盖范围而无需重复。