实现完成后、评审前：用多视角审查简化近期改动且不改变行为

在实现完成、准备代码评审时，系统化简化最近改动的代码，以提升清晰度、复用、质量和效率，同时严格保持行为不变。

适用场景

解决思路

1. 在保持既有行为完全不变的前提下，简化最近改动的代码，目标是清晰度、复用、质量和效率；优先可读、显式的代码，而不是紧凑代码，减少行数不是目标。
2. 按顺序解析简化范围：用户指定的范围具有最高权威，不要擅自扩大。
3. 否则在 git 中，使用当前分支与其 base 的差异；如果没有可用的 base，使用已暂存和未暂存的改动（`git diff HEAD`）。
4. 在 git 之外或没有 diff 时，使用用户指定的文件，或对话中先前编辑过的文件。
5. 如果以上方式都没有产生非空范围，停止并询问用户要简化什么，不要猜测。
6. 询问时使用当前工具列表里已有的宿主阻塞式提问工具；按能力匹配，不要按宿主特定名称匹配。
7. 工具存在于当前工具列表就证明其存在；绝不要调用面向用户的提问工具来探测它是否存在。
8. 如果匹配的工具已列出但未加载，使用宿主的工具发现原语加载该能力；不要搜索其他宿主的工具名。
9. 仅当列表中没有此类工具，或真实提问调用报错时，才回退到宿主用户可见聊天界面的编号选项。
10. 绝不要静默跳过提问。
11. 预检：如果范围内没有实质性人工编写的代码，只有文档、生成文件、vendored 文件、依赖或 lockfile、机械性改动，报告没有可简化的内容并在不启动 reviewer 的情况下停止。
12. 对于混合范围，只保留其中的代码。
13. 预检判断的是改动类型，绝不是大小：明确的小范围仍然执行；任何大小或成本阈值由调用方设置。
14. 当平台的任务跟踪能力可用时，展示 review、apply、verification 结果，但不要为每个 reviewer 创建一个任务；否则继续，不要在聊天中模拟任务列表。
15. 启动 3 个 review agent 并行执行：code-reuse、code-quality、efficiency reviewer。
16. 在可用时通过平台的 subagent 原语调度三个通用 subagent（Claude Code 中为 `Agent`/`Task`，Codex 中为 `spawn_agent`）；否则内联或串行运行 review。
17. 对每个 reviewer，从本 skill 目录读取其 prompt asset，并将完整文件内容作为 subagent 的 prompt 传入，同时传入已解析范围（完整 diff 或文件集），使其拥有完整上下文。
18. 读取并逐字传入 `references/personas/code-reuse-reviewer.md`。
19. 读取并逐字传入 `references/personas/code-quality-reviewer.md`。
20. 读取并逐字传入 `references/personas/efficiency-reviewer.md`。
21. 不要凭记忆转述这些 rubric；必须读取每个文件并逐字传入，否则 reviewer 会丢失保持行为不变所需的规则。
22. 有界调度：将三个 reviewer 排队，并只启动 harness 一次能接受的数量。
23. 并发或 active-agent-limit 错误表示 harness 已满，不是 reviewer 失败：让该 reviewer 保持排队，并在有槽位释放后重试。
24. 当调度无法通过进行中工作、受支持的释放或修正调用恢复时，使用同一 prompt asset 内联运行该 pass，并披露这一替换。
25. Agent 生命周期：在清理前收集终止结果，包括失败。
26. 当 harness 提供调用方拥有的清理能力时，在重新填充槽位、推进阶段或返回前，关闭或释放 review 拥有的 agent。
27. 不要向已经没有剩余工作的已完成 agent 发消息。
28. 不要根据完成或中断推断已释放容量，也不要臆造清理操作。
29. 模型选择：当前 harness 暴露已知覆盖项时，为这些 reviewer 使用平台平衡的中层模型。
30. 在 Claude Code 中，该层级是 Sonnet class。
31. 在 Codex 中，仅当当前 dispatch 原语暴露显式 model 或 custom-agent selector 时才应用该层级；仅凭任务措辞不能选择不同模型。
32. 否则省略覆盖项并继承父模型——在父模型上能跑通的 pass 胜过损坏的调度。
33. 权限模式：在 dispatch 调用上省略 `mode` 参数，以便应用用户配置的权限设置。
34. 只有在三个 review 结果都完成后才继续，无论它们由 subagent 返回还是内联产生。
35. 直接应用有价值的发现；将误报和低价值发现记录为 skipped，不要询问用户。
36. 为评估某个发现，必要时可以检查已解析范围之外，但只编辑该范围及其所需的 import/export 行。
37. 对于用户指定的文件或目录范围，这些 import/export 行也必须位于该范围内；跳过任何会编辑到 mutation boundary 之外的修复。
38. 每个修复都必须保持输出、错误、副作用和顺序不变；如果无法确认，跳过。
39. 如果某个接口或数据形状只存在于当前未发布范围的早期迭代中，一旦确认它在已解析范围之外没有 deployed、persisted、public、external、dependent-branch 或 in-repo caller，它就不再是受保护行为。
40. 仅当所有必需的 caller 更新都符合现有 mutation boundary 时，才移除该兼容路径；否则保留。
41. 绝不要通过简化移除安全检查。保留 trust-boundary validation、data-loss protection、security checks 和 accessibility affordances。跳过任何会削弱或移除它们的发现。
42. 遵守调用方传入的 structure pins。以 structure-pin 约束传入的 plan path 是上下文，不是范围。保留其 `session-settled:` Key Technical Decisions，包括刻意保留的重复或分离。
43. 运行项目级 typecheck 和 lint。
44. 按 blast radius 运行匹配的测试：本地改动跑 scoped tests，共享或广影响改动跑更广测试，测试运行器无法限定范围时跑完整套件。
45. 用检查名称和相关输出报告失败。
46. 修复由简化导致的失败，或回滚责任改动；绝不放松断言、弱化类型或跳过测试。
47. 如果没有配置测试套件、lint 或 typecheck，在总结中明确说明；不要静默跳过验证。
48. 总结哪些部分本来就已经合理，以及哪些得到了改进。
49. 按 reuse、quality、efficiency 报告已应用数量、skipped 数量和检查结果。
50. 如果没有任何改动，说明这一点。
51. 不要使用净删除行数作为成功指标。

适用边界 · 注意事项

• 目标不是修 bug 或排查故障时不要用；此类任务应使用 ce-debug。
• 范围内只有文档、生成或 vendored 文件、依赖或 lockfile、机械性改动时不要用；应报告无可简化并停止。
• 如果简化会削弱安全检查、破坏受保护兼容路径或越过 mutation boundary，不要执行该简化。