用途
本技能用于审查 git diff 或用户明确指定的文件范围，检查改动在代码复用、代码质量、效率、清晰度与规范方面的问题，并可选地应用安全的 Codex 驱动修复。
主要能力
- 支持三种模式：
- review-only：用户要求审查、审计或检查改动时使用。
- safe-fixes：用户要求简化、清理或重构改动时使用。
- fix-and-validate：与 safe-fixes 相同，但在编辑后还会运行最小相关验证。
- 若用户未指定模式，默认规则为：对“review”“audit”“check”使用 review-only；对“simplify”“clean up”“refactor”使用 safe-fixes。
- 通过四个只读 Codex 子代理并行审查：代码复用审查、代码质量审查、效率审查、清晰度与规范审查。
- 子代理仅检查代码并将发现回传主代理，不得编辑文件、运行 apply_patch、暂存、提交或执行其他改变状态的操作。
- 只有主代理可以应用高置信度、保持行为不变的修复。
使用方式
- 确定范围与 diff 命令：优先使用用户明确指定的文件或路径；其次使用当前 git 改动；再次使用当前 Codex 轮次中较早编辑的文件；仅当用户要求审查但没有 diff 时，才使用最近修改的已跟踪文件。若没有明确范围，则停止并简要说明。
- 根据仓库状态选择最小的正确 diff 命令：未暂存工作用 git diff；已暂存工作用 git diff --cached；用户明确要求的分支或提交比较使用该精确 diff 目标；混合暂存与未暂存则两者都审查。不要在有更小 diff 可用时默认假设 git diff HEAD 是正确的。
- 在审查规范或应用修复前，阅读仓库本地指令文件和相关项目文档，优先使用最接近的适用指南，如 AGENTS.md、仓库工作流文档、被触及模块的架构或风格文档，以区分真实问题与有意的本地模式。
- 当范围足够大、并行审查有帮助时，启动四个只读审查子代理，给每个子代理相同范围，告知其仅检查分配的审查角色，并处于只读审查阶段，要求只返回简洁、结构化的发现，包含文件、行或符号、问题、建议修复和置信度。
- 等待所有审查子代理完成后，由主代理合并发现，归一化为：文件与行或最近符号、类别（复用、质量、效率或清晰度）、为何是问题、建议修复、置信度（高、中、低）。在编辑前丢弃薄弱、重复或与指令冲突的发现。
- 在 review-only 模式下，报告发现后停止。在 safe-fixes 或 fix-and-validate 模式下，仅由主代理应用高置信度、保持行为不变的修复，跳过需要产品或架构判断的主观重构，保留有意或指令支持的本地模式，编辑范围限于被审查文件，除非完成修复正确性需要小的相邻改动。不要暂存、提交或推送改动。
- 在 fix-and-validate 模式下，主代理完成编辑后，对触及范围运行最小相关验证，例如针对被触及模块的定向测试、类型检查或编译、格式化或 lint 检查。优先快速、范围明确的验证，除非改动广度需要更大范围。若因用户要求跳过验证，需明确说明。
- 最后简要总结：审查了什么、修复了什么（如有）、有意保留了什么、是否运行了验证。若代码已符合该标准，直接说明，不要制造编辑。
适用场景
- 需要审查 git diff 或指定文件范围的代码改动。
- 希望从复用、质量、效率、清晰度与规范多角度检查代码。
- 希望在审查后安全地应用保持行为不变的简化或清理修复。
- 希望在修复后运行最小相关验证。
限制
- 子代理必须保持只读，不得编辑文件、运行 apply_patch、暂存、提交或执行其他改变状态的操作。
- 只有主代理可以应用修复。
- 仅应用高置信度、保持行为不变的修复。
- 跳过需要产品或架构判断的主观重构。
- 不暂存、提交或推送改动。
- 若没有明确范围，则停止并简要说明。
- 仅报告能实质性提升可维护性、正确性或成本的问题，不要仅为让代码看起来不同而改动。