task-dev

name

task-dev

description

根据 task-split 生成的独立任务文件逐个开发 task，执行实现、为用例编写自动化测试代码并跑通、输出总结并更新任务文件和 overview 状态。Use when the user asks to 开发详细任务、实现独立任务、开发 task 文件、执行 T1/T2、继续开发带用例的任务。Also trigger when the user references a tasks/ directory with independent task files (T1-*.md, T2-*.md) and wants to implement one of them. Make sure to use this skill whenever the user mentions task files from task-split, wants to start coding based on detailed task files with test cases, or asks to continue development work from a tasks/ directory.

US Task Dev Detailed

基于 task-split 生成的独立任务文件（tasks/ 目录），逐个 task 进行开发实现。每次只处理一个 task，完成后输出任务总结并更新任务文件和 overview 状态。

输入格式

本 skill 处理 task-split 生成的多文件格式：

./.sdd/[SR编号]/[AR编号]/tasks/
├── overview.md              # 任务概览和执行规则
├── T1-[任务标题].md         # 独立任务文件
├── T2-[任务标题].md
└── ...

每个任务文件包含：

• 任务元信息（编号、前置任务、执行顺序、工作量、模块、交付文件）
• 详细设计（背景目标、代码影响、实现方案、接口设计、非功能约束）
• 用例设计（结构化用例：前置条件/测试步骤/预期结果/后置条件）
• DoD Checklist
• 总结（初始为空，完成后填写）

Execution Discipline

task-dev 是严格串行任务执行技能。必须遵守以下规则：

• 遵循项目级 Spec（如存在）：开始开发前检查项目根目录的 .sdd/spec.md。若该文件存在，必须完整读取并在需求理解、实现、测试和验收中遵循其中的规范；若不存在，则跳过此检查，不将其视为阻塞条件。
• 锁定单一任务：一旦确定当前任务编号，本轮只允许读取、修改、验证和总结该任务范围内的内容。不得在该任务完成前开始实现其他任务。
• 按前置任务拓扑序执行：当前任务的所有前置任务（任务文件任务元信息中的前置任务字段）必须都为 Completed 才能开始；同一时刻只能开发一个任务，不允许并行。若用户指定的任务前置任务未全部完成，停止并提示必须先完成的前置任务。
• 多个可开工任务按编号小者优先：若多个 Pending 任务的前置任务都已完成，选编号最小的那个。
• DoD 未通过阻断下一个任务，挂账用例例外：当前任务的 DoD 项必须全部通过才能标记 Completed 并开始下一个任务。唯一例外：未通过项是测试用例且该用例标了 依赖任务: T[X]，则该用例视为挂账、登记到 overview 挂账用例登记表，不阻断当前任务标记 Completed 和下一个任务开始；待 T[X] 完成时提示回归。
• 完成后再移动：当前任务必须完成实现、用例验证、DoD checklist 更新、总结写入、overview 状态更新后，才允许推荐或进入下一个任务。
• 用例实现与验证：每个任务的用例设计必须先编写自动化测试代码（或手动验证清单），再运行确保全部通过；标了 依赖任务 的用例挂账登记；结果记录到总结。
• 连续执行也逐个提交：若用户明确要求连续完成多个任务，也必须按"选择一个任务 -> 完成并更新文件 -> 重新读取任务状态 -> 选择下一个任务"的循环执行，不能交叉开发多个任务。

Workflow

先建立 todo list，并按以下流程执行。

1. 定位 tasks 目录和 overview

• 优先使用用户指定的 tasks 目录路径（默认 ./.sdd/[SR编号]/[AR编号]/[模块名称]_tasks/）。
• 若用户未指定，在当前工作目录下查找包含 overview.md 和 T*.md 文件的 tasks/ 目录。若有多个匹配，列出供用户选择。
• 读取 overview.md，提取任务概览表和执行规则，确认任务总数和当前状态。
• 检查存疑汇总（Open Questions）：读取 overview 的"存疑汇总"章节，若存在任何存疑项，必须先逐条向用户列出（存疑编号、存疑项、涉及任务、待确认问题），由用户确认处置方式（已解决/可忽略/需要先解决）后才能继续。若用户表示某条存疑未解决且影响当前任务实现，停止开发并提示用户先解决存疑。

2. 确定要开发的任务

两种模式，优先响应用户的显式指定：

模式 A：用户指定任务编号

• 用户说"实现 T1"、"开发 T3"等，定位对应的 T[N]-*.md 文件。
• 检查该任务是否可开工：
  • 读取该任务文件的任务元信息中前置任务字段（若字段缺失，回退按编号顺序的前一个任务）。
  • 从 overview.md 读取任务概览表，确认所列前置任务的状态是否都为 Completed。
  • 若前置任务未全部完成，不得开始实现该任务；报告"必须先完成 [前置任务编号]"并列出阻塞任务。
• 若该任务已标记为 Completed，提醒用户确认是否要重新开发。

模式 B：自动推荐下一个任务

• 从 overview.md 的任务概览表中筛选所有状态为 Pending 或 In Progress 的任务。
• 对每个候选任务，读取其前置任务字段，保留所有前置任务都为 Completed 的候选。
• 在可开工的候选中，按编号小者优先选择。
• 若所有 Pending 任务的前置任务都未完成，告知用户当前无可开工任务并列出阻塞链。
• 若所有任务都已完成，告知用户"所有任务已完成"。

3. 读取任务文件和开发上下文

确定任务后，读取以下材料：

• 项目级开发规范（如存在）：检查项目根目录 .sdd/spec.md。若存在，完整读取并将其中要求纳入开发要点；若不存在，直接忽略。
• 当前任务文件：[模块名称]_tasks/T[N]-[任务标题].md，完整读取所有章节：
  • 任务元信息（前置任务、执行顺序、工作量、模块、交付文件）
  • 详细设计（背景目标、代码影响表格、流程图、实现方案、接口设计、非功能约束）
  • 用例设计（所有结构化用例）
  • DoD Checklist
• 项目结构：浏览项目的目录结构，了解代码组织方式。若项目中存在 software_architecture.md，读取该文件理解模块边界。
• 相关代码：根据任务文件"代码影响"表格中的修改文件，读取当前代码现状。如果涉及接口调用或依赖，也读取相关文件。
• 前置任务产出：若当前任务的前置任务字段非"无"，读取所有前置任务文件的总结章节，理解其变更和关键决策。

将收集到的上下文整理为开发要点摘要。若任务文件中存在 【存疑】 且影响实现，向用户提问确认；否则直接进入开发阶段。

4. 实现任务

根据任务文件的详细设计和实现方案，实现代码。

• 按照"详细设计"章节中的流程图、实现方案、接口设计、错误处理、非功能约束进行实现。实现过程中对照流程图确认本任务的接口与上下游 task 的调用关系一致，不得偏离原图。
• 严格遵循项目中已有的代码风格和命名约定。
• 当前任务未完成前，不得顺手实现后续任务的功能。若发现后续任务需要的前置改动，记录到当前任务总结中，不提前开发。
• 如果任务文件中标记了 【存疑】 的内容影响当前实现，不要猜测——向用户提问确认后再继续。
• 如果实现过程中发现详细设计与实际情况有冲突（如接口签名不匹配、依赖模块行为不同），暂停并向用户报告，由用户决定是否调整设计或实现方式。

5. 用例实现与验证

本阶段做两件事：(A) 为每个用例编写自动化测试代码（或准备手动验证清单），(B) 运行并确保全部通过。任务文件"用例设计"里的用例是规格说明，不是可执行代码——必须先把它落成测试代码，再跑通。

(A) 编写测试代码

对每个用例（TC-T[N]-01、TC-T[N]-02...）：

1. 检查依赖任务字段：若该用例标了 依赖任务: T[X]，跳过本任务的测试代码编写和运行，标为"待回归（依赖 T[X]）"，登记到 overview 挂账用例登记表，不视为 DoD 失败。
2. 解除存疑：若用例"前置条件"或"预期结果"中有 【存疑】，先与用户确认，再编写测试代码。
3. 编写自动化测试代码：按用例的"前置条件/测试步骤/预期结果/后置条件"编写单元测试/集成测试，覆盖每个步骤的预期值；测试代码与实现代码同提交。
4. 无法自动化时改为手动清单：若项目无测试框架或用例不适合自动化，按"测试步骤"逐步列出操作和预期，准备一份手动验证清单，不写测试代码。

(B) 运行并确保通过

1. 运行本任务编写的所有自动化测试代码；手动用例按清单逐步执行。
2. 对比实际输出与用例"预期结果"，确认每步匹配。
3. 通过的用例标记 ✅；失败的用例优先修复实现代码使其符合用例预期，而非改测试迁就实现。若确属测试代码或用例描述本身有误，先与用户确认后再改测试或用例描述，再重跑。重复直到通过。
4. 执行用例"后置条件"清理测试数据、恢复状态。
5. 记录用例验证结果到总结（用例编号 + 通过/失败/挂账）。

6. DoD 验证

根据任务的 DoD checklist 逐项验证：

• 功能项：确认每个功能验收点的代码实现符合描述。
• 测试项：分两步确认——"编写用例"：所有非挂账用例已编写自动化测试代码（或手动验证清单）；"运行用例"：所有非挂账用例运行通过；挂账用例已登记到 overview 挂账用例登记表。
• 文档项：确认需要更新的文档已完成。
• 可观测性项：确认关键路径已添加必要的日志/指标/追踪。

验证过程中：

• 通过的项目，在任务文件中勾选对应 checklist（将 - [ ] 改为 - [x]）。
• 未通过的项目，修复后重新验证。若未通过项是测试用例且该用例标了 依赖任务: T[X]，按挂账处理（见上一步）；其他未通过项不得标记 Completed，必须修复或与用户协商调整。

7. 输出任务总结

在任务文件的 ## 总结 章节写入任务总结。总结格式如下：

## 总结

### 变更摘要
- **修改文件**：[列出所有新建和修改的文件]
- **核心实现**：[1-3 句话描述核心逻辑]
- **关键决策**：[如有偏离详细设计的决策，说明原因]

### 用例验证结果
- TC-T[N]-01：✅ 通过
- TC-T[N]-02：✅ 通过
- TC-T[N]-03：❌ 失败 - [失败原因]
- TC-T[N]-0X：⏸ 挂账 - 依赖 T[Y]，待 T[Y] 完成后回归
- ...

### 遇到的问题
- [问题1：描述 + 解决方式]
- [问题2：描述 + 解决方式]
（如无问题，写"无"）

### 对后续任务的建议
[如有对后续任务实现有帮助的信息，写在这里；否则省略此节]

总结要简洁、聚焦于对验证和后续任务有参考价值的信息。

8. 更新任务文件和 overview

更新任务文件（[模块名称]_tasks/T[N]-*.md）：

• DoD checklist 勾选状态（[ ] → [x]）
• 总结章节内容

更新 overview（[模块名称]_tasks/overview.md）：

• 在任务概览表中，将该任务的状态从 Pending 或 In Progress 改为 Completed
• 若当前任务有用例标了 依赖任务，往"挂账用例登记"表追加对应行（用例编号、所在任务=当前任务、依赖任务、状态=Pending）
• 若当前任务完成后，扫"挂账用例登记"表中 依赖任务 = 当前任务 且状态为 Pending 的条目，向用户报告"有 N 条挂账用例可回归，位于 T[Y]，用例编号 ..."，由用户决定是否现在跑；用户选择回归时，逐条执行验证并更新状态为 Passed/Failed

更新完成后，向用户报告：

• 完成的任务编号和标题
• DoD 通过情况（全部通过 / 挂账 N 条用例 / 其他部分通过及原因）
• 用例验证结果（X/Y 通过，Z 条挂账）
• 下一个可开工任务编号（如果有）
• 可回归的挂账用例提示（如果有）

9. 推荐下一步

若还有未完成任务，推荐下一个任务编号和标题，但不自动开始，除非用户明确要求连续执行。

Quality Gates

实现完成、输出总结前，逐项自检：

• 本轮只实现了锁定的当前任务，没有提前实现其他任务。
• 已检查项目根目录 .sdd/spec.md；若该文件存在，当前任务的实现、测试和验收均已遵循其中的规范。
• 开工前已检查 overview"存疑汇总"章节；若存在存疑项，已向用户逐条确认处置方式，不存在存疑未解决就擅自推进的情况。
• 当前任务的所有前置任务都已为 Completed；若用户指定的任务前置任务未全部完成，本轮未进行实现。
• 在多个可开工任务中，按编号小者优先选择了当前任务。
• 任务实现与任务文件"详细设计"章节描述一致（如有偏离，已在总结中说明原因）。
• 任务文件"用例设计"中的每个用例都已编写自动化测试代码（或手动验证清单）并运行通过；"编写用例"和"运行用例"两步都完成；标了 依赖任务 的用例已挂账登记、未阻塞 DoD 通过。
• DoD checklist 中的每一项都已执行；未通过项若非挂账用例，本轮未标记 Completed。
• 代码遵循项目现有风格和约定。
• 没有遗留 【存疑】 相关的猜测性实现。
• 任务总结包含变更摘要、用例验证结果、遇到的问题。
• 任务文件和 overview 都已更新。

Output Rules

• 代码输出遵循项目现有代码风格。
• 任务总结使用 Markdown，写入任务文件的 ## 总结 章节。
• 任务文件和 overview 更新后写回原文件路径。
• 如果用户要求仅在对话中展示总结，则不更新文件。
• 最终报告只推荐下一个任务编号，不自动开始下一个任务，除非用户明确要求连续执行。
• 使用简洁、工程化语言。

Template Contract

• 读取任务文件格式遵循 task-split 的 references/task_template.md 模板结构。
• 任务总结写入模板中的 ## 总结 章节。
• DoD checklist 更新格式：- [ ] → - [x]。
• overview 更新格式：任务概览表中对应行的"状态"列从 Pending 改为 Completed。

完成后回调

若不处于 aaw-workflow 编排中，请忽略此节。

本 skill 由 aaw-workflow 编排调用。交付件生成后：

1. 返回 aaw-workflow 流程
2. 执行 aaw next --sr <SR号> --json 查看进度
3. 若返回 deliverables_exist: true → 直接 aaw done --sr <SR> <id>
4. 否则 → 停止；是否放行下一步由 aaw-workflow 的 user_confirm 策略控制

不记得 SR 号 → 先 aaw status --json