DiAL/docs/prompts/prompt-apply-review.md

审查 OpenSpec apply 完成后以及后续手动修补后的实际实现，判断代码、测试、变更文档是否一致，识别偏离、漏记和可优化点，并将确认后的实际变更同步回变更文档，按以下流程执行。

约束

• 先审查再修复；未经用户确认，不修改代码或变更文档
• 默认按 spec-driven workflow 审查；识别 change 后先确认 schemaName；若实际 schema 不同，说明差异，仅对实际存在的 artifacts 做审查
• 禁止同步或修改 openspec/specs/ 下的主规范——主规范同步属于 archive 阶段，不在此提示词范围内；本次 change 目录下的 specs/*.md、代码、测试、README 等均可修改
• 优先使用当前会话中的实现说明、测试结论、手动修补记录和已生成的变更文档；仅在无法明确 change、schemaName、改动范围或修补来源时，再用提问工具或 OpenSpec 命令补充定位
• 不要因为代码已经存在就自动以代码为准；先判断差异属于"文档要求未实现"、"测试后新增修补"还是"意外偏离/回归"
• 每批代码或文档修改执行前用提问工具获得用户确认
• 删除/重写前用提问工具获得用户确认，并先备份原文件为 {file}.bak.{timestamp}
• 若修改代码涉及新逻辑、模块结构、API、实体或用户可见行为，同步更新测试、相关变更文档和 README

1. 收集

读取约束：

• 直接使用 Read 工具并行读取文件，禁止使用 subagent/Task 工具做文件读取和内容转发
• 不原样输出文件内容，仅在步骤 2 输出审查结论

分步收集：

a) 先并行读取核心入口和配置，确定范围：

• 本次 change 的 proposal.md
• openspec/config.yaml

b) 从 proposal.md 提取 Capabilities / Modified Capabilities，确定 proposal 已声明的 spec 列表

c) 并行获取改动范围：git diff --name-only、git diff --name-only --cached；若工作区已干净，再结合文档和代码模块反推

d) 对比 git diff 涉及的模块与 proposal 已声明的 spec，识别 apply 阶段新增改动触及但 proposal 未覆盖的现有 spec，合并为完整 spec 读取列表；相关性来源还包括：手动修补涉及的受影响能力、design.md Impact 中提到的模块、相关代码对应的现有能力

e) 并行读取完整 spec 列表和其余 artifacts（design.md、tasks.md、相关源码、测试文件、README、架构文档）

f) 收集当前会话中与本次变更相关的实现说明、apply 过程中的偏离、测试失败、手动修补原因、待确认事项

若当前上下文无法明确 change 或文档路径：

• 先用提问工具让用户确认 change 名称或文档范围
• 仍无法确认时，再执行 openspec status --change "{name}" --json 和 openspec instructions apply --change "{name}" --json 辅助定位

若已明确 change，但尚未确认 schemaName，先读取 change 元数据或执行 openspec status --change "{name}" --json 确认。

若缺少测试结果或手动修补记录，明确说明本次无法可靠判断部分差异的来源，仅能基于代码与文档现状审查。

2. 分析

按以下优先级检查：

优先级	维度	检查点
P0	实际实现与测试结论	当前代码的真实行为是什么；apply 后是否有手动改动或测试后修补；测试是否证明这些实现有效；若缺少测试结果，标记相关结论为"未验证"；检查是否存在回归、未覆盖场景或被掩盖的问题
P1	文档同步性	对本次 change 目录下实际存在的 artifacts 检查：已落地的实现、测试后新增修补、边界处理、异常路径、验证结论是否已同步回变更文档；若影响模块结构、API、实体或用户可见行为，再检查 README 是否同步
P2	Spec 覆盖完整性	对比实际代码改动范围与 proposal 中定义的 Capabilities / Modified Capabilities，识别 apply 阶段新增的功能是否触及了更多现有 spec；若触及，列入补充清单，在本次 change 的 specs 中新增对应的 spec 文件，并更新 proposal.md 的 Modified Capabilities
P3	文档要求覆盖	对实际存在的 artifacts 检查：文档中承诺的目标、方案、Requirement、Scenario 是否都已实现；在 spec-driven 下重点检查 proposal.md、design.md、specs/*.md、tasks.md
P4	实现质量	代码结构、复用、命名、复杂度、错误处理、测试质量、与项目现有模式的一致性是否存在明显问题或可优化点

分析时区分三类差异：

• 文档要求已明确，但代码未实现或实现不完整 → 需补充代码或测试
• 代码因测试暴露问题、手动修补或合理落地细化而新增/变更 → 需回写文档
• 代码与文档不一致，且无法判断应以哪边为准 → 列入待确认清单

不要把以下情况直接视为合理修补：

• 通过 skip、only、弱化断言、绕过错误处理来让测试通过
• 为了贴合现有代码而降低已确认的 Requirement 或行为约束
• 未经过讨论和验证就扩大功能范围

重点识别：

• 文档要求但未落地的功能、场景、异常处理或验证步骤
• apply 完成后新增的代码修补、边界处理、接口调整、行为变化未同步到文档
• tasks.md 标记完成，但代码、测试或文档未闭环
• Modified Capabilities 在本次 change 的 specs 中是否已更新（注意：仅更新 change 目录下的 specs，不动 openspec/specs/）；apply 阶段新增功能触及的未覆盖 spec 是否已补充到本次 change 的 specs/ 目录
• 代码存在明显的重复、复杂度过高、命名不清、错误处理薄弱、测试质量不足等问题

输出审查结果：

1. 问题总览表：问题类型 × 涉及文件数
2. 实际改动与修补清单：本次实现中已落地的主要功能、后续修补和验证结论；若缺少测试结果，对未验证部分单独标记
3. 未覆盖清单：文档要求但未在代码中实现或未充分验证的内容
4. 需回写文档清单：代码和测试中已确认、但文档未体现的实现、修补或约束变化
5. 方向待确认清单：代码与文档不一致，且无法判断应以哪边为准的事项
6. Spec 补充清单：apply 阶段新增功能触及但 proposal 未覆盖的现有 spec，列出需新增的 spec 文件名、对应的主 spec 路径、需描述的变更内容
7. 任务状态问题清单：未真正完成、状态错误或需补充的新任务
8. 测试问题清单：缺失覆盖、掩盖错误、验证不足或修补后未回归验证的测试问题
9. 代码质量/优化清单：可优化的实现问题和建议
10. 逐项分析：每个问题说明位置、问题、影响、建议和建议修复方向

若所有清单均为空，输出"审查通过，未发现问题"，跳至步骤 5。

3. 计划（用户确认）

先针对"方向待确认清单"用提问工具逐项向用户确认。

再整理完整修复方案，按类别列出：

• 代码或测试补充：补实现、补异常处理、补回归测试、修复掩盖错误的测试
• 文档回写：同步本次 change 目录下的 proposal.md、design.md、tasks.md、specs/*.md、README 中遗漏或过时的内容（禁止同步到 openspec/specs/）
• Spec 补充：将 apply 阶段新增功能触及的现有 spec 复制到本次 change 的 specs/ 目录并更新，同步更新 proposal.md 的 Modified Capabilities
• 任务状态修正：修正已完成/未完成状态，补充 apply 后新增但已完成的修补任务或验证任务
• 代码质量优化：在不改变目标行为的前提下优化结构、复用、命名或可维护性

对每个拟修改的文件说明：

• 修改内容
• 修改原因
• 预期影响
• 验证方式
• 若存在分支方案，分别说明适用前提

用提问工具展示完整修复方案，获得用户确认后执行。

4. 执行

逐项执行已确认的代码、测试和文档修复。

若涉及删除或重写：

• 先创建备份文件 {file}.bak.{timestamp}
• 再执行修改

若修改了代码或测试：

• 同步更新相关变更文档；若影响模块结构、API、实体或用户可见行为，再同步 README
• 运行相关测试；若修补影响范围较大，再补充执行受影响的回归测试

若修改了文档：

• 确认本次 change 目录下的变更文档之间保持一致；重点检查 proposal.md、design.md、tasks.md、specs/*.md
• 若 apply 后新增修补改变了能力边界或行为约束，同步更新本次 change 的 Capabilities / Modified Capabilities
• 若"Spec 补充清单"中有需新增的 spec：先从 openspec/specs/ 复制对应的原 spec 到本次 change 的 specs/ 目录，再基于实际改动更新其内容；禁止修改 openspec/specs/ 下的原文件
• 禁止将本次 change 的 specs 同步到 openspec/specs/，该操作属于 archive 阶段

执行后重新读取所有被修改的代码、测试和文档，并复核：

• "未覆盖清单" 是否已清空或已标注保留原因
• "需回写文档清单" 是否已清空
• "Spec 补充清单" 是否已清空或已标注保留原因
• "方向待确认清单" 是否已清空或已记录用户决策
• "任务状态问题清单" 和 "测试问题清单" 是否已清空或已标注残留原因
• "代码质量/优化清单" 中哪些已处理，哪些有意延期

5. 收尾

列出所有修改的文件、备份文件、测试命令与结果、文档同步摘要和剩余风险。

若本次因缺少测试结果、修补记录或上下文而降级执行，或有问题因信息不足暂未处理，单独说明。