用途
Simplify 是一个“评审前清理关卡”。它的目标不是给出正式批准，而是在正式评审之前检查已改动的代码，寻找可复用机会、代码质量问题和效率问题，并修复其中值得处理的部分，同时不改变代码行为。
何时使用
- 用户希望在 reviewer 或 code-reviewer 之前执行一次 /simplify 风格的清理。
- 某个功能已完成，且 diff 中可能存在重复、粗糙边缘或可避免的低效。
- 希望在正式评审前减少可避免的评审意见。
- 改动涉及足够多的文件或逻辑，单次简化不足以覆盖。
不适用场景
- 微小 diff，单次局部清理即可。
- 会改变需求的行为变更、功能开发或缺陷修复。
- 跨未触及模块的大型架构重设计。
- 正式规格验证或安全审查。
在评审流程中的位置
推荐顺序：implement -> simplify -> code-reviewer 和/或 reviewer -> receiving-code-review。
以下情况可跳过完整的三代理流程：改动很小且显而易见；只改了一两行琐碎代码；用户希望直接进入正式评审而非清理。
工作流程
阶段 1：识别改动
- 如果用户给出 base/head 范围，使用该范围。
- 如果存在已暂存改动，检查 git diff HEAD，以同时包含已暂存和未暂存改动。
- 否则使用 git diff。
- 如果没有 git diff，则审查用户提到的或本会话中你之前编辑过的最近修改文件。
- 为审查者保留一份紧凑的受影响文件摘要以及完整 diff 文本。
阶段 2：阅读本地标准
- 先检查本地说明，例如 AGENTS.md、仓库约定以及相关技能。
- 遵循受影响文件中已有的命名、格式和结构。
- 如果本地约定与通用清理偏好冲突，以本地约定为准。
阶段 3：并行启动三个审查代理
对于中等或大型 diff，在单轮中并行启动三个只读子代理。尽可能使用 explorer 代理，因为这是代码库分析而非实现。
每个代理必须收到：完整 diff、受影响文件列表、清理约束（不改变行为、不编辑、只报告发现）。
三个审查领域：
- 代码复用审查
- 代码质量审查
- 效率审查
提示模板位于：
- references/reuse-reviewer.md
- references/quality-reviewer.md
- references/efficiency-reviewer.md
重要事项：
- 审查代理是只读的，不编辑文件。
- 主代理汇总发现并执行修复。
- 不要并行启动多个工作代理编辑同一批受影响文件。
阶段 4：修复有价值的问题
- 等待所有审查者完成。
- 汇总发现并去重。
- 如果问题能在不改变行为的前提下改进代码，直接修复。
- 如果某个发现是误报或不值得改动，记录下来并跳过，不必长篇争论。
阶段 5：验证
- 对改动区域运行最窄范围的有意义验证。
- 优先运行针对性测试，然后视情况运行 lint/build。
- 如果没有自动化验证，明确说明并提及残余风险。
- 简要总结修复内容，或说明代码已经足够干净。
快速参考
- 可读性：偏好清晰命名、显式分支、小而连贯的辅助函数；避免密集单行和取巧写法。
- 范围控制：偏好受影响文件、最近 diff、用户指定路径；避免未经请求的全仓库清理。
- 安全性：编辑后做针对性验证；避免假设重构一定安全。
- 注释：说明意图和约束；避免叙述显而易见的代码。
- 代理使用：三个并行只读审查者，一个控制者应用修复；避免多个编辑代理触碰同一批文件。
常见错误
- 把简化变成重设计。
- 过早提取抽象。
- 在无关文件间大范围重命名。
- 为减少行数而优化，而非为更易维护而优化。
- 因为改动“看起来是机械性的”而跳过验证。
- 让三个代理都编辑代码，而不是只报告发现。
- 用该技能替代正式评审或规格验证。
上游参考
该 Codex 技能将 Claude 工作流中使用的 /simplify 流程改编为 Codex 原生技能。源说明和改编细节见 references/upstream-agent.md。