review

name	review
description	当用户要求代码审查、code review、检查改动质量、提交前审查、质量检查、看看有没有问题，或询问 如何回应审查意见时使用；只查看改动内容而不评估质量时使用 diff。
metadata	{"openclaw":{"emoji":"🔎"}}

review — 代码审查技能

执行前置

遵循当前目录 AGENTS.md「技能执行公共契约」；仅按需读取技能正文与 reference。

对改动执行系统性审查：早审常审、上下文精确裁剪、问题分级跟进、反馈可反驳。 核心原则：Review early, review often——审查在级联成大问题前拦截它们。

核心原则

1. 早审查，常审查：每个任务完成时、大功能实现后、合并到主干前必审； 卡住时/重构前/修完复杂 bug 后也值得审（新视角、基线确认）。
2. 审查者上下文精确裁剪：派发审查子代理时给精心构造的上下文（改动描述、 需求/计划、BASE_SHA、HEAD_SHA），绝不传自己的会话历史——审查者应评估 工作产物，不是你的思考过程。
3. 问题分级处理：Critical 立即修；Important 继续前修；Minor 记录后修； 审查者的有效反馈不争论，错误反馈用技术推理反驳（展示能证明它工作的 代码/测试）。
4. 证据驱动：审查结论基于实际 diff 与运行结果，不凭印象；统计数字实测。
5. 验证闭环：审查通过不等于任务完成——修复审查发现的问题后按 debug 循环 回归，再复审查问题是否闭环。
6. 不代替实现：审查是评估与报告，修复按 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)   # 或上一个 tag/分支基线
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 契约检查，不自动暂存、提交或推送；