the-grilling

グリリング：敵対的ブレインストーミング

概要

グリリングは、1回限りのマルチエージェント・ディベートです。提案者が提案し、悪魔の代弁者が攻撃し（最初にアイデア、次に提案）、統合役が修正します。ラウンドはありません。各エージェントはちょうど1回だけ実行されます。ドンへの質問は一度に1つだけで、質問を列挙してはいけません。提案を行う前に、アイデアを吟味します。

トリガー

ドンが偵察ドシエを承認した後（偵察完了）に実行されます。

厳守ルール（交渉不可）

1. **ラウンドはありません。**各エージェント（提案者、悪魔の代弁者、統合役）はちょうど1回だけ実行されます。ループして戻ってはいけません。ラウンド2はありません。
2. **アイデアが先です。**悪魔の代弁者は、提案を攻撃する前に、ドンの目的（アイデア）を攻撃します。アーキテクチャを提案する前に、偵察ドシエの類似事例、前提、スコープ、類推を踏まえて、アイデアについてドンに質問します。
3. **一度に質問は1つです。**ドンとのやり取りでは、必ず質問を1つだけ行います。次の質問をする前に、回答を待ちます。これは、質問をまとめて出力するサブエージェントの出力よりも優先されます。以下の「ドンへの質問プロトコル」を参照してください。
4. **質問を列挙してはいけません。**2つ以上の異なる質問を含むドン宛てのメッセージは、番号付きであっても違反です。最も重要な質問から始め、回答を得た後で、次の質問がまだ必要かどうかを判断してください。

プロトコル（1回限り）

フェーズA — アイデアを吟味する

提案を作成する前に、統括エージェントは偵察ドシエ（特に類似事例、先行事例、グリーンフィールドモードの場合は「制約とリスクの調査」）を参照し、目的そのものについてドンに質問します。

1. 統括エージェントは偵察ドシエを読み、ドンが判断する必要のある未解決の前提、スコープの曖昧さ、類似事例との比較に関する判断をすべて抽出します。
2. 質問の優先順位を付けます。アイデアの妥当性に最も大きく関わるものから始めます（問題の捉え方 → 隠れた前提 → スコープ → 類似事例の選択）。
3. ドンには一度に1つだけ質問します。回答を得るたびに、次に予定していた質問がまだ関連するかどうかを判断します。ドンの回答によって、疑問が解消されたり、不要になったり、あるいは新たに、より緊急性の高い疑問が生じたりする可能性があります。
4. アイデアに関する重要な質問がなくなるまで続けます。ドンは「アイデアは固まりました。アーキテクチャに進んでください」と伝えることもできます。

アイデアの判定（統括エージェント）：

• 却下（REJECT） — 表明された目的に問題があり、ドンによる再定義が必要です。中断し、目的を言い直すか中止するようドンに求めます。
• 要修正（CHALLENGE） — 目的には上記で確認した修正が必要です。それらを反映し、フェーズBに進みます。
• 妥当（SOUND） — 目的は妥当です。フェーズBに進みます。

REJECTの場合：停止します。判定と理由をドンに伝えます。提案者を起動してはいけません。ドンは目的を修正する（偵察に戻る）か、中止できます。

フェーズB — 提案者（1回限り）

提案者サブエージェントを1回だけ起動します。偵察ドシエと、ドンのアイデアに関する回答を反映した修正後の目的を読み、提案を1つ作成します。proposer-prompt.mdを参照してください。

フェーズC — 悪魔の代弁者（1回限り）

悪魔の代弁者サブエージェントを1回だけ起動します。アーキテクチャ上の欠陥、セキュリティ、憲章違反、リグレッション、スケーラビリティについて提案を攻撃します。フェーズAで提起されたアイデアレベルの懸念はすでに記録されています。悪魔の代弁者がそれらを再検討するのは、提案によって目的のスコープが実質的に変わる場合に限ります。devils-advocate-prompt.mdを参照してください。

フェーズD — ドンの意見を聞く（一度に1つの質問）

悪魔の代弁者による攻撃の要約をドンに提示します。その後、次のように質問します。

1. 最初の質問：「悪魔の代弁者による攻撃に同意しますか？」—回答を待ちます。
2. ドンの回答に基づいて、次の質問を決めます。必要な場合に限り、「見落としている懸念はありますか？」と質問し、回答を待ちます。
3. 必要な場合に限り、「提案の一部を覆したいですか？」と質問し、回答を待ちます。

前の回答ですでに決着している場合、その質問は行いません。ドンの回答をすべて収集します。

フェーズ E — シンセサイザー（1 回のみ）

シンセサイザーのサブエージェントを 1 回だけ起動します。有効な攻撃とドンのフィードバックを取り入れ、提案の有効な要素を擁護し、最終的な修正版の解決策を作成します。synthesizer-prompt.md を参照してください。

シンセサイザーの出力が最終的な合意です。2 回目の攻撃フェーズはありません。

終了条件

グリリングはフェーズ E の終了後に終わります。ナッシュ均衡のチェックも、ラウンド制限も、ラウンドが存在しないためラウンド 2 での早期終了もありません。1 回のパスで議論全体が完了します。

例外 — 最善の合意案： シンセサイザーが、デビルズ・アドボケートが重大な異議を提起し、ドンと提案を 1 回の統合パスで解決できないと判断した場合、シンセサイザーは未解決の異議を記録した最善の合意案を代わりに作成します。

## Best Available Consensus

**Proposal:** <Final revised solution>

### Resolved Points
- <Points where all parties agree>

### Unresolved Objections
1. <Objection> — Risk: HIGH/MEDIUM/LOW — Mitigation: <if any>
2. ...

### Don's Decision Required
Accept this consensus (with documented risks), reject and restart, or table.

ドンへの質問プロトコル（厳守）

ドンとのやり取りでは、毎回質問を 1 つだけ行います。次の質問をする前に、ドンの回答を待ちます。

このルールは、複数の質問を 1 つのメッセージにまとめるテンプレートやサブエージェントの出力より優先されます。オーケストレーションエージェント（グリリングを実行するエージェント）は、次の手順に従う必要があります。

1. サブエージェントがドンに投げかける質問をすべて特定する
2. 重要度の高い順（最も重要な判断を最初）に並べる
3. 最初の質問を提示し、ドンの回答を待つ
4. 回答後、次に予定していた質問がまだ必要か再評価する。回答ですでに解決している場合は、その質問を省く
5. まだ必要な次の質問を提示し、再び回答を待つ
6. 必要な質問がなくなるまで繰り返す
7. ドンの回答をすべて集め、次のサブエージェントにまとめて渡す

アンチパターン — 質問の一括提示： 番号付きの質問リストを 1 つのメッセージでドンに提示してはいけません。サブエージェントが「ドンへの質問」リストを出力した場合でも、オーケストレーションエージェントは質問を 1 メッセージにつき 1 つずつ順番に行い、不要になった質問は省きます。

質問ツールのスキーマ（厳守）

ドンに質問するために question ツールを使用する場合、各選択肢には null 以外の文字列である両方のフィールドを必ず指定してください。

label: string       — concise display text, 1-5 words
description: string — explanation of what choosing this option means

description は決して null、undefined、または省略にしてはいけません。 「はい」や「いいえ」のような明白な選択肢であっても、説明を記載してください。

Bad:  { label: "Yes" }
Bad:  { label: "Yes", description: null }
Good: { label: "Yes", description: "I agree with the Devil's-Advocate's attack" }
Good: { label: "No",  description: "I reject the attack — the proposal stands" }

このスキーマに違反すると、検証エラーが発生してツールの呼び出しに失敗します。

これは次の項目に適用されます。

• フェーズ A のアイデアに関する質問（アイデアごとの質問）
• フェーズ D でのドンの意見
• 最善の合意案に関する判断
• シンセサイザーまたは提案者がドンに投げかける質問

理由： ドンは、同時に 3 つの質問をされるより、1 つの質問に答えるほうが、より良い回答を返します。質問をまとめると、考える負担が増し、判断の質が下がります。

繰り返しの検出（1 回のみのパスに関する注記）

1 回のみのパスでは、フェーズ A のアイデアに関する質問とフェーズ C のデビルズ・アドボケートによる攻撃の間で繰り返しが生じることは想定内であり、問題ありません。両者は異なる角度からアイデアを問いただします。同じ懸念が重複している場合はシンセサイザーが指摘し、最終的な合意で同じ懸念を重複して数えないようにします。

サブエージェントのプロンプト

プロポーザー、デビルズ・アドボケート、シンセサイザーは、このディレクトリにあるプロンプトを使用するサブエージェントとして起動されます。

• proposer-prompt.md — プロポーザー用プロンプトテンプレート
• devils-advocate-prompt.md — デビルズ・アドボケート用プロンプトテンプレート
• synthesizer-prompt.md — シンセサイザー用プロンプトテンプレート

ディスパッチ手順

各サブエージェントをディスパッチするために Task ツールを呼び出すときは、次の手順に従ってください。

1. スキルのディレクトリにある、そのエージェント用のプロンプトファイルを読み込みます
2. テンプレートのプレースホルダー（ドシエの内容、Don によるアイデア詰問への回答、Devils-Advocate の出力、Don からのフィードバックなど）を埋めます
3. subagent_type には、該当する名前付き Gangsta エージェント（"proposer"、"devils-advocate"、"synthesizer"）を設定します。Gangsta のインストールでは無効なため、"general" や "general-purpose" は使用しないでください
4. 記入済みのプロンプト全体を prompt パラメーターに含めます

重要 — プラットフォームのエージェントタイプ： Gangsta のインストールで有効な subagent_type の値は、名前付きのカスタムエージェントである "associate"、"soldier"、"the-inspector"、"proposer"、"devils-advocate"、"synthesizer" です。組み込みの "general" エージェントと "explore" エージェントは無効化されています。"general-purpose"、"Task"、"oracle"、"fixer"、"explorer"、"council" は絶対に使用しないでください。 プラットフォーム全体の対応表については、using-gangsta/references/opencode-tools.md を参照してください。

出力

Grilling では、独立したトランスクリプトファイルは作成しません。代わりに、進行役エージェントが討論の最後に Grilling Conclusions の要約を作成します。この要約は、次のフェーズ（The Sit-Down）に直接渡され、Contract に含められます。

Grilling Conclusions には、次の内容を含める必要があります。

• アイデアの判定： REJECT / CHALLENGE / SOUND。Phase A での Don によるアイデアに関する回答を記録します
• 主要な決定事項： 決定した各アーキテクチャ／設計上の事項と、その根拠
• 却下した選択肢： 検討のうえ却下した各選択肢とその理由（Recon Dossier にある類似事例のうち、採用しなかったものも含む）
• 未解決の異議： リスクを認識しつつも受け入れたもの（Best Available Consensus が発動した場合）
• 終了理由： Single-pass complete / Best Available Consensus

進行役エージェントはこの要約をコンテキスト内に保持します。別ファイルとして保存することはありません。

チェックポイント

---
heist: <heist-name>
phase: the-grilling
status: completed
timestamp: <ISO 8601>
next-action: Proceed to The Sit-Down
artifacts: []
note: Grilling Conclusions passed in-context to The Sit-Down for inclusion in the Contract
---

オメルタの遵守状況

• 導入ルール：Proposer、Devils-Advocate、Synthesizer は直接やり取りせず、すべてこのスキルを介して調整されます
• 真実のルール：すべての批判と提案は、Recon Dossier、Constitution、または具体的な技術的事実を根拠として示します
• 可用性のルール：完了後、トランスクリプトとチェックポイントを保存します
• ラウンド禁止ルール：各エージェントの実行は厳密に1回とし、循環的な再批判のループは行いません
• アイデア優先ルール：Phase A では、Phase B でアーキテクチャを提案する前にアイデアを厳しく検討します
• 質問を一度に1つだけにするルール：複数の質問をまとめて Don に提示しません