Code Review

当前通用版本包含基于 Tw93 / Waza 的 check 技能 改编的资料与脚本，保留 Tw93 的 MIT 版权声明。它与 Claude Code 官方插件的同名 PR 审查命令是不同入口；不要把官方插件的固定多代理、评分或自动评论步骤套到这里。

先确定审查目标和程度，找出候选缺陷，逐条尝试证伪，只报告经得起验证的发现。以正确性、安全和合同为主。补丁必要性与结构退化由 patch-audit 承接；仅在用户要求补丁必要性或可维护性复审，或符合其自动触发条件时按相关章节审查，复用已有结论，不另跑整套流程。普通局部实现和文件行数增长本身不触发。较大范围的架构减法交给 $prune。只读审查中仅报告，不因转交技能扩大修改权限。发布检查和已授权交付交给 $check。

用法

参数只表示审查范围和方式，不是 shell 命令。顺序不限。

$code-review [程度] [目标] [--fix] [--comment]

• 程度：low | medium | high | xhigh | max，未指定时用 medium。
• 目标（未指定时审查工作区相对 HEAD 的全部未提交改动，包含暂存、未暂存和未跟踪的文本文件）：
  • --staged：只审查暂存区。
  • PR/MR 链接或编号，如 123 或 #123：先从链接、远端和项目规则确定托管平台与仓库，再用可用的对应 CLI/API 取得标题、描述、基线和 diff。gh 仅用于 GitHub；仅有编号且仓库有歧义时才澄清。
  • 分支或引用，如 feature/x、--ref=main：分支目标审查 git merge-base <默认分支> <分支>..<分支>；--ref=<引用> 审查当前工作区相对该引用的差异。
  • 路径，如 src/foo.ts src/bar/：只审查这些路径上的改动；路径没有改动时审查这些文件的当前内容，并在报告中说明。
• --fix：审查结束后把确认的发现直接修到工作树。
• --comment：把发现作为 PR 行内评论发布，只适用于 PR 目标。

边界

• 默认只读：不修改、不暂存、不提交。带 --fix、用户明确要求修复，或同任务已有有效修复授权时才修改。
• --comment 是对外发布：先形成可审阅的完整评论（文件、差异侧、行号、正文），按当前请求与项目规则确认相应发布授权。已有明确授权不重复确认；仅要求审查或草稿不发布。不代替用户提交 approve / request changes 等额外审查决定。
• 先读项目指令（AGENTS.md 等），用 git status --short --branch 确认目录和分支。共享工作区里有与目标无关的改动时，不把它们纳入审查，也不去动它们。
• 调试脚本、复现用例放系统临时目录，结束时清理。
• 已有同任务修复授权有效时继续，不因本轮审查重复索要授权。提交、推送及对外评论仍遵守各自动作的授权。

程度

程度决定调查的广度和报告门槛，不决定语气。

low/medium 宁缺毋滥。high 以上可以报告 PLAUSIBLE，但必须写出触发条件，不堆砌猜测。程度不是固定工具配额：已有证据足够时不机械新增测试，关键事实不足时补最小验证。

流程

1. 确定目标：解析参数，取得 diff 和改动文件列表。PR 目标同时读 PR 标题和描述，了解作者意图。diff 为空时直接说明，不硬找问题。
2. 理解意图：结合提交信息、PR 描述、相关测试和文档，写清这次改动想实现什么；审查以意图为基准，而不只看代码外形。 检查目标是否遗漏、改动是否夹带无关范围；区分本次引入、加重和原有问题。冻结比较基线、当前提交与任务文件清单；代码变化后旧审查结论失效，应重新核对受影响范围。
3. 寻找候选缺陷，重点关注：
   • 逻辑错误、边界与空值、差一、类型或单位不匹配、错误的默认值
   • 改动后调用方和被调用方的契约是否仍然一致（参数、返回值、异常、事件顺序、序列化格式）
   • 异步与并发：迟到回调覆盖新状态、重复触发产生重复副作用、资源未释放、取消与超时处理
   • 错误处理：吞错、错误被转换成成功、部分更新留下半完成状态
   • 安全：认证授权、租户隔离、注入、敏感信息进日志或错误响应
   • CI 权限与外部输入：不可信内容是否进入有写权限的作业、命令或构建产物
   • 被删除或替换的旧路径是否仍有引用，或残留入口、开关、测试
   • 测试是否真的能区分旧的错误行为和目标行为
   • high 以上附带：已有 canonical 实现却重复造轮子、可删掉的间接层、明显的低效（N+1、无必要的串行、重复计算）
4. 逐条验证：对每个候选，先尝试证明它不成立——找到守卫条件、上游校验、类型约束或测试覆盖就丢弃。按程度表的要求补运行证据。结论标为：
   • CONFIRMED：有代码路径或运行证据证明会发生
   • PLAUSIBLE：推理成立但缺少运行证据，写出还需要验证什么
   • 证伪的直接丢弃，不写进报告
5. 排序输出：按严重程度排列（数据损坏/安全 > 功能错误 > 边界情况 > 清理建议），合并同一根因的多个表现。

按需深入

• 改动涉及异步完成、后台任务、重试、队列、事件提交、文件替换、删除、依赖或合同边界时，按相关章节读取 专项检查。
• 用户明确要求全项目质量评估或评分时，使用 项目评估；普通 diff 不运行全仓扫描。
• 需要独立模型挑战方案时，按用户要求或项目规则使用 adversarial-review，不按文件数量自动启动多轮代理。
• CLI、插件或安装包的交付验证由 check 的产物检查 补充，检查程度与本次实际改变的安装或发布路径匹配。

输出格式

每条发现：

[严重程度] 简短标题 — path/to/file.ext:行号  (CONFIRMED | PLAUSIBLE)
问题：一句话描述缺陷。
触发场景：具体输入或状态 → 错误的输出、崩溃或副作用。
证据：关键代码路径、测试或复现结果。
修复方向：一两句，可落地到现有代码。

清理类建议单独放在“清理建议”小节，排在缺陷之后。有证据的结构退化另列“结构问题”，说明本次增加的维护负担、简化方向或保留依据；不伪装成功能故障，也不因功能正常就降为可选润色。

结尾说明：审查目标与程度、做过哪些运行验证（测试命令及结果）、未覆盖的范围或盲区。没有发现时直接说“未发现问题”，并写明审查了什么。

--fix

• 只修报告中 CONFIRMED 的缺陷；PLAUSIBLE 和清理建议先列出来，由用户决定是否一起修。
• 修复围绕审查目标及其必要关联调用方、合同，按项目既有风格写；不以原 diff 行号阻止同根因修复，也不扩成无关重构。
• 修复后运行相关测试或静态检查，并逐条回报每个发现的处理结果：fixed / skipped（写原因）/ no_change_needed。验证没过时如实报告，不把失败说成成功。

--comment

• 只适用于 PR 目标；目标不是 PR 时说明并跳过。
• 评论定位到当前 PR/MR diff 支持的文件、差异侧和行号；删除问题可以位于旧侧。平台不支持该位置时，用精确文件与上下文的普通评论，不编造新侧行号。正文说明问题、触发场景和修复方向。
• 发布前重新核对目标与当前提交。使用实际平台支持的评论接口；GitHub 可使用 review 的 COMMENT 事件，其他平台遵循其接口。发布后读回内容和目标，确认没有重复或错位。