| name | task-split |
| version | 2.3.2.4 |
| description | 基于已确认的设计与测试规格，生成单文件薄任务计划 tasks-overview.md；任务只保留目标、范围、权威设计/测试引用、依赖和状态，不复制或改写设计正文。Use when the user asks for 任务拆分、开发任务规划、有序任务计划、task split，或希望把已评审设计组织为可串行调度的 T1/T2 任务。支持两种模式：严格模式（SR/AR 入口）以详细设计文档、测试用例设计文档和通过的模块设计门禁结果为输入；轻量模式（dev 入口）以单份 dev-design.md 为输入，由工作单显式声明。 |
前置操作：工作流编排检查
若本 skill 是由 aaw-workflow 的工作单调用的，跳过本节，直接执行正文。
否则，在执行正文之前，先向用户发起一次二选一确认：
是否回到 aaw-workflow 工作流中执行？
- 是，回到工作流（推荐）——进度会被跟踪和上报
- 否，单独执行本 skill——本次执行将不纳入流程跟踪
- 用户选“是” → 加载
aaw-workflow skill，按其流程执行（其入口意图判定会引导继续已有工作流或新建），不再单独执行本 skill 正文。
- 用户选“否” → 继续执行本 skill 正文，之后不再提及工作流。
本节最多询问一次，不得重复打扰。
若工作单输出已存在，仍按当前要求完整执行：先读取并评估已有成果，复用仍有效的信息和已确认答案，可局部修改或整体重写，并写回原路径。
模式判定
本 skill 支持两种输入模式，由工作单（或调用上下文）里的标记决定：
- 严格模式（默认）：SR/AR 入口调用。权威输入是《详细设计说明书》《测试用例设计》《模块设计门禁结果》三件套。按下方「输入与前置条件」执行，三件套缺失时停止并返回上游。
- 轻量模式：dev 入口调用。工作单的
prompt 字段会显式声明“本实例为 task-split 的【轻量模式】”。此时权威输入只有 .sdd/{SR}/dev-design.md，不存在三件套，也不要求它们。按「轻量模式分支」执行，不要因为缺三件套而中止或引导用户跑 module-tobe-design / module-test-design / module-design-gate。
判定方法：若工作单 prompt 中存在“【轻量模式】”标记，进入轻量模式；否则（含单独调用、无标记的普通调用）一律按严格模式。
重新拆分时可以保留职责未变化任务的 T 编号。任务拆分只以当前工作单登记的输入和输出路径为准。
task-split
定位
任务拆分位于设计门禁与代码实现之间。它只负责把已评审设计组织成一条可调度的实现顺序，不生成第二份设计。
严格模式下，详细设计文档是实现设计的唯一事实来源，测试用例设计文档是验证规格的唯一事实来源；轻量模式下两者均由 dev-design.md 承担（方案与契约变更章节 / 验收标准章节）。tasks-overview.md 只保存任务边界和指向权威文档的引用。
任务编号 T1、T2……仅作为调度、状态和遥测标识。新版流程不生成 T1-xxx.md、T2-xxx.md 等独立任务文件。
输入与前置条件（严格模式）
本节适用于严格模式；轻量模式见下一节。
三个输入均为必需：
| 输入 | 默认路径 | 要求 |
|---|
| 详细设计文档 | .sdd/{SR}/{AR}/{模块组名}/模块详细设计说明书.md | 正式成果物，设计状态允许进入 AICoding |
| 测试用例设计文档 | .sdd/{SR}/{AR}/{模块组名}/模块测试用例设计.md | 正式成果物，不存在阻断测试缺口 |
| 模块设计门禁结果 | .sdd/{SR}/{AR}/{模块组名}/.context/模块设计门禁结果.md | 当前结论为“通过” |
启动后立即校验：
- 三份文件真实存在，且属于同一个 SR、AR 和模块组。
- 门禁结论为“通过”；不通过或阻塞时不得生成可放行的任务计划。
- 详细设计和测试设计不存在会影响任务边界、实现或验证的待确认项。
- 非标准输入或缺少状态字段时，必须由用户明确确认其可作为任务规划依据；在工作流编排中不得以此绕过门禁。
任一条件不满足时停止，返回对应设计、测试设计或门禁阶段处理。任务拆分不得补设计、补测试规格或用推断掩盖上游缺口。
轻量模式分支
仅当工作单声明【轻量模式】时适用。
输入
| 输入 | 默认路径 | 要求 |
|---|
| 轻量设计文档 | .sdd/{SR}/dev-design.md | 必需。方案与契约变更章节是实现设计的事实来源；验收标准章节是验证规格的事实来源 |
| 轻量门禁结果 | .sdd/{SR}/.context/dev-design-gate.md | 可选。存在时确认结论为通过 |
启动后校验：
dev-design.md 真实存在且可读；- 其方案与契约变更足以确定任务边界，验收标准足以确定每个任务的验证范围；
- 不存在影响任务边界、实现或验证的待确认项。
不要校验《模块详细设计说明书》《模块测试用例设计》《模块设计门禁结果》是否存在，不要因其缺失而中止，不要引导用户去执行 module-tobe-design / module-test-design / module-design-gate。
dev-design.md 缺失或内容不足以支撑拆分时，停止并返回 dev-design 阶段补齐；不得自行补设计或用推断掩盖缺口。
与严格模式的差异
| 严格模式 | 轻量模式 |
|---|
| 实现设计来源 | 《模块详细设计说明书》 | dev-design.md 的方案与契约变更章节 |
| 验证规格来源 | 《模块测试用例设计》的用例编号 | dev-design.md 的验收标准条目 |
| 输出路径 | .sdd/{SR}/{AR}/{模块组名}/tasks-overview.md | .sdd/{SR}/tasks-overview.md |
| 测试引用形式 | 引用用例编号 | 引用验收标准条目（无编号时引用其原文短语） |
轻量模式下，验收标准同时承担测试规格的角色：为每个任务标明它负责哪几条验收标准，确保每条验收标准都有责任任务。
保持不变的部分
除输入来源、输出路径和测试引用形式外，其余全部沿用本 skill 正文：拆分原则、任务计划边界（允许/禁止写入）、Phase 2-4 流程、overview_template.md 骨架、### T{N} 小节与 - 状态： 字段的格式契约、自检清单、以及“不生成 T[N]-*.md 独立任务文件”的约束。
输出
唯一成果物（路径随模式变化，见上表）：
.sdd/{SR}/{AR}/{模块组名}/tasks-overview.md
tasks-overview.md 必须遵循 <skill-dir>/references/overview_template.md，包含：
- 元信息和三份权威输入路径；
- 串行执行规则和顺序；
- 薄任务计划（每个任务：做什么、改哪些文件、验证哪些用例、前置）；
- 存疑汇总；
- 待处理用例登记；
- 由
task-dev 更新的执行记录区。
若由 aaw-workflow 调用，完成后按工作单 data_schema 回填任务标题列表。列表项只包含标题，不包含 T1-/T2- 前缀或 .md 后缀：
{"tasks":["用户CRUD","权限校验"]}
任务计划边界
允许写入
- 一个可独立验收的任务目标；
- 本任务涉及的模块、组件或工程落点范围（文件路径）；
- 测试设计中的测试用例编号（用于定位验证范围）；
- 真实前置任务、串行位置和状态；
- 跨任务补充验证的最终责任任务。
禁止写入
- 重新描述接口字段、方法签名、数据结构、错误码或配置值；
- 复制、重画或简化流程图和时序图；
- 改写算法、状态流转、异常处理、兼容、灰度或回退策略；
- 复制测试步骤、输入参数、断言和预期结果；
- 新增详细设计或测试设计中不存在的技术结论；
- 堆砌详细设计中的决策/契约/流程编号引用——任务描述必须让读者不打开权威文档就能看懂做什么，编号只用于开发时定位；
- 生成独立
T[N]-*.md 任务文件；
- 把
tasks-overview.md 变成未经评审的实现说明书。
开发阶段必须读取权威文档原文。任务中的引用只用于定位关注范围，不能替代完整阅读。
拆分原则
- 以可验证结果为单位：不按文档章节、代码文件或技术层次机械拆分。
- 任务最小充分：足够小以便理解、实现、验证和提交，又足够完整以产生独立结果。预计核心改动超过 400 行时重新检查拆分，但不以行数机械切割。
- 保持纵向闭环：同一任务尽量同时承接必要实现和其核心验证，避免把模型、接口、服务、测试横向切成无法独立验收的任务。
- 按真实依赖排序：先构造依赖图，再拓扑排序为唯一串行序列；编号必须与执行顺序一致。
- 降低冲突和返工：多个候选任务都可开工时，优先安排边界稳定、共享修改区域少的任务。
- 引用而不转述：优先使用稳定编号；没有编号的工程落点使用明确章节锚点，不得用二次摘要代替引用。
- 覆盖完整：每个需要实现的设计项至少由一个任务承接，每个测试用例有明确责任任务。
- 存疑不放行：无法从权威输入确定任务边界或引用时，记录
Open Questions；未清零前不得确认计划。
具体流程
Phase 1：校验输入
严格模式：
- 解析 SR、AR 和模块组名称，确认三份输入位于同一模块目录。
- 定位并完整读取详细设计、测试设计和门禁结果。
- 确认门禁通过，且三份输入指向同一设计范围。
- 提取详细设计中的需求点、设计决策、契约、流程、风险编号和工程落点章节锚点。
- 提取测试设计中的覆盖目标、测试用例编号和测试缺口。
轻量模式：
- 解析 SR，定位
.sdd/{SR}/dev-design.md。
- 完整读取该文档；存在
.context/dev-design-gate.md 时一并读取并确认结论为通过。
- 提取方案、契约变更、影响文件（工程落点）和存疑项。
- 提取验收标准条目，作为覆盖目标与验证规格。
- 不校验、不读取、不要求三件套文档。
Phase 2：形成任务边界
- 按独立可验证结果形成候选任务。
- 为每个候选任务确定一句话目标、涉及范围、设计引用和测试引用。
- 检查任务是否过大、过小、跨越不相关目标或缺少核心验证。
- 分析真实技术依赖和共享修改区域。
- 对依赖图进行拓扑排序，形成唯一串行顺序并依次编号。
- 小改动也必须至少生成一个任务条目；不生成独立任务文件。
Phase 3：检查覆盖和责任关系（内部核对，不写入 tasks-overview）
- 将每个需要实现的设计决策、契约、流程、风险或工程落点映射到任务，在分析中核对无遗漏；不在 overview 中单独列出映射表。
- 将测试用例和覆盖目标映射到责任任务。
- 跨任务用例归属到最早具备完整执行条件的任务。
- 只有不影响当前任务主要完成状态的补充验证可以待处理；必须记录依赖、原因、最终责任任务和状态。
- 核心实现或核心验收不得全部待处理到后续任务。
Phase 4：生成并检查 tasks-overview
- 读取并复制
overview_template.md 骨架，不得从空白文档自由发挥。
- 写入真实内容并移除全部占位提示。
- 检查任务数量、标题、编号、顺序、依赖和 CLI
tasks 列表完全一致。
- 检查每个任务的描述是否自包含可读（不依赖编号引用才能看懂）。
- 检查内部覆盖核对无遗漏（Phase 3），Open Questions 为空。
- 交给用户检查任务边界、顺序和覆盖关系。
若处于 aaw-workflow，执行 done 后必须停在工作流的用户确认状态；确认前不得开始任何 task-dev。若单独执行本 skill，则在用户明确确认前只能将成果视为草案。
自检清单
完成条件
只有同时满足以下条件，任务拆分阶段才可放行：
tasks-overview.md 结构完整且通过自检；- 权威设计和测试规格没有被复制或改写；
- 设计、测试和任务覆盖关系完整；
- 不存在影响实现的存疑；
- 用户已确认任务计划；
- 工作流完成数据与 overview 的任务标题和顺序一致。
