| name | task-split |
| description | 基于已确认的详细设计文档，拆分为带完整设计和用例的独立任务文件，严格顺序执行。Use when the user asks for 详细任务拆分、带设计的任务拆分、任务详细设计、独立任务文件、detailed task split，or wants to convert a detailed design doc into self-contained task files with full design and test cases for each task. Also trigger when the user mentions 每个任务要有完整设计、任务要独立可开发、要详细用例. 注意：本 skill 必须以详细设计文档为输入，没有详细设计时应先引导用户运行 write-us-design 或提供详细设计文档。 |
Split Tasks Detailed
把已确认的详细设计文档拆分成独立的任务文件，每个任务包含从设计文档中提取的详细设计内容和结构化用例，使得开发者可以只看单个 task 文件就能完成开发和测试。任务按前置任务字段确定的拓扑序逐个执行，同一时刻只能开发一个任务。
模板契约
- 每次生成前，先读取对应模板：
<skill-dir>/references/overview_template.md 和 <skill-dir>/references/task_template.md。
- 采用 template-first 写法：先把模板骨架完整复制，再逐项替换占位内容；不得从空白文档自由发挥。
- 模板是输出骨架和约束。必须保留模板中的标题层级、章节顺序、表格列、必填章节；占位提示要替换为实际内容，不得改名、删减、重排、加编号、合并章节或自由发挥结构。
- 对无法从设计文档确定的信息，不得猜测。必须在对应位置标
【存疑】，并同步写入 overview.md 的 Open Questions。
- 写完所有文件后，先做模板一致性自检。自检必须逐项检查：标题层级、章节顺序、表格列、占位项替换、"执行规则"是否原样保留、每个任务是否包含详细设计/用例设计/DoD、
【存疑】 是否同步进入 overview Open Questions。若任一项不符合模板，先修正文件，再交给用户检查。
- 交给用户检查时，如果
overview.md 的 "存疑汇总（Open Questions）"非空，必须主动单独列出这些存疑项和待确认问题，并明确需要用户确认后才能视为该阶段通过。
使用前提（强约束）
必须有详细设计文档作为输入。 详细设计文档可以是 module-tobe-design 生成的模块详细设计文档，也可以是用户提供的其他详细设计文档（需包含实现方案、接口设计、代码影响等章节）。
skill 启动后第一步即校验：
- 用户已指定 ar 编号或设计文档路径，且对应的详细设计文档真实存在；
- 若输入文档是
module-tobe-design 模板文档且不存在未闭环的问题和待确认的问题 才能继续；若存在未闭环的问题或待确认的问题，提示用户"建议先确认设计文档，或明确授权基于未稳定设计拆分任务"。
- 若输入文档不是
write-us-design 模板，或没有 状态 字段，不阻断流程；必须询问用户"该详细设计是否已确认可用于拆分任务？"用户确认后继续。
若找不到详细设计文档，立即中止拆分流程并引导用户：
- 找不到详细设计文档 → 提示"本 skill 需要基于已确认的模块详细设计进行任务拆分。请先运行
module-tobe-design 生成详细设计文档，或提供包含实现方案、接口设计、代码影响的详细设计文档。"
只有当输入条件满足时，才进入下面的 Workflow。
task-split 不负责重新做设计或完整代码探索。任务的详细设计内容（背景与目标、实现方案、接口设计、非功能约束）全部从输入的详细设计文档中提取并分配到对应 task；用例设计优先从详细设计文档的"验证和测试"章节转换为结构化用例。
Workflow
先建立 todo list，并按以下流程执行。
Phase 1: 校验输入
- 询问或确认 US 编号、详细设计文档路径（默认文件名为
xxx模块详细设计说明书.md）。
- 校验详细设计文档存在；不存在则按"使用前提"指引用户并退出。
Phase 2: 拆分任务并生成独立文件，并请用户确认
Launch a subagent：
请根据用户确认的详细设计文档拆分任务。若存在software_architecture.md，用它校验模块归属；若不存在，以设计文档中的模块为准。
输出目录：./.sdd/[SR编号]/[AR编号]/[模块名称]_tasks/
overview.md（任务概览）T1-[任务标题].mdT2-[任务标题].md- ...
若由 aaw-workflow 编排调用，完成文件生成后需要按工作单的 data_schema 回填任务标题列表。该列表只填写任务标题本身，不包含 T1-、T2- 等编号前缀，也不包含 .md 后缀。例如生成了 T1-用户CRUD.md 和 T2-权限校验.md，提交给 CLI 的数据应为：
{"tasks":["用户CRUD","权限校验"]}
参考模板
- 概览模板：
<skill-dir>/references/overview_template.md
- 任务模板：
<skill-dir>/references/task_template.md
IMPORTANT：
- 先完整复制模板骨架，再填充内容；输出标题、表格列和"执行规则"必须保持模板原样。
- 任务拆分原则：
- 按模块合并优先：同一模块的修改默认全部放在一个任务中完成，不按功能点/文件粒度细拆；多个模块的修改若耦合紧密也可合并到一个任务。
- 400 行硬阈值才拆：只有当单个任务预计代码改动超过 400 行时，才拆分为多个任务；拆分时仍按子功能/接口边界切分，保持每个任务内部高内聚，而非按文件粒度机械切割。
- 每个任务要独立可验证。
- 任务按前置任务字段确定的拓扑序逐个执行；同一时刻只能开发一个任务，不允许并行；多个可开工任务按编号小者优先。
- 任务编号只作标识，不保证等于执行顺序；前置任务字段必填（首个任务填"无"，线性链填前一个任务编号，DAG 分叉如实列出所有前置任务）。
- 能靠重排编号消除的线性依赖优先重排编号，让 T1→T2→T3 仍符合拓扑序；遇到无法靠重排消除的 DAG 分叉（如 T3 同时依赖互相独立的 T1、T2），保留编号、靠前置任务字段如实表达。
- 详细设计内容分配：
- 从输入的详细设计文档中提取"背景与目标"、"实现方案"、"接口设计"、"非功能约束"内容，按任务涉及的模块/功能点分配到对应 task 的"详细设计"章节。
- 流程图从详细设计文档原样复制到每个相关 task 的"流程图"章节；若设计文档有多张图，复制涉及该 task 模块的图；不得自行重画、简化或合并。确保跨 task 开发时流程图一致，本 task 实现的接口在原图中能被下游 task 的调用关系体现，避免孤儿接口。
- 从设计文档的"代码影响"章节按模块分配到各 task 的"代码影响"表格。
- 不自行补充或重新设计；如果设计文档某部分内容不足以支撑某个 task，在该 task 对应位置标
【存疑】 并写入 overview Open Questions。
- 用例设计生成：
- 优先从详细设计文档的"验证和测试"或类似章节提取测试场景，将其转换为结构化用例（前置条件/测试步骤/预期结果/后置条件）并分配到对应 task。
- 如果详细设计文档缺少某个 task 的用例/测试描述，在该 task 的"用例设计"章节标注
【存疑】详细设计文档未提供该任务的用例设计，需补充，并同步到 overview Open Questions。
- 用例格式必须结构化：前置条件、测试步骤（编号、操作、输入参数）、预期结果（每步预期、最终状态）、后置条件。
- 不写场景式叙事；必须包含具体操作、参数、预期值。
- overview.md 内容：
- 元信息：US编号、来源设计文档路径、任务总数、生成时间
- 执行规则：按前置任务字段确定的拓扑序逐个执行；同一时刻只能开发一个任务，不允许并行；多个可开工任务按编号小者优先；标了
依赖任务 的挂账用例不阻断下一个任务
- 任务概览表：编号、任务标题、代码影响模块、前置任务、状态
- 任务依赖链：每行一条
前置 → 后置 关系，如实表达 DAG；无前置任务的起点任务不必列出
- 挂账用例登记：所有标了
依赖任务 的用例都登记到此表（用例编号、所在任务、依赖任务、状态）
- 存疑汇总（Open Questions）：汇总所有 task 中的
【存疑】 和设计文档未决项
- 严格使用模板结构输出，保留所有章节、表格、"执行规则"和"存疑汇总（Open Questions）"。
模板一致性自检清单：
生成后执行"模板契约"自检，并请用户检查 tasks/ 目录下的所有文件。
|__ 若有问题 -> Launch a subagent 根据用户反馈修改 -> 回到本 Phase 的用户检查
|__ 若无问题且无待确认存疑 -> 跳出 Workflow，并给用户简要总结（任务总数、依赖链、是否有 Open Questions），并建议下一步运行 task-dev 开始逐个开发任务。
完成后回调
若不处于 aaw-workflow 编排中，请忽略此节。
本 skill 由 aaw-workflow 编排调用。交付件生成后：
- 返回 aaw-workflow 流程
- 执行
aaw next --sr <SR号> --json 查看进度
- 若返回
deliverables_exist: true → 直接 aaw done --sr <SR> <id>
- 否则 → 停止；是否放行下一步由
aaw-workflow 的 user_confirm 策略控制
不记得 SR 号 → 先 aaw status --json
