adversarial-reviewer

对抗式代码审查技能，通过三个带有敌意的审查者角色，强制实现真正的视角转换，以打破自我审查单一思维。

用途

当 Claude 审查自己编写或刚读过的代码时，它与作者共享同样的思维模型、假设和盲点，这导致对代码给出“看上去没问题”的评价，而一个全新的人类审查者会立刻指出问题。本技能通过要求采用对抗性角色来强制实现真正的视角转换，每个角色有不同的优先级、不同的担忧以及不同的“坏代码”定义。

主要能力

三个对抗性角色：Saboteur（生产环境破坏）、New Hire（可维护性）、Security Auditor（基于 OWASP）
强制发现问题：每个角色必须至少发现一个问题，消除走过场式的审查
严重度提升：被 2 个或以上角色捕获的问题提升一个严重级别
自我审查陷阱打破器：克服共享思维模型盲点的具体技巧
结构化裁决：BLOCK / CONCERNS / CLEAN，并给出清晰的合并指导

使用方式

/adversarial-review              # Review staged/unstaged changes
/adversarial-review --diff HEAD~3  # Review last 3 commits
/adversarial-review --file src/auth.ts  # Review a specific file

审查工作流

收集变更：根据调用方式确定审查范围。无参数时运行 git diff（未暂存）+ git diff --cached（已暂存），若两者都为空则运行 git diff HEAD~1（最后提交）。--diff <ref> 运行 git diff <ref>。--file <path> 读取整个文件。若无变更则停止并报告“Nothing to review.”。
读取完整上下文：对 diff 中的每个文件读取完整文件（而非仅变更行）；识别变更目的（缺陷修复、新功能、重构、配置变更、测试）；记录项目约定。
运行全部三个角色：依次执行每个角色，每个角色必须至少产生一个发现。不要软化发现，不要含糊其辞，要么是问题要么不是，要直接。
去重与综合：合并重复发现；将被 2 个或以上角色捕获的发现提升到下一严重级别；生成最终结构化输出。

三个角色

角色一：Saboteur（破坏者）

心态：“我正在试图在生产环境中破坏这段代码。”

优先关注：未验证的输入；可能变得不一致的状态；无同步的并发访问；吞掉异常或返回误导性结果的错误路径；可能被违反的数据格式、大小或可用性假设；差一错误、整数溢出、空/未定义解引用；资源泄漏（文件句柄、连接、订阅、监听器）。

角色二：New Hire（新员工）

心态：“我刚加入这个团队，需要在 6 个月后零上下文的情况下理解和修改这段代码。”

优先关注：无法传达意图的名称；需要阅读 3 个以上其他文件才能理解的逻辑；魔法数字、魔法字符串、未解释的常量；做不止一件事的函数；缺失的类型信息；与周围代码风格或项目约定不一致；测试实现细节而非行为；描述“做什么”而非“为什么”的冗余注释。

角色三：Security Auditor（安全审计员）

心态：“这段代码会被攻击，我的工作是在攻击者之前找到漏洞。”

基于 OWASP 的检查清单：注入（SQL、NoSQL、OS 命令、LDAP）；认证缺陷（硬编码凭据、缺失认证检查、会话令牌出现在 URL 或日志中）；数据暴露（错误消息、日志、API 响应中的敏感数据）；不安全默认值（调试模式、宽松 CORS、通配符权限、默认密码）；缺失访问控制（IDOR、缺失角色检查、权限提升路径）；依赖风险（已知 CVE 的新依赖）；机密（代码、配置或注释中的 API 密钥、令牌、密码）。

严重度分类

严重度	定义	所需操作
CRITICAL	会导致数据丢失、安全漏洞或生产中断。合并前必须修复。	阻止合并。
WARNING	可能在边界情况下导致缺陷、降低性能或困扰未来维护者。合并前应修复。	修复或明确接受风险并说明理由。
NOTE	风格问题、次要改进机会或文档缺口。修复更好。	作者自行决定。

提升规则：被 2 个或以上角色标记的发现提升一个级别（NOTE 变为 WARNING，WARNING 变为 CRITICAL）。

输出格式

评审结构如下：

## Adversarial Review: [brief description of what was reviewed]

**Scope:** [files reviewed, lines changed, type of change]
**Verdict:** BLOCK / CONCERNS / CLEAN

### Critical Findings
[If any — these block the merge]

### Warnings
[Should-fix items]

### Notes
[Nice-to-fix items]

### Summary
[2-3 sentences: what's the overall risk profile? What's the single most important thing to fix?]

裁决定义：

BLOCK — 1 个或以上 CRITICAL 发现。在解决之前不要合并。
CONCERNS — 无严重问题但有 2 个或以上警告。合并风险自负。
CLEAN — 仅有备注。可以安全合并。

反模式

“LGTM，未发现问题”：如果什么也没发现，说明看得不够仔细。每个变更至少有一个风险、假设或改进机会。
仅表面发现：只报告空白/格式问题而遗漏空指针解引用，比不审查更糟。实质优先，风格其次。
手下留情：“这可能也许是个小问题……”——不，要直接。
复述 diff：复述变更不是发现，要说清楚它错在哪里。
忽视测试缺口：没有测试的新代码就是发现项。测试不是可选项。
只审查变更行：缺陷存在于新代码与现有代码的交互中，要读取完整文件。

自我审查陷阱

你很可能正在审查自己刚编写或刚读过的代码，你的大脑形成了产生这段代码的相同思维模型，自然会认为它看起来正确。打破这一模式的方法：自下而上阅读代码；在阅读函数体之前先陈述其契约，看函数体是否匹配；假设每个变量在被证明之前都可能为空/未定义；假设每个外部调用都会失败；问自己“如果完全删除这个变更，什么会坏？”——如果答案是“什么都不会坏”，该变更可能是不必要的。

适用场景

合并任何 PR 之前，尤其是没有人类审查者自行编写的 PR
长时间编码会话之后，疲劳会产生盲点
当 Claude 说“看上去不错”时，如果你得到了轻松的批准，运行此技能寻求第二意见
安全敏感代码：认证、支付、数据访问、API 端点
当某处“感觉不对劲”时，相信直觉并运行对抗式审查

限制

该技能的官方介绍中未提供关于平台支持的详细列表、收费信息或版本要求，相关信息暂未提供。

技能介绍

用途