task-split

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 变成未经评审的实现说明书。

开发阶段必须读取权威文档原文。任务中的引用只用于定位关注范围，不能替代完整阅读。

拆分原则

1. 以可验证结果为单位：不按文档章节、代码文件或技术层次机械拆分。
2. 任务最小充分：足够小以便理解、实现、验证和提交，又足够完整以产生独立结果。预计核心改动超过 400 行时重新检查拆分，但不以行数机械切割。
3. 保持纵向闭环：同一任务尽量同时承接必要实现和其核心验证，避免把模型、接口、服务、测试横向切成无法独立验收的任务。
4. 按真实依赖排序：先构造依赖图，再拓扑排序为唯一串行序列；编号必须与执行顺序一致。
5. 降低冲突和返工：多个候选任务都可开工时，优先安排边界稳定、共享修改区域少的任务。
6. 引用而不转述：优先使用稳定编号；没有编号的工程落点使用明确章节锚点，不得用二次摘要代替引用。
7. 覆盖完整：每个需要实现的设计项至少由一个任务承接，每个测试用例有明确责任任务。
8. 存疑不放行：无法从权威输入确定任务边界或引用时，记录 Open Questions；未清零前不得确认计划。

具体流程

Phase 1：校验输入

严格模式：

1. 解析 SR、AR 和模块组名称，确认三份输入位于同一模块目录。
2. 定位并完整读取详细设计、测试设计和门禁结果。
3. 确认门禁通过，且三份输入指向同一设计范围。
4. 提取详细设计中的需求点、设计决策、契约、流程、风险编号和工程落点章节锚点。
5. 提取测试设计中的覆盖目标、测试用例编号和测试缺口。

轻量模式：

1. 解析 SR，定位 .sdd/{SR}/dev-design.md。
2. 完整读取该文档；存在 .context/dev-design-gate.md 时一并读取并确认结论为通过。
3. 提取方案、契约变更、影响文件（工程落点）和存疑项。
4. 提取验收标准条目，作为覆盖目标与验证规格。
5. 不校验、不读取、不要求三件套文档。

Phase 2：形成任务边界

1. 按独立可验证结果形成候选任务。
2. 为每个候选任务确定一句话目标、涉及范围、设计引用和测试引用。
3. 检查任务是否过大、过小、跨越不相关目标或缺少核心验证。
4. 分析真实技术依赖和共享修改区域。
5. 对依赖图进行拓扑排序，形成唯一串行顺序并依次编号。
6. 小改动也必须至少生成一个任务条目；不生成独立任务文件。

Phase 3：检查覆盖和责任关系（内部核对，不写入 tasks-overview）

1. 将每个需要实现的设计决策、契约、流程、风险或工程落点映射到任务，在分析中核对无遗漏；不在 overview 中单独列出映射表。
2. 将测试用例和覆盖目标映射到责任任务。
3. 跨任务用例归属到最早具备完整执行条件的任务。
4. 只有不影响当前任务主要完成状态的补充验证可以待处理；必须记录依赖、原因、最终责任任务和状态。
5. 核心实现或核心验收不得全部待处理到后续任务。

Phase 4：生成并检查 tasks-overview

1. 读取并复制 overview_template.md 骨架，不得从空白文档自由发挥。
2. 写入真实内容并移除全部占位提示。
3. 检查任务数量、标题、编号、顺序、依赖和 CLI tasks 列表完全一致。
4. 检查每个任务的描述是否自包含可读（不依赖编号引用才能看懂）。
5. 检查内部覆盖核对无遗漏（Phase 3），Open Questions 为空。
6. 交给用户检查任务边界、顺序和覆盖关系。

若处于 aaw-workflow，执行 done 后必须停在工作流的用户确认状态；确认前不得开始任何 task-dev。若单独执行本 skill，则在用户明确确认前只能将成果视为草案。

自检清单

• 只生成或更新了 tasks-overview.md，没有生成 T[N]-*.md。
• 严格模式：三份权威输入存在，门禁结论为通过；轻量模式：dev-design.md 存在且验收标准足以支撑拆分。
• 每个任务只有一个主要、可独立验证的目标。
• 任务描述让读者不打开权威文档就能看懂做什么（没有堆砌设计编号引用）。
• 任务内容只有边界、引用、依赖和状态，没有复制设计或测试正文。
• 已内部核对：每个需要实现的设计项（轻量模式下为每个方案/契约变更点）至少映射到一个任务，无遗漏。
• 每个测试用例（轻量模式下为每条验收标准）有责任任务，待处理用例有最终责任任务。
• 依赖图无环，T 编号与串行顺序一致。
• tasks 数据只包含标题，顺序与 overview 一致。
• Open Questions 为空。
• 用户已经确认任务计划，或成果明确标记为草案。

完成条件

只有同时满足以下条件，任务拆分阶段才可放行：

• tasks-overview.md 结构完整且通过自检；
• 权威设计和测试规格没有被复制或改写；
• 设计、测试和任务覆盖关系完整；
• 不存在影响实现的存疑；
• 用户已确认任务计划；
• 工作流完成数据与 overview 的任务标题和顺序一致。