审查并简化代码改动：用只读子代理并行检查复用、质量…

当需要审查 git diff 或指定文件范围的代码改动，检查复用、质量、效率、清晰度与规范问题，并可选地应用安全修复时使用。

适用场景

解决思路

1. 根据用户请求选择模式：`review-only`（用户要求审查、审计或检查改动）、`safe-fixes`（用户要求简化、清理或重构改动）、`fix-and-validate`（同 `safe-fixes`，但编辑后还要运行最小相关验证）。若用户未指定，默认：'review'、'audit'、'check' 用 `review-only`；'simplify'、'clean up'、'refactor' 用 `safe-fixes`。
2. 确定范围与 diff 命令，优先顺序：1) 用户明确指定的文件或路径；2) 当前 git 改动；3) 当前 Codex 轮次中早先编辑过的文件；4) 仅当用户要求审查但没有 diff 时，才用最近修改过的已跟踪文件。若没有明确范围，停下来简短说明。
3. 使用 git 改动时，根据仓库状态确定最小的正确 diff 命令：未暂存的工作用 `git diff`；已暂存的工作用 `git diff --cached`；用户明确要求的分支或提交比较用该 diff 目标；暂存与未暂存混合时两者都审查。当有更小的 diff 可用时，不要假设 `git diff HEAD` 是正确默认值。
4. 在审查规范或应用修复前，阅读仓库本地指令文件和相关项目文档，优先使用最接近的适用指导，如 `AGENTS.md`、仓库工作流文档、被触及模块的架构或风格文档，用这些指令区分真实问题与有意的本地模式。
5. 当范围足够大、并行审查有帮助时，启动四个只读审查子代理并行工作；对于很小的 diff 或单个很小的文件，可以本地审查。启动子代理时：给每个子代理相同范围；告诉每个子代理只检查其分配的审查角色；告诉每个子代理处于只读审查阶段；不允许子代理编辑文件、运行 `apply_patch`、暂存改动、提交或执行其他改变状态的操作；要求只返回简洁、结构化的发现；要求每个子代理报告文件、行或符号、问题、建议修复和置信度；要求每个子代理只把发现返回给主代理，不得自行实现修复。
6. 子代理 1：代码复用审查。1) 搜索已有的辅助函数、工具或共享抽象，看是否已解决同一问题。2) 标记改动中引入的重复函数或近似重复逻辑。3) 标记本应调用已有辅助函数却重新实现的内联逻辑。该子代理只读，不得编辑文件、应用补丁或做任何其他工作区改动。推荐角色：`explorer` 用于广泛代码库查找，或 `reviewer` 用于更强的审查。
7. 子代理 2：代码质量审查。1) 冗余状态、缓存值或不必要存储的派生值。2) 因在现有调用链中穿入新参数而造成的参数蔓延。3) 应成为共享抽象的轻微变体复制粘贴。4) 跨模块边界的泄漏抽象或所有权违规。5) 在已有类型化契约、枚举或常量存在时仍使用字符串类型值。该子代理只读，不得编辑文件、应用补丁或做任何其他工作区改动。推荐角色：`reviewer`。
8. 子代理 3：效率审查。1) 重复工作、重复读取、重复 API 调用或不必要的重新计算。2) 本可安全并发运行的顺序工作。3) 在启动、渲染、请求或其他热路径中新增无明显必要的工作。4) 在操作本身可直接尝试并处理错误时，仍做存在性预检查。5) 内存增长、缺少清理或监听器/订阅泄漏。6) 代码只需要子集时却进行过宽的读取或扫描。该子代理只读，不得编辑文件、应用补丁或做任何其他工作区改动。推荐角色：`reviewer`。
9. 子代理 4：清晰度与规范审查。1) 违反本地项目约定或模块模式。2) 不必要的复杂性、深层嵌套、弱命名或冗余注释。3) 过于紧凑或取巧而降低可读性的代码。4) 过度简化，把本应分开的关注点合并成一个不清晰的单元。5) 死代码、死抽象或无价值的间接层。该子代理只读，不得编辑文件、应用补丁或做任何其他工作区改动。推荐角色：`reviewer`。只报告能实质性改善可维护性、正确性或成本的问题，不要仅为让代码看起来不同而搅动代码。
10. 聚合发现：等待所有审查子代理完成，然后合并它们的发现。主代理负责此步骤，把子代理输出仅视为审查输入，而不是把代码改动再委托出去的许可。将发现规范化为：1) 文件和行或最近符号；2) 类别：复用、质量、效率或清晰度；3) 为什么是问题；4) 建议修复；5) 置信度：高、中或低。编辑前丢弃薄弱、重复或与指令冲突的发现。
11. 谨慎修复问题：在 `review-only` 模式下，报告发现后停止。在 `safe-fixes` 或 `fix-and-validate` 模式下：只有主代理应用修复；只应用高置信度、保持行为的修复；跳过需要产品或架构判断的主观重构；当本地模式是有意或指令支持时保留它们；除非完成修复正确性需要小的相邻改动，否则保持编辑范围限于被审查文件。优先修复如：用已有辅助函数替换重复代码；移除冗余状态或死代码；在不改变行为的情况下简化控制流；收窄过宽操作；在范围可控时重命名不清晰的局部变量。不要作为此技能的一部分暂存、提交或推送改动。
12. 在需要时验证：在 `fix-and-validate` 模式下，主代理完成编辑后，对触及范围运行最小的相关验证。例如：针对被触及模块的定向测试；针对被触及目标的类型检查或编译；如果这是项目真正的安全门，则运行格式化或 lint 检查。优先快速、范围有限的验证，而不是全量套件运行，除非改动广度证明需要更多。如果因用户要求不运行而跳过验证，明确说明。
13. 总结结果：以简短结果收尾：审查了什么；修复了什么（如有）；有意保留了什么；是否运行了验证。如果代码按此标准已经干净，直接说明，而不是制造编辑。

适用边界 · 注意事项

• 没有明确范围时（用户未指定文件、路径，也没有 git 改动或早先编辑的文件），不要继续，应停下并简短说明。
• 对于很小的 diff 或单个很小的文件，不必启动并行子代理，可本地审查。
• 不要仅为让代码看起来不同而搅动代码，也不要应用需要产品或架构判断的主观重构。