Red Team

概要

<!-- CANONICAL: shared/dispatch-convention.md -->

すべてのサブエージェント ディスパッチはディスク仲介ディスパッチを使用します。完全なプロトコルについては shared/dispatch-convention.md を参照してください。

あらゆる成果物に対する敵対的レビュー。Devil's Advocate サブエージェントをディスパッチして仕事を攻撃し、検出事項を修正してから、FRESH な Devil's Advocate をディスパッチして再度攻撃します。クリーンになるか停滞が検出されるまで反復します。

コア原則： 毎ラウンド新しい視点。アンカリングなし、確認バイアスなし。

開始時に告知： 「この成果物に敵対的レビューを行うために Red Team スキルを使用しています。」

使用時期

• 設計ドキュメントが完成したとき（計画前）
• 実装計画がレビューに合格したとき（実行前）
• 実装が完了したとき（終了前）
• あらゆる成果物に対して敵対的レビューが必要なとき
• ビルド パイプラインが Red Team を要求しているとき

反復ループ

digraph red_team_loop {
  "Dispatch FRESH Devil's Advocate" -> "Reviewer returns findings";
  "Reviewer returns findings" -> "No Fatal/Significant issues" [label="clean"];
  "No Fatal/Significant issues" -> "Artifact approved -- proceed";
  "Reviewer returns findings" -> "Fatal/Significant issues found";
  "Fatal/Significant issues found" -> "Dispatch fix agent";
  "Dispatch fix agent" -> "Score issues (Fatal=3, Significant=1)";
  "Score issues (Fatal=3, Significant=1)" -> "Compare weighted score to prior round";
  "Compare weighted score to prior round" -> "Dispatch FRESH Devil's Advocate" [label="strictly lower score = progress"];
  "Compare weighted score to prior round" -> "Escalate to user" [label="same or higher score = stagnation"];
  "Reviewer returns findings" -> "Escalate to user" [label="architectural concern"];
}

ルール

1. 毎ラウンド新しいレビュアー — 毎回新しいサブエージェントをディスパッチします。前回のレビュアーの検出事項を次のレビュアーに渡しません。各レビュアーは成果物をゼロベースで見ます。
2. 停滞 = エスカレーション — 重み付けスコアリングを使用して停滞を検出します（下記参照）。重み付けスコアが厳密に低下していない場合は、停止してユーザーにエスカレーションします。両ラウンドの完全な検出事項を含めます。
3. アーキテクチャ上の懸念はループをバイパス — ラウンド数や進捗に関わらず即座にエスカレーションします。
4. ラウンド数上限なし — 各ラウンドが進捗を示す限りループを継続します。呼び出し元（例：crucible:quality-gate）はグローバル セーフティ リミットを設定できます。
5. Fatal と Significant のみカウント — Minor な観察はログに記録されますが、停滞検出にはカウントされず、修正ラウンドをトリガーしません。

停滞検出

停滞は生の問題数ではなく、重み付けスコアリングを使用して検出します。これにより、Fatal の問題が Significant に変換される場合（これは本当の進捗です）の誤検知を防ぎます。

重み付け： Fatal = 3 ポイント、Significant = 1 ポイント。

例： ラウンド 1 で 2 件の Fatal + 1 件の Significant = スコア 7。修正者が両方の Fatal を排除しても、3 件の新しい Significant が現れます。ラウンド 2 で 0 件の Fatal + 3 件の Significant = スコア 3。これは進捗です（3 < 7）、停滞ではありません。

進捗には以下のいずれか：

• 重み付けスコアが前ラウンドより厳密に低い、または
• Fatal 数が厳密に低く、かつ重み付けスコアが同じかそれ以下

どちらの条件も満たされない場合、それは停滞です。 両ラウンドの検出事項をユーザーにエスカレーションします。

問題の分類

Devil's Advocate はすべてのチャレンジを分類する必要があります：

• Fatal： 成果物は失敗するか、不正な出力を生成します。対処する必要があります。
• Significant： 成果物は機能しますが、有意義なリスクまたは見落とされた機会があります。対処すべきです。
• Minor： 細かい指摘または好みの問題。ログに記録しますが、ブロックしません。

使用方法

1. 成果物の種類と修正メカニズムを決定する

成果物	修正メカニズム
設計ドキュメント	Plan Writer サブエージェントがドキュメントを修正
実装計画	Plan Writer サブエージェントが計画を修正
コード/実装	修正エージェント（新規、元の実装者ではない）
ドキュメント	修正エージェント
スタンドアロン呼び出し	呼び出し元が決定

2. Devil's Advocate をディスパッチ

このディレクトリの red-team-prompt.md テンプレートを使用します。以下を提供します：

• 完全な成果物の内容（ディスパッチ ファイルに含める、サブエージェントにファイルを読ませない）
• プロジェクト コンテキスト（既存システム、制約、技術スタック）
• 成果物が何を達成すべきか

モデル：Opus （敵対的分析は最高のモデルが必要）

3. 検出事項を処理する

• Fatal/Significant な問題がない： 成果物が承認されます。進行します。
• Fatal/Significant な問題が見つかった： 重み付けスコア（Fatal=3、Significant=1）を計算します。修正メカニズムをディスパッチします。その後、ステップ 4 に進みます。
• アーキテクチャ上の懸念： 直ちにユーザーにエスカレーションします。修正を試みません。

4. 修正後の再レビュー

新しい Devil's Advocate サブエージェントをディスパッチします（フレッシュ、前の文脈なし）。重み付けスコアを計算して比較します：

• 重み付けスコアが厳密に低い： 進捗。ステップ 3 にループバックします。
• 重み付けスコアが同じかそれ以上： 停滞。両ラウンドの検出事項をユーザーにエスカレーションします。

Devil's Advocate がないもの

• コード レビュアー（スタイル、命名、品質をチェックしない — それは crucible:code-review）
• ブロッキングのためのブロッカー — チャレンジは具体的で実行可能である必要があります
• リライター — 彼らはチャレンジします、代替案を作成しません

深さの キャリブレーション

レビュアーが予想より少ない検出事項を返す場合、レビューは浅い可能性があります。2 番目のレビュアーを以下の指示でディスパッチします：「前のレビュアーは N 件の問題を発見しました。彼らが見落としたものを見つけてください。」

成果物	予想される検出事項（Fatal + Significant）	最小カバー次元
設計ドキュメント	5-10	全 6 つ
実装計画	3-8	致命的欠陥、隠れたリスク、脆弱性、前提条件
コード（機能）	3-6	致命的欠陥、隠れたリスク、脆弱性
コード（リファクタリング）	2-5	致命的欠陥、前提条件、完全性

これらはガイドラインであり、クォータではありません。1 件の検出事項で本当にクリーンで徹底的な次元カバレッジを持つ成果物は問題ありません。1 件の検出事項だけでも 1 次元のみに対処するレビューは、成果物に関わらず浅いです。

鉄則

敵対的レビューなしでは、どの成果物も出荷されません。
コード レビューは必要ですが、十分ではありません。

コード レビューは品質をチェック — コードは正しい、きれい、よく構成されている？Red Team は前提条件を攻撃 — これは実際に敵対的な条件下で機能する？入力が悪意のある場合、依存関係が失敗する場合、負荷が予想を超える場合は何が起こる？これらは重複しない懸念です。コード レビューに合格したことは、Red Team が不要であることの証拠ではありません。

正当化防止

言い訳	現実
「コード レビューが既に合格している」	コード レビューと Red Team は重複しないカバレッジを持ちます。レビューは品質をチェックします。Red Team は敵対的な条件下での前提条件を攻撃します。両方が必要です。
「これはマイナー チェンジです」	重要なパス内のマイナー チェンジは不均衡な影響範囲を持ちます。小さい差分は微妙なバグが隠れている場所です — レビューするコードが少ないほど、どこを見るべきか明らかでなくなります。
「スケジュールに遅れている」	敵対的レビューをスキップすると数時間節約できますが、本番環境で問題が現れると数日のコストがかかります。Red Team はこれらの問題を見つける最も安い場所です。
「設計は徹底的でした」	徹底的な設計には徹底的な障害モードがあります。複雑さ = 攻撃面。より多くの思考が入ったほど、より多くの前提条件に異議を唱えます。
「単なるリファクタリング、動作は変わらない」	リファクタリングは同等性の前提条件が隠れている場所です。Red Team は同等性クレーム — 「何も変わらなかった」が何か変わった最も危険なバグを検証します。
「品質ゲートが後で捕捉する」	品質ゲートは Red Team を呼び出します。ここをスキップすることはそこもスキップすることを意味します。
「尋問官が既にテストした」	尋問官はコンポーネント間動作の実行可能なテストを書きます。Red Team は設計の前提条件と失敗モードを攻撃し、テストとして表現できません。異なるツール。
「我々は既に N ラウンドやった」	前のラウンドは修正するべき物を見つけました。これは成果物がレビューを必要とした証拠であり、今クリーンであることの証拠ではありません。新しい視点、毎ラウンド。

Red Flag

プロセス違反 — 決して：

• 複数のラウンドで同じレビュアー サブエージェントを再利用する
• 前回の検出事項を次のレビュアーに渡す
• 修正後の再レビューをスキップ（「修正は問題ないように見える、進みましょう」）
• Fatal 問題を無視する
• 修正されていない Significant 問題を続行する

正当化をスキップ — 以下を考えている自分に気づいたら STOP：

• 「この成果物は敵対的レビューを必要としない」
• 「スコープが Red Team には小さすぎる」
• 「時間が足りない、このパスをスキップ」
• 「コード レビュー/尋問官が既にこれをカバーしている」
• 「ユーザーはスキップするよう言った」（ユーザーはオーバーライドできますが、最初にリスクを明確に名付けてください）

デュアルモード操作

Red Team は呼び出し元に応じて 2 つのモードで動作します：

crucible:quality-gate で呼び出された場合： シングルパスのみを実行します。このラウンドの検出事項を返します。反復しない、停滞検出を適用しない、修正エージェントをディスパッチしない。品質ゲートはループ、停滞検出、修正ディスパッチを所有します。あなたはレビュアーです、コーディネータではありません。

直接呼び出された場合 （例：crucible:finish またはスタンドアロン）: 上記で説明されているように、停滞検出、修正ディスパッチ、エスカレーションを備えた完全な反復ループを実行します。

マルチモデル コンセンサス： コンセンサス適格なラウンドで品質ゲートによって呼び出された場合、品質ゲートはコンセンサス MCP ツール経由でマルチモデル ディスパッチを処理します。Red Team 自体はコンセンサスを呼び出しません — 品質ゲート オーケストレータは適格なラウンドで Red Team ディスパッチをコンセンサス呼び出しに置き換えます。スタンドアロンで呼び出された場合、Red Team はシングルモデル ディスパッチのみを使用します。

外部モデル レビュー（オプション）

直接呼び出しのみ。 シングルパス モード（品質ゲートによって呼び出された）で動作するときは、このセクション全体をスキップしてください — 品質ゲートは独自の外部レビュー統合を処理します。

ホスト Red Team サブエージェントをディスパッチした後、external_review MCP ツールを以下で呼び出します：

• prompt: skills/shared/external-review-prompt.md の内容
• context: ホスト レビュアーに提供される同じ成果物 + 攻撃プロンプト コンテキスト
• skill: "red_team" (スキル単位のトグル強制のトップレベル引数)
• metadata: {"skill": "red_team"} (追跡可能性)

スキル単位のトグル： サーバーは skill 引数を外部レビュー構成の skills.red_team に対してチェックします。true に設定されている場合のみアクティブ。external_review MCP ツールが利用不可またはコールが失敗した場合は、黙ってスキップしてホスト検出事項のみで続行します。

外部パースペクティブをホスト Devil's Advocate 検出事項の後に出力に追加します。外部検出事項は同じ Fatal/Significant/Minor 分類を使用しますが、情報のみ — 停滞スコアリング（INV-2）にはカウントされません。ホスト Red Team 検出事項のみがスコアリング アルゴリズムを駆動します。

統合

呼び出し元：

• crucible:quality-gate — 各ゲート ポイント（シングルパス モード）。ビルドは品質ゲートを呼び出し、品質ゲートは Red Team を呼び出します。
• crucible:finish — オプション提示前（完全ループ モード、直接、品質ゲート経由ではない）

ペア：

• crucible:innovate — 各ゲートで Red Team 前に実行

プロンプト テンプレートを参照：red-team/red-team-prompt.md