| name | review |
| description | 当用户要求代码审查、code review、检查改动质量、提交前审查、质量检查、看看有没有问题，或询问
如何回应审查意见时使用；只查看改动内容而不评估质量时使用 diff。
|
| metadata | {"openclaw":{"emoji":"🔎"}} |
review — 代码审查技能
执行前置
遵循当前目录 AGENTS.md「技能执行公共契约」；仅按需读取技能正文与 reference。
对改动执行系统性审查：早审常审、上下文精确裁剪、问题分级跟进、反馈可反驳。
核心原则：Review early, review often——审查在级联成大问题前拦截它们。
核心原则
- 早审查，常审查：每个任务完成时、大功能实现后、合并到主干前必审；
卡住时/重构前/修完复杂 bug 后也值得审（新视角、基线确认）。
- 审查者上下文精确裁剪：派发审查子代理时给精心构造的上下文（改动描述、
需求/计划、BASE_SHA、HEAD_SHA），绝不传自己的会话历史——审查者应评估
工作产物，不是你的思考过程。
- 问题分级处理：Critical 立即修；Important 继续前修；Minor 记录后修；
审查者的有效反馈不争论，错误反馈用技术推理反驳（展示能证明它工作的
代码/测试）。
- 证据驱动：审查结论基于实际 diff 与运行结果，不凭印象；统计数字实测。
- 验证闭环：审查通过不等于任务完成——修复审查发现的问题后按 debug 循环
回归，再复审查问题是否闭环。
- 不代替实现：审查是评估与报告，修复按 debug/实现流程进行；审查报告
附
文件:行号 定位。
触发时机
- 用户要求审查："审查代码"、"code review"、"审查改动"、"检查改动质量"、
"提交前审查"、"审一下"、"review"、"看看有没有问题"、"质量检查"
- 大功能/任务完成时自检："刚完成的改动审查一下"、"这个任务完成了吗"
- 与其他技能配合：查看改动内容用 diff；修复审查发现的问题用 debug；
审查性能问题用 optim；审查通过后打标签用 tag；纯查看不评估用 diff；
多目标并行审查（多个改动区间/多个文件组）→ dispatch 并行派发审查子代理
工作流程
Step 1. 确定审查对象与区间
- 明确审查范围：工作区改动 / BASE..HEAD 提交区间 / 某功能相关改动；
- 需求与计划（若存在）作为评判标准：
{PLAN_OR_REQUIREMENTS}；
- 记录 BASE_SHA 与 HEAD_SHA：
BASE_SHA=$(git rev-parse HEAD~1)
HEAD_SHA=$(git rev-parse HEAD)
Step 2. 收集审查上下文
- 用 diff 技能先概览改动（
git diff $BASE..$HEAD --stat），确定审查重点文件；
- 整理给审查者的上下文：改动描述（做什么）、需求/计划（应做什么）、
BASE_SHA、HEAD_SHA——不传会话历史。
Step 3. 执行审查（派发审查子代理）
- 派发
general-purpose 子代理执行审查，输入精确上下文：
改动描述、需求/计划、BASE_SHA、HEAD_SHA；
- 审查维度：与需求的一致性、正确性、边界情形、错误处理、测试覆盖、
代码质量（可读/可维护）、调试残留/硬编码/安全隐患；
- 结论按严重度分级：Critical（必须立即修）/ Important（继续前修）/
Minor（记录后修）；每条附
文件:行号。
Step 4. 处理审查反馈
| 严重度 | 处理 |
|---|
| Critical | 立即修复（按 debug 循环），回归验证 |
| Important | 继续前修复，不允许带病前进 |
| Minor | 记录到遗留清单，集中处理或由用户决定 |
| 无效反馈 | 用技术推理反驳（代码/测试证明），不盲目服从 |
- 修复后回归：原审查区间复跑测试（test 方法论），确认问题闭环；
- 需要时二次审查验证修复。
Step 5. 总结（结构化输出）
✓ review 完成
对象: <BASE..HEAD 区间 + 需求/计划>
维度: <审查维度清单>
结论: <Critical X / Important Y / Minor Z，总 N 条>
处理: <已修复 K 条（文件:行号）；记录 L 条；反驳 M 条（理由）>
回归: <修复后测试结果>
遗留: <未处理问题，无则省略>
接收审查（被审查方视角，吸收 obra/superpowers receiving-code-review）
本技能的另一半：当审查意见发给你时（无论来自用户、子代理还是外部审查者），
按"先验证后实现"模式回应——技术正确性优先于社交舒适，不表演性同意、不盲从。
回应模式（六步）：
1. READ 完整读完反馈，不边读边辩解
2. UNDERSTAND 用自己的话复述要求（不清楚就提问）
3. VERIFY 对照代码库实际核验（grep/read/git blame，不凭印象）
4. EVALUATE 对当前代码库是否技术上成立（是否破坏现有功能/是否有全局上下文缺失）
5. RESPOND 技术性确认 或 技术性反驳（附证据）
6. IMPLEMENT 逐项实现，每项独立测试
禁止："你说得对！"、"好点子！"、"谢谢提醒" 等表演性同意/致谢——
直接复述技术要点或直接动手，代码本身证明你听到了反馈。
反馈不清晰：先停下来，把所有不清晰项一次问清再实现——
部分理解 = 错误实现（条目间可能关联）；逐项实现时先修阻塞性问题
（崩溃/安全），再修简单问题（笔误/导入），最后复杂重构，每项独立测试并回归。
反驳时机（有据才反驳）：建议会破坏现有功能、审查者缺全局上下文、
违反 YAGNI（grep 确认该功能无调用方）、技术栈/兼容性不成立、
与用户既定架构决策冲突——用技术推理反驳（引用工作代码/测试），
不防御性争吵；反驳错了就事实性纠正（"核验后你是对的，因为 X，已修正"），
不长道歉、不辩解。
错误处理
| 场景 | 处理 |
|---|
| 审查对象不明确 | 列出候选区间（工作区/最近提交/tag 区间），一次性全部列出提问，不逐次追问 |
| 审查子代理不可用 | 直接审查（同维度），注明未派发子代理 |
| 反馈与代码事实不符 | 用代码/测试反驳，附证据 |
| 发现大量 Critical | 暂停其他工作，逐个按 debug 循环修复并回归 |
| 需求/计划缺失 | 以"改动是否符合其自身描述 + 一般正确性标准"审查并注明 |
| 与 diff 用途混淆 | diff 查看内容；review 评估质量并分级——两者可先后使用 |
| 审查中发现 bug | 转 debug 定位修复（复现→根因→最小修复→回归），审查记录修复结果 |
| 收到审查意见不清晰 | 停止实现，把不清晰项一次问清再动手（部分理解=错误实现） |
| 审查意见与事实不符 | 用代码/测试技术性反驳（引用证据），不表演性同意 |
注意事项
- 审查结论以实际 diff 与运行结果为据，不虚报问题数或通过；
- 子代理审查务必裁剪上下文：给工作产物所需的最小信息，不传会话历史；
- 不越界访问工作目录之外的内容；
- 不删除文件（用户未明确要求时）；本次改动按公共 Git 契约检查，不自动暂存、提交或推送；
