adversarial-review

/adversarial-review —— 单一批评者压力测试

主动尝试击垮已知产物，对其进行压力测试。审查者的任务是成为房间里最犀利的批评者——不求平衡、不提建设性意见、不讲客气。采取对抗性立场。

何时使用 /adversarial-review，何时使用 /council-review

工具	用途	模式
/adversarial-review	对已知产物（PR、草稿、规范、计划、论证）进行压力测试	单一批评者，侧重攻击
/council-review	开放式问题、决策、“我们应该怎么做？”	多 Agent 协作式 DMAD

如果输入是没有拟定答案的问题，请转到 /council-review。如果输入是用户希望找出缺陷的成品，那么该工具正合适。

实证说明：M3MADBench（2026）表明，对于开放式问题，多 Agent 对抗式辩论的表现不如多 Agent 协作式辩论。单一批评者的对抗性探查是另一种操作——当目标是找出特定产物中的具体缺陷，而非综合不同观点得出结论时，它才是合适的工具。

为什么有效

最出色的实践者会让模型指出自己作品中错在哪里，而不是对在哪里。大多数用户都用 AI 来确认自己的想法。Adversarial-review 会迫使模型给出反证。同一个能按需流畅赞同的模型，只要提示得当，也能同样迅速地拆解同一论证。

灵感来源：

• Codex Review Plugin 的 /codex:adversarial-review 模式——探查边缘情况、质疑架构决策、扮演反方
• “告诉我为什么我错了”的提示实践
• 事前验尸法——假设产物已经失败；逆向追溯原因

参数

• 参数 1（必填）： 要审查的产物。以下任选其一：
  • 文件路径（docs/spec.md、src/auth.ts）
  • PR 编号或 URL（123、https://github.com/org/repo/pull/123）
  • 用引号括起来的粘贴文本
• 标志（可选，可组合）：
  • --security —— 优先检查攻击面、身份验证缺口、输入验证和机密信息处理
  • --logic —— 优先检查逻辑矛盾、遗漏情况和未说明的假设
  • --user —— 优先检查 UX 缺口、易误操作之处、意外行为和无障碍性
  • --scale —— 优先检查在预期负载的 10× 或 100× 下会出现的问题、并发和争用
  • --quick —— 仅进行一轮攻击，按严重程度排列发现，不深入分析（低成本模式）

未设置标志时，会运行全部五种攻击向量。标志会缩小关注范围。

流程

第 1 阶段：SCOPE —— 确认这是合适的工具

1. 从 $ARGUMENTS 解析标志。
2. 对输入进行分类：
   • PR —— 数值，或包含 /pull/ 的 URL。通过 gh pr view --json title,body && gh pr diff 获取内容。
   • 文件路径 —— 可解析为现有文件的字符串。读取该文件。
   • 粘贴文本 —— 将其视为产物本身。
3. 拒绝开放式问题。 如果输入是没有拟定答案的问题（“我们应该使用 GraphQL 吗？”、“……的最佳方式是什么？”），请转到：

   “这是一个开放式问题，而不是产物。决策请使用 /council-review；对特定草稿、PR、规范或计划进行压力测试请使用 /adversarial-review。” 不要继续。

4. 确认审查范围。 用一句话向用户复述：“正在审查[产物]，检查[已启用的攻击向量]。关注问题所在，而非优点。”

第 2 阶段：READ —— 加载完整产物及上下文

对于 PR：

• gh pr view <id> --json title,body,baseRefName,headRefName,changedFiles
• gh pr diff <id>
• 阅读 PR 正文中引用的任何上下文文件

对于文件路径：

• 阅读完整文件
• 如果产物引用了同级文件，也要阅读
• 如存在项目 CLAUDE.md / AGENTS.md，也要阅读（了解约定）

对于粘贴文本：

• 按原样使用

阶段 3：攻击 — 执行对抗性探测

默认行为（不带标志）：并行运行全部五种攻击向量，分别由子 Agent 执行；或者由单个 Agent 按结构化章节执行（根据工件大小自行决定：超过 500 LOC 时使用子 Agent，否则使用单个 Agent）。

每种攻击向量都有专门的提示词：

--security（或默认）

You are a security reviewer trying to break this artifact. Find:
- Auth gaps: missing checks, broken object-level authorization, IDOR potential
- Input validation failures: injection, untrusted-input flow, type confusion
- Secret handling: hardcoded secrets, secret-in-logs, secret-in-error-messages
- External API trust: assuming responses are well-formed, missing timeouts
- Data exposure: PII in responses, over-fetching, sensitive errors

For each finding: severity (CRITICAL/HIGH/MEDIUM/LOW), specific location (file:line if applicable), reproduction sketch, and the fix in one sentence.

Do not list things that are already secure. Do not pad the report. If you find nothing, say "no findings in this dimension" and move on.

--logic（或默认）

You are a logician reviewing this artifact. Find:
- Missing cases: state combinations the artifact doesn't handle (null, empty, max-int, negative, concurrent)
- Unstated assumptions: things the author treats as obvious that aren't
- Internal contradictions: claim X in one section, claim ~X in another
- Off-by-one and boundary errors
- Ordering: race conditions, dependency cycles, lock ordering
- Counter-examples: an input that breaks the central claim

For each finding: a concrete adversarial example, why it breaks the artifact, and the smallest fix.

--user（或默认）

You are a user encountering this for the first time, trying to use it incorrectly. Find:
- Footguns: things that look fine but cause silent damage
- Surprising defaults: behavior the user doesn't expect from the docs/UI
- Confirmation traps: irreversible actions that look reversible (or vice versa)
- Accessibility: keyboard-only use, screen reader, color-only signaling
- Error states: what happens when the user does the wrong thing? Is the recovery path clear?

For each finding: the specific user action, the surprising or harmful outcome, and the fix.

--scale（或默认）

You are a system reviewer asking: what breaks at 10× or 100× the expected load? Find:
- Algorithmic cliffs: O(n²) or worse hidden in normal-looking code
- Memory growth: unbounded caches, accumulating state, missing cleanup
- Database hot spots: missing indexes, N+1 queries, table-locking transactions
- Concurrency: shared mutable state, race conditions, lock contention
- External dependencies: rate limits, fan-out blast radius, retry storms
- Single points of failure

For each finding: the failure mode, the rough threshold (rows / users / RPS), and the fix.

通用探测（始终运行，除非使用 --quick）

You are the harshest reviewer this artifact will ever see. Beyond the categories above, find:
- The thing the author was avoiding thinking about
- The simplest counter-example to the central claim
- The version of the artifact that exists in 30 days, after one round of feedback — what changed and why?
- The strongest argument *against* the artifact's central thesis
- The "we'll handle it later" item that becomes a real problem

Be specific. No abstract concerns.

升级探测（V2 — 始终运行，除非使用 --quick）

单次审查会遗漏只有在一系列交互中才会出现的失效模式——这是静态单轮评估已知的盲点。动态探测工件：

Single inputs may look safe; sequences break. Find the multi-step failure:
- What's the 2-4 step interaction that compounds into a failure no single step triggers? (state accretion, retry storms, partial-failure left mid-way, auth downgraded across a flow)
- What does a user/attacker do AFTER the first thing works — and where does step N break what step 1 established?
- Where does the artifact assume a clean single attempt but production delivers retries, reorders, or interleaving?

Give the concrete step sequence and the state at each step up to the break.

阶段 4：分类 — 分类并排序

将所有发现归入以下三个严重性等级之一：

等级	定义	操作
CRITICAL	在现实条件下会导致生产环境故障、破坏安全性或危及安全	发布前修复
IMPORTANT	会降低质量、在边缘情况下引发实际错误或使用户困惑	在下一轮修复
NIT	风格、润色或轻微不一致	可选

在每个等级内，按发生可能性 × 影响范围排序。删除纯属猜测或“可以设想某种情况……”的发现——只保留有具体示例支持的发现。

（V2）验证关卡 — 升级前确认。 对于每项 CRITICAL（理想情况下也包括每项 IMPORTANT），说明精确的复现步骤，并在脑中对照工件重新执行：根据现有代码／规范，触发条件是否确实会导致故障，还是已有防护措施会阻止它？未通过复测的发现应降级或删除。自动化红队的优势在于经过验证且可复现的发现，而非数量——无法复现的 CRITICAL 会损害信任，得不偿失。为每项复测后仍成立的发现标记 [reproduced]。

阶段 5：呈现 — 展示发现及复现步骤

输出结构：

## Adversarial Review: [Artifact Name]

**Attack vectors run:** [list of dimensions]
**Findings:** [N CRITICAL / M IMPORTANT / K NIT]

---

### CRITICAL (N)

#### [1] [One-line title — what breaks]
**Location:** [file:line or section]
**Trigger:** [the specific input/condition that breaks the artifact]
**What breaks:** [the failure mode, in one sentence]
**Fix sketch:** [one sentence — what to change]

[Repeat per CRITICAL finding]

---

### IMPORTANT (M)

[Same structure, one tier down]

---

### NIT (K)

[One-line bullets, no expanded structure]

---

### What I Could Not Break

[2-3 sentences naming the strongest parts of the artifact — the parts that resisted attack. This is calibration, not flattery: it tells the user where the artifact is genuinely strong.]

---

### What This Review Did NOT Cover

[Honesty section. List dimensions you did not probe — usually because they require runtime testing, user research, or knowledge the artifact doesn't include. Saves the user from assuming "no findings" means "no risks".]

阶段 6：呈现 — 在聊天中展示并提供保存选项

直接完整展示报告。如果工件是文件或 PR，则提供将报告保存到 <cwd>/adversarial-review-<artifact-slug>-<date>.md 的选项。

注意事项

• 不要保持中立。 这是对抗性角色。工件的维护者已经存在；这项技能的作用是发现他们遗漏的问题。
• 不要凑数。 如果某个维度没有发现，就直说。五条空洞的发现不如一条真实发现，更不如零条。
• 不要在没有示例的情况下猜测。 “攻击者可以设想某种情况……”是噪声。“发送 <input> 并观察 <failure>”才是信号。
• 不要将已完成的工件转交给 /council-review。 这正好弄反了——council 用于开放问题，本技能用于压力测试。
• 不要在修复建议中提出彻底重写。 用一句话说明修复方法，或者写“这需要更深入的重新设计——参见备注”。把重写留给作者。
• 不要省略“我未能攻破的部分”。 否则用户无法判断工件哪些部分确实牢固，哪些只是你没有检查。

更新日志

V2（2026-05-27）

通过 skillforge optimize 优化（成果研究：2026 年红队实践）。

• 升级探测（阶段 3） — 增加多步骤／序列攻击；文档指出，静态的单轮审查会漏掉依赖交互、由升级触发的故障。
• 验证门槛（阶段 4） — 每项 CRITICAL 都必须附有经确认的复现（[reproduced]）；无法复现的发现会降级或剔除。这体现了自动化红队测试的优势：经验证且附有复现的发现胜过单纯追求数量（基于学习的 RT 报告称，与人工方式相比，发现能力约提升 3.9×，验证准确率达 89%）。
• 目标成果：深入分析多步骤故障，并减少误报（验证门槛）。来源：算法红队测试综述（arXiv 2026）；基于学习的自动化 RT；2026 年红队从业者指南。
• 验证（独立 A/B 测试，2026-05-27）：在一个植入的重试／幂等性 bug 上，比较 V1（单轮）与 V2（+升级探测）。两组都发现了该 bug，因此在这个案例中，升级探测的发现率优势尚未得到证明（该 bug 在单轮审查中也能发现）。V2 展现出的优势在于复现质量：提供了具体的 7 步复合故障轨迹，而 V1 仅一行提及。结论仅限于此；要测试发现率，必须使用只有通过序列分析才能发现的 bug。

成本预算

模式	Agent 调用次数	最适用场景
默认（所有向量）	6–7（每个向量 + 通用 + 升级探测 + 分诊）	合并前 PR 审查、规范签核
单个维度（--security 等）	2（定向探测 + 分诊）	定向审计
快速（--quick）	1	低成本快速检查

常规／计划

对于合并前自动化，可将其封装为 GitHub Actions 步骤，在涉及身份验证或数据路径的 PR 上运行 claude code -p "/adversarial-review $PR_URL --security"。

测试

这是一个仅含提示词的技能。随附的 tests/eval.sh 会断言其结构契约。要端到端验证行为：

1. 进入包含近期 PR 或草拟规范的项目目录。
2. 运行 /adversarial-review docs/spec.md（或任意产物路径）。
3. 检查以下内容：
   • 发现项是否归类为 CRITICAL / IMPORTANT / NIT
   • 每项 CRITICAL 是否都有明确的触发条件和复现概要
   • 是否包含内容充实的 “What I Could Not Break” 部分
   • “What This Review Did NOT Cover” 部分是否如实说明遗漏
4. 使用单个标志运行：/adversarial-review docs/spec.md --security。确认只报告安全发现。
5. 针对一个未决问题运行，以验证重定向：/adversarial-review "Should we use GraphQL?" 应重定向至 /council-review。