adversarial-review

/adversarial-review -- 単独批評家によるストレステスト

既知の成果物を積極的に壊そうとして、ストレステストを実施します。レビュー担当者の役割は、その場で最も鋭い批評家になることです。公平でも、建設的でも、丁寧でもありません。敵対的な姿勢で臨みます。

/council-review ではなくこちらを使う場合

ツール	用途	モード
/adversarial-review	既知の成果物（PR、草稿、仕様書、計画、主張）のストレステスト	単独批評家、攻撃重視
/council-review	未解決の質問、意思決定、「何をすべきか？」	複数エージェント、協調的 DMAD

入力が提案された答えのない質問であれば、/council-review に誘導してください。ユーザーが欠陥を探ることを望む完成済みの成果物であれば、こちらが適切なツールです。

実証的な注記：M3MADBench（2026）によると、未解決の質問については、複数エージェントによる敵対的な議論は、複数エージェントによる協調的な議論よりも成果が劣ります。単独批評家による敵対的な検証は、これとは異なる操作です。複数の視点から判断を統合するのではなく、特定の成果物にある具体的な欠陥を見つけることが目的の場合に適したツールです。

引数

• 引数 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 回の攻撃的な確認を行い、重要度順に指摘を示します。詳細な調査は行いません（低コストモード）

フラグが指定されていない場合は、5 つすべての攻撃ベクトルを実行します。フラグを指定すると、対象を絞り込みます。

手順

フェーズ 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：ATTACK — 敵対的なプローブを実行する

デフォルトの動作（フラグなし）：5 つすべての攻撃ベクトルを、並列のサブエージェントとして実行するか、構造化されたセクションを用いて単一のエージェントで実行します（アーティファクトの規模に応じて選択してください。500 LOC を超える場合はサブエージェント、それ以外は単一のエージェント）。

各攻撃ベクトルには、焦点を絞ったプロンプトがあります。

--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 でない限り常に実行）

1 回のレビューでは、複数のやり取りを経て初めて現れる障害モードを見逃します。これは、静的な単一ターン評価において既知の盲点です。アーティファクトを動的に検査してください。

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：TRIAGE — 分類して優先順位を付ける

すべての指摘を、次の 3 つの深刻度に分類します。

Tier	定義	対応
CRITICAL	現実的な条件下で本番環境における障害、安全性の破綻、またはセキュリティ侵害につながる	リリース前に修正
IMPORTANT	品質を低下させる、エッジケースで実際のバグを引き起こす、またはユーザーを混乱させる	次のパスで修正
NIT	スタイル、仕上げ、軽微な不整合	任意

各深刻度の中で、発生可能性 × 影響範囲に基づいて順位を付けます。純粋な憶測や「こういうシナリオも想像できる」といった指摘は除外し、具体例に裏付けられたものだけを残してください。

（V2）検証ゲート — 深刻度を上げる前に確認する。 CRITICAL（できれば各 IMPORTANT も）について、正確な再現手順を示し、アーティファクトに照らして頭の中で再実行してください。コードや仕様のとおりにトリガーが実際に障害に至るのか、既存のガードによってすでに阻止されるのかを確認します。この再テストに耐えない指摘は、深刻度を下げるか削除してください。自動レッドチームの強みは、再現手順を伴う検証済みの指摘であり、再現できない CRITICAL は、その価値以上に信頼を損ないます。再テストに耐えた指摘には、それぞれ [reproduced] を付けてください。

フェーズ 5：PRESENT — 再現手順とともに指摘を提示する

出力構成：

## 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：PRESENT — チャットに表示し、保存を提案する

レポート全体をインラインで出力します。アーティファクトがファイルまたは PR の場合は、<cwd>/adversarial-review-<artifact-slug>-<date>.md への保存を提案してください。

注意点

• 中立的な立場を取らないでください。 これは敵対的な役割です。アーティファクトを擁護する人はすでにいます。このスキルの目的は、彼らが見落とした点を見つけることです。
• 指摘を水増ししないでください。 ある観点で何も見つからなかった場合は、そのように伝えてください。実質的な指摘 10 件より、内容の薄い指摘 5 件のほうがましというわけではなく、むしろ 0 件のほうがよい場合もあります。
• 例を示さずに推測しないでください。 「攻撃者がこういうシナリオを想像できるかもしれない」は雑音です。「<input> を送信して <failure> を確認する」は有用な情報です。
• 完成したアーティファクトを /council-review に回さないでください。 これは逆の間違いです。council は未解決の質問向けであり、このスキルはストレステスト向けです。
• 修正案で全面的な書き直しを提案しないでください。 一文の修正案か、「これはより深い再設計が必要です — Notes を参照」としてください。書き直しは作成者に任せます。
• 「What I Could Not Break」を省略しないでください。 これがないと、ユーザーはアーティファクトのどこが本当に堅牢で、どこを調べていないのか判断できません。

変更履歴

V2（2026-05-27）

skillforge optimize による最適化（成果調査：2026年のレッドチーム演習）。

• エスカレーションプローブ（フェーズ3） — 複数ステップ／シーケンス攻撃を追加します。静的な単一ターンのレビューでは、インタラクションに依存するエスカレーション起因の不具合を見逃すことが文書化されています。
• 検証ゲート（フェーズ4） — すべての CRITICAL に、確認済みの再現手順（[reproduced]）を含める必要があります。再現できない指摘事項は、格下げまたは削除されます。これは、自動レッドチーム演習の強みを反映しています。生の件数より、再現手順で検証された指摘事項のほうが有効です（学習ベースの RT レポートでは、手動の場合と比べて発見数が約3.9倍、検証精度が89%と報告されています）。
• 成果目標：複数ステップの不具合分析を深め、検証ゲートによって誤検知を減らします。出典：アルゴリズムによるレッドチーム演習のレビュー（arXiv 2026）、学習ベースの自動 RT、2026年のレッドチーム実践者向けガイド。
• 検証（独立した A/B テスト、2026-05-27）： 再試行／冪等性のバグを仕込んで、V1（単一パス）と V2（+エスカレーションプローブ）を比較しました。どちらの条件でもバグを検出したため、このケースではエスカレーションプローブによる検出率の優位性は実証されていません（このバグは単一パスでも検出可能でした）。V2で実証された利点は、再現手順の質でした。V1が一行で言及したのに対し、V2は具体的な7ステップの複合障害の追跡を示しました。主張の範囲はこの点に限定されます。検出率を検証するには、シーケンス攻撃でのみ検出できるバグが必要です。

コスト予算

モード	エージェント呼び出し回数	適した用途
デフォルト（全ベクトル）	6–7（ベクトルごと + 共通 + エスカレーションプローブ + トリアージ）	マージ前の PR レビュー、仕様の承認
単一の観点（--security など）	2（対象を絞ったプローブ + トリアージ）	特定の対象に絞った監査
クイック（--quick）	1	簡易チェック

定例／スケジュール

マージ前の自動化では、GitHub Actions のステップとしてラップし、認証またはデータ関連のパスに触れる PR に対して claude code -p "/adversarial-review $PR_URL --security" を実行します。

テスト

これはプロンプトのみのスキルです。同梱されている tests/eval.sh では、構造上の要件を検証します。動作をエンドツーエンドで確認するには、次の手順を実行します。

1. 最近の PR または仕様書のドラフトがあるプロジェクトに cd します。
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 にリダイレクトされるはずです。