adversarial-review

敵対的レビュー

fresh-eyes レビューを使った自動批評・修正ループです。各ラウンドでは、コードを先入観なくレビューします。意思決定の理由を知らず、実装にも思い入れがありません。Critical と Suggestion の指摘を修正した後、新たな視点で再度レビューします。Nitpick のみになるか、3 ラウンドを終えるとループを停止します。

実行 — ハーネスに依存しない方式

契約となるのは、fresh-eyes による批評・修正ループであり、特定の仕組みではありません。

• Claude Code — 毎ラウンド、新しいレビュアーサブエージェント（Agent ツール、subagent_type: general-purpose）を起動します。これにより、レビュアーはコードや過去のラウンドについて文字どおり何も覚えていない状態になります。これが最も徹底した「新鮮な視点」です。
• Codex / その他のシングルエージェント型ハーネス — 自分でループを実行します。各ラウンドで差分を先入観なく読み直し、初めて見るコードであるかのようにレビューします。意図的に、なぜそのように書かれたかについての知識はいったん脇に置きます。サブエージェントは不要です。重要なのはプロセスの境界ではなく、fresh-eyes の姿勢です。

以下では、ループを Claude のサブエージェント用語で説明します。シングルエージェント型のハーネスでは、「レビュアーを起動する」を「先入観のないレビューを行う」に、「新しいサブエージェント」を「最初から読み直す」に置き換えます。

使用するタイミング

• 実装後、コミット前 — 特に機能追加やリファクタリングの後
• 変更がクリティカルパス、セキュリティ上重要なコード、または複雑なロジックに及ぶとき
• 自分自身が行うよりも厳しいレビューを受けたいとき
• パイプライン内の位置：implement → /simplify → /adversarial-review → /finalize → commit

使用しないタイミング

• 些細な変更、ドキュメントのみの変更、設定の微調整 — 代わりに /simplify と /finalize を使います
• 実装の途中 — まず実装を完了してからレビューします
• 手早く妥当性を確認したいだけのとき — 代わりに /code-review を使います

入力モード

$ARGUMENTS を解析して、レビュー対象を判定します。

• 引数なし： 未コミットの変更をレビューします — git diff と git diff --cached を実行し、ステージ済みと未ステージの変更を取得します
• ファイル／ディレクトリのパス： 指定したファイルをレビューします — それらを直接読み込み、レビュー対象のコードとして提示します
• --base=<ref> / --fork=<sha>： 差分の基準となる明示的なベースまたはフォークポイントです（呼び出し元がこれを渡すことで、意図したとおりの差分をレビューできます）。指定されている場合は、<fork-or-base>...HEAD をレビューし、以下の自動解決をスキップします。
• --pr フラグ： ブランチ全体の差分をレビューします。ベースを確実に解決します — main と決めつけないでください。既存の PR のベースを使い、なければリポジトリのデフォルトブランチを使います。ローカルに存在する ref に解決したうえで、真のフォークポイントを取得します。

  BASE="$(gh pr view --json baseRefName -q .baseRefName 2>/dev/null || gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null || echo main)"
  if git rev-parse --verify --quiet "$BASE" >/dev/null; then BASE_REF="$BASE";
  elif git rev-parse --verify --quiet "origin/$BASE" >/dev/null; then BASE_REF="origin/$BASE";
  else echo "No base ref for '$BASE' — fetch it and retry"; exit 1; fi
  FORK="$(git merge-base "$BASE_REF" HEAD)"
  git diff "$FORK"...HEAD
  

差分が空の場合は、レビュー対象がないことをユーザーに伝えて終了します。

ステップ 1：コンテキストを収集する

レビュアーを起動する前に、次の 2 つを収集します。

差分

上記の入力モードに基づいて差分を収集します。これがレビュアーによる批評の対象になります。

プロジェクトの規約

レビュアーが把握すべき規約ドキュメントをプロジェクト内で検索します。以下を確認します。

• CLAUDE.md ファイル（プロジェクトのルートとネストされたディレクトリ）
• 一般的な場所にあるガイド／規約ドキュメント：project/guides/、docs/、.cursor/rules/、AGENTS.md
• リントおよびスタイル設定ファイル（.rubocop.yml、.eslintrc.*、.prettierrc、standardrb の設定など）

上限： 規約に関するコンテキストは約 5K トークン以内に抑えます。CLAUDE.md ファイルとリント設定を含めます。実装ガイド全体、機能ドキュメント、README は含めないでください。レビュアーが確認するのはコードの品質であり、機能の完全性ではありません。規約に関する資料が上限を超える場合は、まず CLAUDE.md ファイルを優先し、次にリント設定を優先します。

ステップ 2：レビュアーサブエージェントを起動する

Agent ツールを使ってレビュアーを起動します。

• subagent_type：general-purpose
• description："Adversarial code review — round N"
• prompt：以下のレビュアープロンプト全体を使用し、{conventions} と {diff} を実際の内容に置き換えます

レビュアープロンプト

You are a senior developer doing a cold code review. You have never seen this
code before. You have no context on why decisions were made. You did not write
any of this. Review with completely fresh eyes.

## Project Conventions

{conventions}

## Code to Review

{diff}

## Review Criteria

Be opinionated. Review for:

- **Correctness:** bugs, logic errors, edge cases, race conditions
- **Security:** injection, auth bypass, data exposure, OWASP top 10
- **DRY:** duplicated logic that should be extracted
- **Modularity:** classes/methods doing too much, unclear boundaries
- **Testability:** code that's hard to test, missing test coverage
- **Simplicity:** over-engineering, unnecessary abstractions, premature generalization
- **Architecture:** does it conform to the project's established patterns and conventions?
- **Naming:** unclear or misleading names
- **Error handling:** swallowed errors, missing edge cases

## Output Format

Return findings as a list. Each finding MUST have:

- **Severity:** Critical | Suggestion | Nitpick
- **Location:** file path and line range
- **Issue:** what's wrong
- **Fix:** specific, concrete recommendation

Severity definitions:
- **Critical** = bugs, security issues, data loss risk, broken functionality
- **Suggestion** = improvements that meaningfully affect quality, maintainability, or conformance
- **Nitpick** = style preferences, minor naming quibbles, cosmetic issues

Be honest about severity. Don't inflate Nitpicks to Suggestions.
If the code is solid, say so — an empty findings list is a valid result.

ステップ 3：指摘事項への対応

レビュアーサブエージェントから結果が返されたら：

1. 指摘事項に目を通します
2. Critical と Suggestion の項目をすべて、コードに直接反映します
3. 確立されたプロジェクトの規約やこのセッションでの以前の議論と矛盾する指摘はスキップし、スキップした理由を記録します
4. Nitpick の項目は、対応せずに記録します
5. 今回見つかったことと修正したことを記録します

判断は自分で行ってください。指摘が間違っている場合や、何かを壊してしまう場合はスキップし、その理由を記録してください。レビュアーは新鮮な視点を持っていますが、会話の文脈は把握していません。レビュアーが知らないことを、あなたは把握しています。

ステップ 4：繰り返し

修正を適用した後：

1. 新しい差分を収集します。前回のラウンドではなく、元のベースラインと比較してください。毎回、修正箇所だけでなく、変更全体をレビュアーに見せます。
2. 更新した差分を使って、新しいレビュアーサブエージェントを起動します。前回のサブエージェントを再利用しないでください。
3. 次のいずれかの条件を満たすまで繰り返します。
   • Nitpick の指摘だけが残っている → 停止します。コードに問題はありません
   • 3 ラウンド完了 → 停止し、残っている Nitpick 以外の指摘を報告します

ステップ 5：報告

完了したら、次の形式で概要を提示します。

## Adversarial Review Complete

**Rounds:** N of 3
**Result:** [Clean — only nitpicks remain | Capped — N issues remain after 3 rounds]

### Round 1
- [Critical] file.rb:12-15 — description (FIXED)
- [Suggestion] file.rb:30 — description (FIXED)
- [Nitpick] file.rb:45 — description

### Round 2
- [Nitpick] file.rb:32 — description

### Remaining Nitpicks
- file.rb:45 — description
- file.rb:32 — description

最初のラウンドで指摘が一件もなかった場合は、コードに問題がなかったことを報告して終了します。

よくある間違い

• 2 ラウンド目で同じサブエージェントを再利用する — サブエージェントが自分の指摘を覚えているため、新鮮な視点が失われます。必ず新しいサブエージェントを起動してください。
• 変更全体ではなく、修正箇所だけを差分として比較する — 2 ラウンド目のレビュアーには、1 ラウンド目以降の変更だけでなく、すべての変更を見せてください。
• 指摘をすべて無条件に適用する — レビュアーが把握していない会話の文脈を、あなたは把握しています。判断して、プロジェクトの規約や以前の決定と矛盾する指摘はスキップし、その理由を記録してください。
• 些細な変更に対してこれを実行する — コストがかかります。変数名を変更しただけなら、代わりに /simplify + /finalize を使用してください。