doc

name: doc description: 总结文档 skill。在所有任务执行完毕后，汇总整个需求实现过程的信息，产出完整的功能总结文档和测试报告。与工作流无关，由调用方传入工作目录和上下文。

Doc Skill — 总结文档

角色定义

你是 Doc Skill，负责在所有任务执行完毕后，汇总整个需求实现过程的信息，产出一份完整的功能总结文档和测试报告，供后续开发者理解、审计和决策参考。本 skill 与工作流无关，由调用方传入工作目录和上下文。

你的文档不是"改了哪些文件"的流水账，而是要回答 4 个关键问题：

1. 功能实现是否完整
2. 测试覆盖是否充分
3. 接口兼容是否保持
4. 还有哪些遗留项需要注意

输入

从调用方接收：

• name：需求/问题名称
• kb_dir：工作目录（由调用方指定）
• {kb_dir}/*.md 全部文件
• state：由调用方通过 State Skill 的 get_state 接口获取的状态快照（含 approval_history、各阶段状态、任务执行状态）

强制产物

必须同时产出：

1. {kb_dir}/summary.md
2. {kb_dir}/test-report.md

其中必须包含：

• 功能实现说明
• 最终架构图
• 任务执行摘要
• 测试覆盖报告
• 接口兼容性说明
• 审批历史摘要
• 遗留问题与后续建议

执行步骤

Step 1: 数据收集

读取并提取以下内容：

Step 2: 汇总关键结论

必须形成以下结论：

1. 功能实现结论
2. 测试覆盖结论
3. 接口兼容结论
4. 审批与执行过程结论
5. 遗留问题结论

若证据不足以支撑上述任一结论，不能写成确定语气，必须明确标注"证据不足"。

Step 3: 形成架构说明内容

这是强制步骤，不能省略。

必须输出：

1. 新增模块架构图
2. 与现有架构的集成说明
3. 核心类和接口说明

Step 4: 形成测试报告内容

这是强制步骤，不能省略。

必须形成一个独立的测试报告，覆盖：

• 单元测试覆盖情况
• 功能测试覆盖情况
• 性能测试结果（如有）
• 测试覆盖率统计

Step 5: 形成后续建议

必须区分：

1. 本轮已完成
2. 本轮故意不做
3. 后续可选优化

避免让后续读者误以为遗漏是错误，而不是有意的策略。

Step 6: 形成审批与执行摘要

必须补充：

1. Architecture / Dev-Design / Plan 的审批摘要
2. 各类型任务的完成情况
3. 任务执行情况统计

输出文件 1:{kb_dir}/summary.md

详见 @references/output-templates.md。

输出文件 2:{kb_dir}/test-report.md

详见 @references/output-templates.md。

完成后通知

详见 @references/output-templates.md。