菜单
Agent Team によるマルチエージェントディスカッションの協調プロトコル。 構造化された多角的探索（Position -> Challenge -> Synthesis）で 設計判断・技術選定・方針決定の合意形成を支援する。 Use when: - /discuss コマンドでディスカッション実行時 - 設計判断の対立点について多角的議論が必要な時 - spec-plan Phase 4 で設計選択肢の評価が必要な時 Trigger phrases: discuss, deliberate, multi-perspective, team discussion
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/MysMon/Spec-Workflow-Toolkit --skill discussion-protocol命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
設定ファイルとソースコードからプロジェクトの技術スタックを自動検出。 Use when: 新規コードベースでの作業開始、言語/フレームワーク/ツールの特定。 Trigger phrases: detect stack, what framework, identify technology, project setup
REST、GraphQL、gRPC の API 設計パターン。 Use when: API の新規設計、OpenAPI 仕様作成、バージョニング/ページネーション設計。 Trigger phrases: API design, REST endpoint, GraphQL schema, OpenAPI, gRPC, pagination
エバリュエーター・オプティマイザーのフィードバックループによる反復改善。 Use when: 出力品質の反復改善、明確な評価基準がある複雑な出力の最適化。 Trigger phrases: iterate, refine, improve quality, feedback loop, evaluate and optimize
基于 SOC 职业分类
正在显示 SKILL.md
| 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 |
Agent Team による構造化された多角的探索プロトコル。 既存の team-orchestration スキルの共通基盤（検出、フォールバック、サーキットブレイカー）を前提とし、 ディスカッション固有のラウンド制御・収束判定・同意バイアス対策を定義する。
LLMマルチエージェント「議論」は人間の議論のシミュレーションではなく、 「探索空間の構造的拡大と体系的統合」である。 結果は最終決定ではなく、ユーザーへの判断材料として位置づける。
Round 1 - Position（必須）:
各メンバーが独立に立場表明（並列実行、他者の意見を見ない）
目的: 探索空間の初期サンプリング、多様性の最大化
Round 2 - Challenge（必須）:
他者の提案への批判に特化
L1: 同意・賛同の表明を禁止
L1: 弱点1つ + 失敗シナリオ1つ + 代替案1つ を必須
目的: 探索空間の境界テスト、同意バイアスの構造的抑制
Round 3 - Synthesis（条件付き）:
批判を踏まえた立場修正 + 構造化された折衷案の提示
モデレーター判定: 未解決の重要な対立があれば実施、なければスキップ
目的: 構造化された折衷 + 残存対立の明示
| プリセット | ラウンド数 | 用途 |
|---|---|---|
--quick | 2 (Position + Synthesis) | 軽量な意見収集 |
| デフォルト | 2-3 (適応型) | 標準的なディスカッション |
--deep | 5 (最大) | 複雑な設計判断 |
議論参加者 3名: トピックに応じて動的にアサイン
- 対立軸を含む構成を推奨（推進派 vs 慎重派、抽象 vs 具体 等）
devils-advocate 1名（固定ロール）:
- 全ラウンドで批判的立場を維持
- L1: 暗黙の前提を3つ以上明示すること
- 最終立場では建設的な妥協案を提示
モデレーター 1名 = リーダー:
- プロセス介入専任、議論の内容には介入しない（L1）
- ラウンド管理、収束判定、偽の合意検出、結果統合
トピックに応じてオーケストレーターが自動選出:
--members でカスタムロール指定も可能。
Layer 1: devils-advocate 固定ロール
スポーン時点で批判的立場を付与
Layer 2: Challenge Round の同意禁止 L1ルール
賛同の表明を禁止。弱点+失敗シナリオ+代替案を必須
Layer 3: 構造化ヘッダーによる立場変更の追跡
全メンバーが毎ラウンド「変更 Yes/No + 理由」を記述
Layer 4: Position Round での独立実行
初期立場は他者を見ずに独立して提出（アンカリング防止）
Layer 5: CONSENSUS 時の同意バイアス警告
全員一致時にユーザーに警告表示
DIVERGENT: 立場が大きく分散
NARROWING: 共通点が見え始めている
CONVERGING: 合意に接近中
CONSENSUS: 合意に到達（同意バイアス検証が必要）
モデレーターが各ラウンド後に主要論点を抽出し、論点ごとの合意状態を評価。 数値スコアではなくカテゴリカル判定を採用（LLMの数値自己評価の信頼性が低いため）。
CONSENSUS 到達時:
メンバー間 SendMessage: 200語以内（L1）
モデレーター配布: 300語以内（L2）
最終立場報告: 500語以内（L1、構造化フォーマット）
許可（プロセス介入）:
- 「根拠を示してください」
- 「論点Xが未議論です」
- 「議論が膠着しています。新しい角度から検討してください」
- 「全員が同意していますが、根拠は多様ですか？」
禁止（内容介入）:
- 「A案が正しいと思います」
- 「Bさんの意見に賛成です」
- 「この設計は良くないのでは？」
| 収束状態 | 介入 |
|---|---|
| DIVERGENT | 論点の優先順位付けを行い焦点を絞る |
| NARROWING | 正常進行。未議論の観点がないか確認のみ |
| CONVERGING | 偽の合意検出準備。根拠の多様性を観察開始 |
| CONSENSUS | 偽の合意検出実行 |
完全なフォーマットは reference.md を参照。概要:
## Discussion Result: [トピック]
### 合意マトリクス（論点別合意状態）
### モデレーター裁定（分裂論点への判断）
### 立場変遷（各メンバーの立場変化）
### 少数意見（Dissenting Views）
### 次のアクション
team-orchestration スキルの3段階判断モデルを踏襲。 ディスカッション固有の調整:
--timeout で変更可能）discussion-protocol（このスキル）
↑ 参照
team-orchestration（共通基盤）
- Agent Team 検出とフォールバック
- Single Writer プロトコル
- AskUserQuestion 中継
- サーキットブレイカー基盤
- TeammateIdle 品質ゲート
docs/specs/{feature}-discussion-{topic-slug}.md に保存