アドバーサリアルレビュー（逆張りレビュー） は何をしますか？
提案が実行される前に、その提案が失敗する理由を見つけ出します。ランク付けされた、アクション可能な懸念点と1つの判定を生成します。絶対に実装はしません。ラウンド制限を超えてループすることもありません。
0. セットアップ
- モードを選ぶ。 呼び出し元がそう指定した場合（例：「レポートモードでアドバーサリアルレビュー」）、またはサブエージェント、ワーカー、ヘッドレス実行（人間が答えることができない）で動作している場合は
report。兆候：タスクが委譲されたプロンプトとして到着した、質問ツールがない、または呼び出し元がファイルや文字数制限のあるサマリーを要求した。それ以外のすべての場合はinteractive。 - 成果物（アーティファクト）を見つける。 それは以下のいずれか：ファイルパス、差分範囲、貼り付けられた計画、または「この会話で生成されたもの」。複数の候補がある場合は、出力の最初の行で選択したものを明記する。何も指定されておらず、最近の出力も明らかな候補ではない場合：インタラクティブモードでは、どの成果物を指すのかを尋ね、この会話での最新の出力、ユーザーが指定するファイルや差分、またはユーザーが説明するアプローチを提示する。レポートモードでは、停止して成果物が指定されていないと伝える。
- クリティカリティ（重要度レベル）を設定する： プロトタイプ、社内ツール、本番、または金銭・セキュリティに関わるパス。インタラクティブ：不明確で、どれだけ厳しく評価すべきかに影響する場合は、1回だけ尋ねる。レポート：本番と仮定し、その旨を伝える。クリティカリティはカテゴリスイープの深さを決定する。深刻度バーを動かすことは決してない。
- 台帳（レジャー）を確認する。 台帳のパスを特定する（セクション11を参照）。この成果物の台帳が存在する場合、
references/ledger-format.mdを読む。- 最新のラウンドの任意のIDに対する最新の行が
pendingの場合、ウォークスルーが途中で終了している。再開する：セクション1から5をスキップし、保存されたレコードを読み、最初のpending懸念点からセクション8を続ける。レンズの再実行や再ランク付けは行わない。レポートモードでは、代わりにそれらを OPEN DECISIONS の下にリストする。 - それ以外の場合は、後のラウンドである。セクション11に従う。
- 最新のラウンドの任意のIDに対する最新の行が
1. まず最善のケースを述べる
懸念点を述べる前に、提案が合理的である理由を2、3文で書く：それが解決する問題と、それが尊重する制約。これが書けない場合、提案はまだ理解されていない。もっと読んでから進める。
2. 候補となる懸念点を生成する
そのレンズに到達したら、レンズの参照ファイルを読み込む。L12は最後に実行する。
| # | レンズ | 使用 | 参照先 |
|---|---|---|---|
| L1 | 後知恵としての失敗：リリースされて障害が発生した；原因を遡る | 常時 | references/lens-questions.md |
| L2 | 目標を逆転させる：何が確実に失敗を招くかをリストアップし、どれが存在するか確認する | 常時 | references/lens-questions.md |
| L3 | 隠れた前提：それぞれを挙げ、それが偽だった場合に何が起こるかを問う | 常時 | references/lens-questions.md |
| L4 | よく見落とされる領域のカテゴリスイープ | 常時 | references/category-checklist.md |
| L5 | AI出力に対する、典型的なAIの欠陥のスイープ | 常時、AIが生成した場合 | references/ai-output-checklist.md |
| L6 | 主張を明確にする：曖昧な言葉を検証可能にする | 種類による | references/lens-questions-extended.md |
| L7 | エビデンスを求める：測定したのか、読んだのか、仮定したのか？ | 種類による | references/lens-questions-extended.md |
| L8 | 他の立場：オンコール、セキュリティ、新規参入者、ヘビーユーザー、攻撃者 | 種類による | references/lens-questions-extended.md |
| L9 | 2、3ステップ先まで追跡する | 常時 | references/lens-questions-extended.md |
| L10 | フレーミングに疑問を呈する：正しい問題か、もっと小さな変更で済むか？ | 常時 | references/lens-questions-extended.md |
| L11 | 分離パス：事実、リスク、代替案、レビューの質 | 種類による | references/lens-questions-extended.md |
| L12 | 最悪の障害からその根本的な設計上の選択に至る原因の連鎖 | 種類による | references/lens-questions-extended.md |
「種類による」レンズ、成果物の種類別：
| 成果物の種類 | これらのレンズを追加 |
|---|---|
| 小さな差分またはバグ修正 | なし |
| 機能差分または複数ステップの計画 | L6, L7, L12 |
| 設計、RFC、またはオプション間の決定 | L6, L7, L8, L11, L12 |
| 別のスキルまたはエージェントの出力 | それが生成したものに応じた行を使用 |
懸念点の根拠となる実際のコード、設定、または計画行を読むこと。コードについての推測に基づいた懸念点はエビデンスとはみなされない。
3. フィルタリング
4つのテストすべてを各候補に適用する。いずれかに失敗した候補は破棄する。
- 結果： 誰もそれに対処しなかった場合、実際に何が起こるか？「大したことない」なら破棄。
- 反論： それが実際の問題ではないとする最も強い理由を書く（コードが既にカバーしている、この変更の範囲外である、または害を及ぼさない）。その理由が成立する場合、破棄する。懸念点が生き残った場合、反論を保持し、それがなぜ成立しないかを述べる。
- アクション可能： 具体的なアクションが存在しなければならない。アクションがない場合は破棄。
- 重複ではない： この会話内の別のレビューステップ、呼び出し元のブリーフ、または台帳によって既に報告されているものは破棄する。
4. 深刻度の評価
バーは固定されている。モード、クリティカリティ、ラウンド、時間的制約によって変動しない。
- Critical： 1つの具体的な障害イベントを述べる：トリガー、どのように失敗するか、被害がどの程度広がるか。トリガーは、提案に書かれているとおりに到達可能でなければならない。到達可能なトリガーが特定できない場合、その懸念点は最大でもHighである。
references/severity-downgrade-example.mdを参照。 - High： 害を引き起こす、名前の付けられた現実的なシナリオ。
- Medium： 修正する価値がある。障害イベントは不要。
各懸念点をblocking（ブロッキング）（作業を進める前に修正が必要）またはwatch-item（ウォッチアイテム）（追跡はするが、作業を止める必要はない）のいずれかにマークする。
5. 予算
- すべてのCriticalとすべてのHighを完全に報告する。
- 上位3つのMediumを完全に報告する。その他のMediumは1行でリストする：件数、続けてそれぞれの短いラベル。Mediumを黙って破棄することは決してしない。
- Critical + High が5を超える場合、詳細レビューを停止する。 判定はRETHINKとし、提案をより小さな部分に分割することを推奨する。CriticalとHighのタイトルのみをリストする。
6. 懸念点レコード
報告されるすべての懸念点は、以下のすべてのフィールドを持つ：
### H1: <一行タイトル>
- Severity: High | Failure event: <トリガー> -> <どのように失敗するか> -> <被害範囲>
- Lens: L3 隠れた前提
- Counter-argument: <懸念点に対する最も強い反論>。Fails because <理由>。
- Evidence: <ファイル:行 | 計画ステップ | 引用された決定>
- If ignored: <何が起こるか>
- Action: <具体的な変更>
- Status: blocking | watch-item
IDは深刻度の文字と番号を使用する：C1、H1、M1。IDはどのラウンドでも決して変更されない。Mediumレコードは Failure event: n/a と記述してもよい。
7. 判定
レビューは厳密に1つの判定で終了する：
- PROCEED（進め）： blockingな懸念点はない。注記があってもよい。
- AMEND（修正して進め）： アプローチは妥当。リストされたblockingな懸念点を最初に修正すること。
- RETHINK（考え直せ）： 根本的な欠陥がある、またはセクション5の予算を超過した。
判定の下に、Known risks（既知のリスク） という見出しを追加する。最新の台帳行が risk-accepted であるすべての懸念点（任意のラウンドから）を、そのID、タイトル、ラウンドとともにリストする。ない場合は「Known risks: none」と書く。これらは決してブロックしない。
8. インタラクティブモード
- 最善のケースを表示する（セクション1）。
- 最初の質問の前に、懸念点レコードと、ウォークスルー対象の懸念点ごとに1つの
pending台帳行を書く（台帳リファレンスを参照）。 - ターンごとに1つの懸念点を、最も深刻なものから順に提示する。ユーザーは accept（承認）、reject（却下）、modify（修正）、risk-accept（リスク受容）、または defer（延期） を選択する。
- 構造化された質問ツールが存在する場合（Claude Codeの
AskUserQuestion、OpenCodeのquestion）、それを使用し、懸念点ごとに1つの質問とし、レコード全体を質問テキストに含めて画面に表示し続けるようにする。ツールがオプションを制限する場合は、accept、reject、risk-accept、defer を提供し、modify は自由テキストとして受け付ける。 - Modify: ユーザーの変更を受け入れ、その後、その懸念点を新しい形式で承認されたものとして扱う。Reject: 懸念点は該当しない。Risk-accept: 懸念点は現実のものであるが、ユーザーはそれを受け入れ、今は誰も修正しない。blockingではない。Defer: ウォッチアイテム。後で修正する。
- 各回答の直後に台帳行を追加する。次の質問の前に行うこと。 判定を待ってはいけない。
- 構造化された質問ツールが存在する場合（Claude Codeの
- すべての懸念点に解決策が決まったら、ラウンド2以降では再チェック（セクション11）を実行する。その後、判定と既知のリスク（セクション7）を提示する。
- 少なくとも1つの懸念点が承認または修正された場合は、判定の如何に関わらず、修正された計画（セクション10）を書く。
- 判定行を台帳に追加する。停止し、明示的なゴーサインを待つ。
9. レポートモード
質問はしない。待機もしない。以下の順序で出力する：
- クリティカリティの仮定（もしあれば）。
- 最善のケース。
- すべての懸念点レコード。深刻度でランク付けされ、予算内に収める。
- 判定、および台帳からの既知のリスク。
- OPEN DECISIONS（未解決の判断事項）： 番号付きリスト。各項目は人間が答えられる判断として表現し、推奨オプションとそのトレードオフを続ける：
1. <質問>（C1関連）推奨：<オプション>。トレードオフ：<コストまたはリスク>。
呼び出し元がファイルパスを指定した場合、完全なレポートをそこに書き込む。200語以下のサマリーのみを返す：判定、深刻度ごとの件数、OPEN DECISIONSのタイトル。解決策が open のレコードと行を追加する（台帳リファレンスを参照）。その後停止する。レポートモードでは計画の修正は決して行わない。
10. 修正された計画
インタラクティブモードのみ。すべての懸念点に解決策が決まった後に実行する。少なくとも1つの懸念点が承認または修正された場合は常に書き、判定の如何は問わない。PROCEEDで承認も修正も何もなかった場合のみスキップする。
-
承認された変更を組み込んだ計画全体を再度述べる。解決策だけをリストしてはいけない。
-
統合テーブルを追加する。一致する行がない承認または修正された懸念点を MISSING（欠落） とマークし、その旨をテーブルの上に記載する。
懸念点 解決策 それに対応する計画行 C1 accepted ステップ3：べき等性キーを追加 H2 modified MISSING -
停止する。明示的なゴーサインを待つ。このスキルは決して実装しない。
11. ラウンドと終了条件
- 台帳パス：
${XDG_STATE_HOME:-~/.local/state}/adversarial-review/<スラッグ>.md。最初の書き込みの前に、スラッグと行形式についてreferences/ledger-format.mdを読む。 - 台帳は追記専用である。以前の行を編集または削除してはならない。
- 懸念点は、その解決成果物（コミットSHAまたは計画行）が存在し、その後の変更がそれに触れていない場合にのみ解決されたとみなす。
- 後のラウンドはヘッダー行で開始する：
Round N | carried open: C2, H1 | new last round: 1 Critical, 2 High - ラウンド2以降は、前のラウンドから変更されたものと、その変更が影響を与える可能性のあるもののみをレビューする。そこでの新しいCriticalまたはHighは、変更されたマテリアルにおける新しい動作であり、実際に発火するものでなければならない。
- 台帳に記録された懸念点は、変更がそれを解決したものに触れた場合、または再チェックでそれが悪化したことが判明した場合を除き、再度提起してはならない。
- ラウンド終了時の再チェック（ラウンド2以降）。 判定の前に、最新の行が
deferred、risk-accepted、pending、またはopenであるすべての懸念点を、現在の成果物およびコードに対してチェックする。それぞれに行を1つ追加する：still applies（依然として該当）、no longer applies（該当しなくなった、理由付き）、または got worse（悪化した、深刻度を引き上げて理由を説明）。悪化した懸念点は新たな判断を必要とする：ウォークする（インタラクティブ）か、OPEN DECISIONS（レポート）の下にリストする。古い行は決して変更しない。
終了ルール（ハード）
これらのルールは、このスキル内の他のすべてのルールに優先する。
- 新しいCriticalまたはHighを追加しない後のラウンドはループを終了する。 判定はPROCEED。未解決のMediumはウォッチアイテムになる。持ち越された未解決のCriticalまたはHighは新しいものではないが、依然としてブロックする：このラウンドで解決する（インタラクティブ）か、判定前にOPEN DECISIONSの下にリストする（レポート）。
- ラウンド3でも新しいCriticalが見つかった場合、 コードではなく、作業の分割方法に挑戦する。別の分割方法を推奨する。
- 4ラウンドを超えて実行してはならない。 ラウンド4の後、残っているすべてのブロッカーを番号付きの判断リストとしてユーザーに渡し、停止する。
12. トーン
- 直接的かつ具体的に。「これは～すると失敗する」と書き、「これは潜在的に問題を引き起こす可能性がある」とは書かない。最も重要な懸念点から始める。
- すべての懸念点にレンズ名を明記し、読者が方法を学べるようにする。
- 提案が良好な場合は、明確にそう述べ、PROCEEDを出す。
- 念のため懸念点をでっち上げない。すべての懸念点はファイル、行、または計画ステップを指定する。場所のない一般的なリスクは破棄される。
- レビュー対象のコードを書き換えない。変更を説明し、実際の修正はそれに対処する人に任せる。