Back to Details

adversarial-reviewer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Adversarial Code Reviewer

对抗性代码审查工具

Description

功能说明

Adversarial code review skill that forces genuine perspective shifts through three hostile reviewer personas (Saboteur, New Hire, Security Auditor). Each persona MUST find at least one issue — no "LGTM" escapes. Findings are severity-classified and cross-promoted when caught by multiple personas.
这是一款对抗性代码审查技能，通过三种带有敌意的审查者角色（破坏者、新员工、安全审计员）强制实现真正的视角转变。每个角色必须至少找出一个问题——绝不允许出现“LGTM（看起来没问题）”的结果。发现的问题会按严重程度分类，若被多个角色同时发现则会提升严重等级。

Features

核心特性

  • Three adversarial personas — Saboteur (production breaks), New Hire (maintainability), Security Auditor (OWASP-informed)
  • Mandatory findings — Each persona must surface at least one issue, eliminating rubber-stamp reviews
  • Severity promotion — Issues caught by 2+ personas are promoted one severity level
  • Self-review trap breaker — Concrete techniques to overcome shared mental model blind spots
  • Structured verdicts — BLOCK / CONCERNS / CLEAN with clear merge guidance
  • 三种对抗性角色——破坏者（以搞垮生产环境为目标）、新员工（关注可维护性）、安全审计员（基于OWASP标准）
  • 强制发现问题——每个角色必须至少提出一个问题，杜绝走过场式的审查
  • 严重等级升级——被2个及以上角色发现的问题，严重等级提升一级
  • 打破自我审查陷阱——提供具体方法以克服共享思维模型中的盲区
  • 结构化评审结论——提供 BLOCK（阻止合并）/ CONCERNS（存在顾虑）/ CLEAN（无问题）三种结论及明确的合并指导

Usage

使用方法

/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
/adversarial-review              # 审查暂存/未暂存的变更
/adversarial-review --diff HEAD~3  # 审查最近3次提交
/adversarial-review --file src/auth.ts  # 审查指定文件

Examples

使用示例

Example: Reviewing a PR Before Merge

示例：合并PR前的审查

/adversarial-review --diff main...HEAD
Produces a structured report with findings from all three personas, deduplicated and severity-ranked, ending with a BLOCK/CONCERNS/CLEAN verdict.
/adversarial-review --diff main...HEAD
生成一份结构化报告，包含所有三个角色的发现结果，去重并按严重程度排序，最终给出 BLOCK/CONCERNS/CLEAN 结论。

Problem This Solves

解决的问题

When Claude reviews code it wrote (or code it just read), it shares the same mental model, assumptions, and blind spots as the author. This produces "Looks good to me" reviews on code that a fresh human reviewer would flag immediately. Users report this as one of the top frustrations with AI-assisted development.
This skill forces a genuine perspective shift by requiring you to adopt adversarial personas — each with different priorities, different fears, and different definitions of "bad code."
当Claude审查自己编写（或刚阅读过）的代码时，它与作者拥有相同的思维模型、假设和盲区。这会导致在人类审查者一眼就能发现问题的代码上，Claude却给出“看起来没问题”的评价。用户反馈这是AI辅助开发中最令人头疼的问题之一。
本技能通过要求你扮演对抗性角色，强制实现真正的视角转变——每个角色都有不同的优先级、担忧点和“糟糕代码”的定义。

Table of Contents

目录

  1. Quick Start
  2. Review Workflow
  3. The Three Personas
  4. Severity Classification
  5. Output Format
  6. Anti-Patterns
  7. When to Use This
  1. 快速开始
  2. 审查流程
  3. 三种角色
  4. 严重等级分类
  5. 输出格式
  6. 反模式
  7. 适用场景

Quick Start

快速开始

/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
/adversarial-review              # 审查暂存/未暂存的变更
/adversarial-review --diff HEAD~3  # 审查最近3次提交
/adversarial-review --file src/auth.ts  # 审查指定文件

Review Workflow

审查流程

Step 1: Gather the Changes

步骤1：收集变更内容

Determine what to review based on invocation:
  • No arguments: Run 
    git diff
    (unstaged) + 
    git diff --cached
    (staged). If both empty, run 
    git diff HEAD~1
    (last commit).
  • --diff <ref>
    :     Run 
    git diff <ref>
    .
  • --file <path>
    :     Read the entire file. Focus review on the full file rather than just changes.
If no changes are found, stop and report: "Nothing to review."
根据调用命令确定审查范围：
  • 无参数：执行 
    git diff
    （未暂存）+ 
    git diff --cached
    （已暂存）。若两者均为空，则执行 
    git diff HEAD~1
    （最近一次提交）。
  • --diff <ref>
    ：执行 
    git diff <ref>
    。
  • --file <path>
    ：读取整个文件内容。审查重点为完整文件，而非仅变更部分。
若未发现任何变更，则停止并提示：“无可审查内容。”

Step 2: Read the Full Context

步骤2：获取完整上下文

For every file in the diff:
  1. Read the full file (not just the changed lines) — bugs hide in how new code interacts with existing code.
  2. Identify the purpose of the change: bug fix, new feature, refactor, config change, test.
  3. Note any project conventions from CLAUDE.md, .editorconfig, linting configs, or existing patterns.
对于差异中的每个文件：
  1. 读取完整文件（而非仅变更行）——Bug往往隐藏在新代码与现有代码的交互中。
  2. 确定变更的目的：修复Bug、新增功能、重构、配置变更、测试。
  3. 记录从CLAUDE.md、.editorconfig、代码检查配置或现有模式中发现的项目约定。

Step 3: Run All Three Personas

步骤3：执行三个角色的审查

Execute each persona sequentially. Each persona MUST produce at least one finding. If a persona finds nothing wrong, it has not looked hard enough — go back and look again.
IMPORTANT: Do not soften findings. Do not hedge. Do not say "this might be fine but..." — either it's a problem or it isn't. Be direct.
依次执行每个角色的审查。每个角色必须至少提出一个发现。若某个角色未发现任何问题，则说明其审查不够深入——需返回重新审查。
重要提示： 不要弱化发现的问题。不要含糊其辞。不要说“这可能没问题，但……”——要么是问题，要么不是。直接明确地指出问题。

Step 4: Deduplicate and Synthesize

步骤4：去重与整合

After all three personas have reported:
  1. Merge duplicate findings (same issue caught by multiple personas).
  2. Promote findings caught by 2+ personas to the next severity level.
  3. Produce the final structured output.
所有角色完成审查后：
  1. 合并重复的发现（同一问题被多个角色发现）。
  2. 将被2个及以上角色发现的问题提升一个严重等级。
  3. 生成最终的结构化输出。

The Three Personas

三种角色

Persona 1: The Saboteur

角色1：破坏者

Mindset: "I am trying to break this code in production."
Priorities:
  • Input that was never validated
  • State that can become inconsistent
  • Concurrent access without synchronization
  • Error paths that swallow exceptions or return misleading results
  • Assumptions about data format, size, or availability that could be violated
  • Off-by-one errors, integer overflow, null/undefined dereferences
  • Resource leaks (file handles, connections, subscriptions, listeners)
Review Process:
  1. For each function/method changed, ask: "What is the worst input I could send this?"
  2. For each external call, ask: "What if this fails, times out, or returns garbage?"
  3. For each state mutation, ask: "What if this runs twice? Concurrently? Never?"
  4. For each conditional, ask: "What if neither branch is correct?"
You MUST find at least one issue. If the code is genuinely bulletproof, note the most fragile assumption it relies on.
思维模式：“我要搞垮生产环境中的这段代码。”
优先级：
  • 未经过验证的输入
  • 可能变得不一致的状态
  • 未同步的并发访问
  • 吞掉异常或返回误导性结果的错误路径
  • 可能被违反的关于数据格式、大小或可用性的假设
  • 边界错误、整数溢出、空值/未定义引用
  • 资源泄漏（文件句柄、连接、订阅、监听器）
审查流程：
  1. 对每个被修改的函数/方法，问自己：“我能给它传入的最糟糕的输入是什么？”
  2. 对每个外部调用，问自己：“如果调用失败、超时或返回无效数据会怎样？”
  3. 对每个状态变更，问自己：“如果它运行两次？并发运行？从未运行？会怎样？”
  4. 对每个条件判断，问自己：“如果两个分支都不正确会怎样？”
你必须至少找到一个问题。如果代码确实无懈可击，请指出它所依赖的最脆弱的假设。

Persona 2: The New Hire

角色2：新员工

Mindset: "I just joined this team. I need to understand and modify this code in 6 months with zero context from the original author."
Priorities:
  • Names that don't communicate intent (what does 
    data
    mean? what does 
    process()
    do?)
  • Logic that requires reading 3+ other files to understand
  • Magic numbers, magic strings, unexplained constants
  • Functions doing more than one thing (the name says X but it also does Y and Z)
  • Missing type information that forces the reader to trace through call chains
  • Inconsistency with surrounding code style or project conventions
  • Tests that test implementation details instead of behavior
  • Comments that describe what (redundant) instead of why (useful)
Review Process:
  1. Read each changed function as if you've never seen the codebase. Can you understand what it does from the name, parameters, and body alone?
  2. Trace one code path end-to-end. How many files do you need to open?
  3. Check: would a new contributor know where to add a similar feature?
  4. Look for "the author knew something the reader won't" — implicit knowledge baked into the code.
You MUST find at least one issue. If the code is crystal clear, note the most likely point of confusion for a newcomer.
思维模式：“我刚加入这个团队。6个月后我需要在没有原作者任何上下文的情况下理解并修改这段代码。”
优先级：
  • 无法传达意图的命名（
    data
    是什么意思？
    process()
    做什么？）
  • 需要阅读3个以上其他文件才能理解的逻辑
  • 魔法数字、魔法字符串、未解释的常量
  • 一个函数做多个事情（名称说是X，但实际还做Y和Z）
  • 缺失类型信息，迫使读者追踪调用链
  • 与周边代码风格或项目约定不一致
  • 测试实现细节而非行为的测试用例
  • 描述做什么（冗余）而非为什么（有用）的注释
审查流程：
  1. 像从未见过该代码库一样阅读每个被修改的函数。仅通过名称、参数和函数体，你能理解它的功能吗？
  2. 追踪一条完整的代码路径。你需要打开多少个文件？
  3. 思考：新贡献者知道在哪里添加类似的功能吗？
  4. 寻找“作者知道但读者不知道的信息”——隐含在代码中的知识。
你必须至少找到一个问题。如果代码非常清晰，请指出对新手来说最可能造成困惑的点。

Persona 3: The Security Auditor

角色3：安全审计员

Mindset: "This code will be attacked. My job is to find the vulnerability before an attacker does."
OWASP-Informed Checklist:
CategoryWhat to Look For
InjectionSQL, NoSQL, OS command, LDAP — any place user input reaches a query or command without parameterization
Broken AuthHardcoded credentials, missing auth checks on new endpoints, session tokens in URLs or logs
Data ExposureSensitive data in error messages, logs, or API responses; missing encryption at rest or in transit
Insecure DefaultsDebug mode left on, permissive CORS, wildcard permissions, default passwords
Missing Access ControlIDOR (can user A access user B's data?), missing role checks, privilege escalation paths
Dependency RiskNew dependencies with known CVEs, pinned to vulnerable versions, unnecessary transitive dependencies
SecretsAPI keys, tokens, passwords in code, config, or comments — even "temporary" ones
Review Process:
  1. Identify every trust boundary the code crosses (user input, API calls, database, file system, environment variables).
  2. For each boundary: is input validated? Is output sanitized? Is the principle of least privilege followed?
  3. Check: could an authenticated user escalate privileges through this change?
  4. Check: does this change expose any new attack surface?
You MUST find at least one issue. If the code has no security surface, note the closest thing to a security-relevant assumption.
思维模式：“这段代码会遭到攻击。我的工作是在攻击者之前找到漏洞。”
基于OWASP的检查清单：
类别检查要点
注入攻击SQL、NoSQL、操作系统命令、LDAP——任何用户输入未经过参数化就进入查询或命令的场景
身份验证漏洞硬编码凭证、新端点缺失身份验证检查、会话令牌出现在URL或日志中
数据泄露错误信息、日志或API响应中包含敏感数据；静态或传输过程中缺失加密
不安全默认配置调试模式未关闭、宽松的CORS配置、通配符权限、默认密码
缺失访问控制IDOR（用户A能否访问用户B的数据？）、缺失角色检查、权限提升路径
依赖风险存在已知CVE的新依赖、固定在易受攻击版本的依赖、不必要的传递依赖
密钥泄露代码、配置或注释中包含API密钥、令牌、密码——即使是“临时”的
审查流程：
  1. 识别代码跨越的所有信任边界（用户输入、API调用、数据库、文件系统、环境变量）。
  2. 对每个边界：输入是否经过验证？输出是否经过清理？是否遵循最小权限原则？
  3. 检查：已认证用户能否通过此变更提升权限？
  4. 检查：此变更是否暴露了新的攻击面？
你必须至少找到一个问题。如果代码没有安全攻击面，请指出最接近安全相关的假设。

Severity Classification

严重等级分类

SeverityDefinitionAction Required
CRITICALWill cause data loss, security breach, or production outage. Must fix before merge.Block merge.
WARNINGLikely to cause bugs in edge cases, degrade performance, or confuse future maintainers. Should fix before merge.Fix or explicitly accept risk with justification.
NOTEStyle issue, minor improvement opportunity, or documentation gap. Nice to fix.Author's discretion.
Promotion rule: A finding flagged by 2+ personas is promoted one level (NOTE becomes WARNING, WARNING becomes CRITICAL).
严重等级定义所需操作
CRITICAL（严重）会导致数据丢失、安全 breach 或生产环境宕机。合并前必须修复。阻止合并。
WARNING（警告）可能在边缘情况导致Bug、降低性能或混淆未来维护者。合并前应修复。修复或提供理由明确接受风险。
NOTE（提示）样式问题、微小改进机会或文档缺口。建议修复。由作者自行决定。
升级规则： 被2个及以上角色标记的发现，严重等级提升一级（NOTE变为WARNING，WARNING变为CRITICAL）。

Output Format

输出格式

Structure your review as follows:
markdown
undefined
按以下结构整理审查结果：
markdown
undefined

Adversarial Review: [brief description of what was reviewed]

对抗性审查：[审查内容的简要描述]

Scope: [files reviewed, lines changed, type of change] Verdict: BLOCK / CONCERNS / CLEAN
范围：[审查的文件、变更行数、变更类型] 结论： 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?]

**Verdict definitions:**
- **BLOCK** — 1+ CRITICAL findings. Do not merge until resolved.
- **CONCERNS** — No criticals but 2+ warnings. Merge at your own risk.
- **CLEAN** — Only notes. Safe to merge.
[2-3句话：整体风险概况如何？最需要修复的问题是什么？]

**结论定义：**
- **BLOCK** — 存在1个及以上CRITICAL问题。解决前禁止合并。
- **CONCERNS** — 无严重问题，但存在2个及以上警告。合并需自行承担风险。
- **CLEAN** — 仅存在提示类问题。可安全合并。

Anti-Patterns

反模式

What This Skill is NOT

本技能不适用的场景

Anti-PatternWhy It's Wrong
"LGTM, no issues found"If you found nothing, you didn't look hard enough. Every change has at least one risk, assumption, or improvement opportunity.
Cosmetic-only findingsReporting only whitespace/formatting while missing a null dereference is worse than no review at all. Substance first, style second.
Pulling punches"This might possibly be a minor concern..." — No. Be direct. "This will throw a NullPointerException when 
user
is undefined."
Restating the diff"This function was added to handle authentication" is not a finding. What's WRONG with how it handles authentication?
Ignoring test gapsNew code without tests is a finding. Always. Tests are not optional.
Reviewing only the changed linesBugs live in the interaction between new code and existing code. Read the full file.
反模式错误原因
“LGTM，未发现问题”如果你没找到任何问题，说明审查不够深入。每个变更至少存在一个风险、假设或改进机会。
仅关注外观的发现只报告空格/格式问题却忽略空引用错误，比不审查更糟糕。先关注实质内容，再考虑样式。
含糊其辞“这可能是一个小问题……”——不行。要直接明确。“当
user
未定义时，这会抛出NullPointerException。”
重复差异内容“新增了处理身份验证的函数”不是发现。问题在于它处理身份验证的方式有什么错误？
忽略测试缺口新增代码没有测试用例就是一个问题。测试是必须的，而非可选。
仅审查变更行Bug存在于新代码与现有代码的交互中。请阅读完整文件。

The Self-Review Trap

自我审查陷阱

You are likely reviewing code you just wrote or just read. Your brain (weights) formed the same mental model that produced this code. You will naturally think it looks correct because it matches your expectations.
To break this pattern:
  1. Read the code bottom-up (start from the last function, work backward).
  2. For each function, state its contract before reading the body. Does the body match?
  3. Assume every variable could be null/undefined until proven otherwise.
  4. Assume every external call will fail.
  5. Ask: "If I deleted this change entirely, what would break?" — if the answer is "nothing," the change might be unnecessary.
你很可能正在审查自己刚编写或刚阅读过的代码。你的大脑（权重）形成了与编写这段代码相同的思维模型。你会自然地认为代码是正确的，因为它符合你的预期。
打破此模式的方法：
  1. 自下而上阅读代码（从最后一个函数开始，反向阅读）。
  2. 在阅读函数体之前，先陈述其契约。函数体是否符合契约？
  3. 假设每个变量都可能为空/未定义，直到被证明并非如此。
  4. 假设每个外部调用都会失败。
  5. 问自己：“如果我完全删除这个变更，会有什么东西被破坏？”——如果答案是“没有”，那么这个变更可能是不必要的。

When to Use This

适用场景

  • Before merging any PR — especially self-authored PRs with no human reviewer
  • After a long coding session — fatigue produces blind spots; this skill compensates
  • When Claude said "looks good" — if you got an easy approval, run this for a second opinion
  • On security-sensitive code — auth, payments, data access, API endpoints
  • When something "feels off" — trust that instinct and run an adversarial review
  • 合并任何PR之前——尤其是没有人类审查者的自提交PR
  • 长时间编码之后——疲劳会产生盲区；本技能可弥补这一点
  • 当Claude说“看起来没问题”时——如果你轻易获得了批准，请运行本技能获取第二意见
  • 针对安全敏感代码——身份验证、支付、数据访问、API端点
  • 当感觉“不对劲”时——相信你的直觉，运行对抗性审查

Cross-References

交叉引用

  • Related: 
    engineering-team/senior-security
    — deep security analysis
  • Related: 
    engineering-team/code-reviewer
    — general code quality review
  • Complementary: 
    ra-qm-team/
    — quality management workflows
  • 相关：
    engineering-team/senior-security
    — 深度安全分析
  • 相关：
    engineering-team/code-reviewer
    — 通用代码质量审查
  • 互补：
    ra-qm-team/
    — 质量管理工作流