| name | discussion-protocol |
| description | Agent Team によるマルチエージェントディスカッションの協調プロトコル。
構造化された多角的探索（Position -> Challenge -> Synthesis）で
設計判断・技術選定・方針決定の合意形成を支援する。
Use when:
- /discuss コマンドでディスカッション実行時
- 設計判断の対立点について多角的議論が必要な時
- spec-plan Phase 4 で設計選択肢の評価が必要な時
Trigger phrases: discuss, deliberate, multi-perspective, team discussion
|
| allowed-tools | Read, Write, Glob, Grep, Task, TaskCreate, TaskUpdate, TaskList, TaskGet, SendMessage, TeamCreate, AskUserQuestion |
| model | sonnet |
| user-invocable | false |
Discussion Protocol
Agent Team による構造化された多角的探索プロトコル。
既存の team-orchestration スキルの共通基盤（検出、フォールバック、サーキットブレイカー）を前提とし、
ディスカッション固有のラウンド制御・収束判定・同意バイアス対策を定義する。
1. プロトコル概要
本質的定義
LLMマルチエージェント「議論」は人間の議論のシミュレーションではなく、
「探索空間の構造的拡大と体系的統合」である。
結果は最終決定ではなく、ユーザーへの判断材料として位置づける。
3ラウンド弁証法構造
Round 1 - Position（必須）:
各メンバーが独立に立場表明（並列実行、他者の意見を見ない）
目的: 探索空間の初期サンプリング、多様性の最大化
Round 2 - Challenge（必須）:
他者の提案への批判に特化
L1: 同意・賛同の表明を禁止
L1: 弱点1つ + 失敗シナリオ1つ + 代替案1つ を必須
目的: 探索空間の境界テスト、同意バイアスの構造的抑制
Round 3 - Synthesis（条件付き）:
批判を踏まえた立場修正 + 構造化された折衷案の提示
モデレーター判定: 未解決の重要な対立があれば実施、なければスキップ
目的: 構造化された折衷 + 残存対立の明示
プリセット
| プリセット | ラウンド数 | 用途 |
|---|
--quick | 2 (Position + Synthesis) | 軽量な意見収集 |
| デフォルト | 2-3 (適応型) | 標準的なディスカッション |
--deep | 5 (最大) | 複雑な設計判断 |
2. チーム構成（3+1+1 モデル）
議論参加者 3名: トピックに応じて動的にアサイン
- 対立軸を含む構成を推奨（推進派 vs 慎重派、抽象 vs 具体 等）
devils-advocate 1名（固定ロール）:
- 全ラウンドで批判的立場を維持
- L1: 暗黙の前提を3つ以上明示すること
- 最終立場では建設的な妥協案を提示
モデレーター 1名 = リーダー:
- プロセス介入専任、議論の内容には介入しない（L1）
- ラウンド管理、収束判定、偽の合意検出、結果統合
最大チームサイズ
- 5名以下: メッシュ型通信（直接 SendMessage）
- 6名以上: ハブ&スポーク型（モデレーター経由）
- 上限: 7名（コンテキスト圧迫防止）
動的ロール選出
トピックに応じてオーケストレーターが自動選出:
- 技術選定: パフォーマンス専門家、セキュリティ専門家、保守性専門家
- 設計判断: UX専門家、アーキテクト、コスト分析家
- 方針決定: ビジネス視点、技術視点、ユーザー視点
--members でカスタムロール指定も可能。
3. 同意バイアス対策（5層防御）
Layer 1: devils-advocate 固定ロール
スポーン時点で批判的立場を付与
Layer 2: Challenge Round の同意禁止 L1ルール
賛同の表明を禁止。弱点+失敗シナリオ+代替案を必須
Layer 3: 構造化ヘッダーによる立場変更の追跡
全メンバーが毎ラウンド「変更 Yes/No + 理由」を記述
Layer 4: Position Round での独立実行
初期立場は他者を見ずに独立して提出（アンカリング防止）
Layer 5: CONSENSUS 時の同意バイアス警告
全員一致時にユーザーに警告表示
4. 収束判定（カテゴリカル4段階）
DIVERGENT: 立場が大きく分散
NARROWING: 共通点が見え始めている
CONVERGING: 合意に接近中
CONSENSUS: 合意に到達（同意バイアス検証が必要）
判定方法
モデレーターが各ラウンド後に主要論点を抽出し、論点ごとの合意状態を評価。
数値スコアではなくカテゴリカル判定を採用（LLMの数値自己評価の信頼性が低いため）。
偽の合意検出
CONSENSUS 到達時:
- 各メンバーの合意根拠を比較
- 根拠が同質的（同じ理由で同意）なら「表面的合意」と判定
- devils-advocate に追加反論を要求
- ユーザーに警告: "Unanimous agreement detected. Verify diversity of reasoning."
5. メッセージ制約（Context Rot 防止）
メンバー間 SendMessage: 200語以内（L1）
モデレーター配布: 300語以内（L2）
最終立場報告: 500語以内（L1、構造化フォーマット）
6. モデレーター（リーダー）の責務
プロセス介入 vs 内容介入（L1）
許可（プロセス介入）:
- 「根拠を示してください」
- 「論点Xが未議論です」
- 「議論が膠着しています。新しい角度から検討してください」
- 「全員が同意していますが、根拠は多様ですか？」
禁止（内容介入）:
- 「A案が正しいと思います」
- 「Bさんの意見に賛成です」
- 「この設計は良くないのでは？」
介入タイミング
| 収束状態 | 介入 |
|---|
| DIVERGENT | 論点の優先順位付けを行い焦点を絞る |
| NARROWING | 正常進行。未議論の観点がないか確認のみ |
| CONVERGING | 偽の合意検出準備。根拠の多様性を観察開始 |
| CONSENSUS | 偽の合意検出実行 |
7. 結果統合フォーマット
完全なフォーマットは reference.md を参照。概要:
## Discussion Result: [トピック]
### 合意マトリクス（論点別合意状態）
### モデレーター裁定（分裂論点への判断）
### 立場変遷（各メンバーの立場変化）
### 少数意見（Dissenting Views）
### 次のアクション
8. サーキットブレイカー
team-orchestration スキルの3段階判断モデルを踏襲。
ディスカッション固有の調整:
- 各ターンタイムアウト: 3分（レビューの5-7分より短い。ディスカッションは短い発言の応酬）
- 全体タイムアウト: デフォルト10分（
--timeout で変更可能）
- フォールバック: Agent Team 利用不可の場合、各ロールを Task tool で独立起動し、リーダーが結果を相互参照して統合
9. 既存スキルとの連携
discussion-protocol（このスキル）
↑ 参照
team-orchestration（共通基盤）
- Agent Team 検出とフォールバック
- Single Writer プロトコル
- AskUserQuestion 中継
- サーキットブレイカー基盤
- TeammateIdle 品質ゲート
Rules (L1 - Hard)
- MUST: 3名以上のディスカッションには必ず1名を devils-advocate として割り当てる
- MUST: Challenge Round では同意・賛同の表明を禁止する
- MUST: devils-advocate は暗黙の前提を3つ以上明示すること
- MUST: モデレーターはプロセス介入のみ行い、内容に関する判断を表明しない
- MUST: 全メンバーの最終立場を構造化フォーマットで回収する
- MUST: CONSENSUS 到達時に同意バイアス検証を実施する
- MUST: Position Round は他者の意見を見ずに独立して実行する
- MUST: 少数意見を結果に記録する（棄却理由も付記）
- MUST: メンバー間 SendMessage は200語以内、最終立場は500語以内
- NEVER: モデレーターが「A案が正しい」等の内容判断を表明する
Defaults (L2 - Soft)
- デフォルト3ラウンド（Position → Challenge → Synthesis）、適応型で2ラウンドに短縮可能
- チーム構成はデフォルト5名（3+1+1）
- 結果ファイルは
docs/specs/{feature}-discussion-{topic-slug}.md に保存
- 偽の合意検出はデフォルトで有効
- 5名以下はメッシュ型通信、6名以上はハブ&スポーク型
Guidelines (L3)
- recommend: 対立軸を含むロール構成を推奨（推進派 vs 慎重派 等）
- prefer: 結果は「合意事項」より「選択肢+トレードオフ+判断問い」として提示することを推奨
- consider: 短時間（5-10分）のプロセスのため、中断時はやり直しで対応
- consider: 議論品質の指標として立場変遷（Position変更の有無）を確認
