multi-agent-brainstorming について
設計者、レビュー担当、仲裁者に範囲を定めた役割を割り当て、順番にレビューして決定と終了条件を記録するスキルです。実装前の設計検証に使い、ロールプレイを独立したレビューとして扱わないよう求めます。
主な機能
- 01設計者とレビュー担当の役割設定
- 02順次進行する批評と修正
- 03異議と対応を記録する決定ログ
- 04仲裁結果と終了条件の明示
- 05レビューと修正の予算設定
活用シーン
- 01実装前の設計の検証
- 02前提と失敗要因の発見
- 03非機能制約の評価
- 04レビュー決定と未解決事項の記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/multi-agent-brainstormingを入力して読み込まれたか確認します。
詳細
マルチエージェントによるブレインストーミング（構造化設計レビュー）
目的
複数の制約付きエージェントを使って正式なピアレビューのプロセスをシミュレートし、 単一エージェントによる設計を堅牢で、レビューによって検証された設計へと変換します。
このスキルの目的は次のとおりです。
- 隠れた前提を明らかにする
- 早い段階で障害モードを特定する
- 非機能要件を検証する
- 実装前に設計に負荷をかけて検証する
- アイデアが無秩序に広がるのを防ぐ
これは並行ブレインストーミングではありません。 役割を厳密に定めた、順次進行の設計レビューです。
実際に個別に呼び出されたレビュアーと、1 つのモデルが役割を演じている場合を区別してください。ロールプレイによる独立した合意を主張してはいけません。認可された委任範囲内で、利用可能なホストエージェントのみを使用してください。レビューと改訂の上限を設定し、収束しない場合は未解決の問題とともに APPROVED、REVISE、または REJECT で終了してください。呼び出されていないレビュアーを、呼び出されたものとして数えてはいけません。このレビューは、実装や安全性の認証を許可するものではありません。
運用モデル
- 1 つのエージェントが設計します。
- 他のエージェントがレビューします。
- いずれのエージェントも、委任された範囲を超えてはいけません。
- 創造性は集中させ、批評は分散させます。
- 決定事項を明示し、記録します。
このプロセスにはゲートが設けられ、設計上の意図に基づいて終了します。
エージェントの役割（必須）
各エージェントには、厳格な担当範囲の制限が適用されます。
1️⃣ 主任設計者（リードエージェント）
役割：
- 設計を担当します
- 標準の
brainstormingスキルを実行します - 決定ログを管理します
許可されること：
- 明確化のために質問する
- 設計案や代替案を提案する
- フィードバックに基づいて設計を改訂する
許可されないこと：
- 最終設計を自ら承認する
- レビュアーの異議を無視する
- ロック後に要件を作り出す
2️⃣ 懐疑派／挑戦者エージェント
役割：
- 設計が失敗すると仮定します
- 弱点とリスクを特定します
許可されること：
- 前提に疑問を投げかける
- エッジケースを特定する
- 曖昧さや過信を指摘する
- YAGNI 違反を指摘する
許可されないこと：
- 新機能を提案する
- システムを再設計する
- 代替アーキテクチャを提示する
質問の指針：
「この設計が本番環境で失敗すると仮定してください。なぜ失敗するのでしょうか？」
3️⃣ 制約ガーディアンエージェント
役割：
- 非機能要件と現実世界の制約を徹底させます
注目領域：
- パフォーマンス
- スケーラビリティ
- 信頼性
- セキュリティとプライバシー
- 保守性
- 運用コスト
許可されること：
- 制約に違反する設計を却下する
- 制限の明確化を求める
許可されないこと：
- プロダクトの目標について議論する
- 機能の変更を提案する
- 明示された要件を超えて最適化する
4️⃣ ユーザーアドボケイトエージェント
役割：
- エンドユーザーを代表します
注目領域：
- 認知負荷
- 使いやすさ
- フローの明確さ
- ユーザー視点でのエラー処理
- 意図と体験の不一致
許可されること：
- 混乱を招く点や誤解を招く点を特定する
- 不適切なデフォルト設定や不明瞭な挙動を指摘する
許可されないこと：
- アーキテクチャを再設計する
- 機能を追加する
- 明示されたユーザーの目標を覆す
5️⃣ インテグレーター／調停者エージェント
役割：
- 対立を解決します
- 決定事項を最終確定します
- 終了基準を徹底させます
許可されること：
- 異議を受け入れる、または退ける
- 設計の改訂を求める
- 設計が完成したと宣言する
許可されないこと：
- 新しいアイデアを作り出す
- 要件を追加する
- 正当な理由なく、ロック済みの決定を再び議論に戻す
プロセス
フェーズ 1 — 単一エージェントによる設計
- 主任設計者が標準の
brainstormingスキルを実行します - 理解のロックを完了し、確認します
- 初期設計を作成します
- 決定ログを開始します
この段階では、他のエージェントは参加しません。
フェーズ 2 — 構造化レビューの反復
エージェントは、次の順序で1 つずつ呼び出されます。
- 懐疑派／挑戦者
- 制約ガーディアン
- ユーザーアドボケイト
各レビュアーについて：
- フィードバックは明示的で、担当範囲内でなければなりません
- 異議では、前提または決定事項を参照しなければなりません
- 新機能を導入してはいけません
主任設計者は次のことを行わなければなりません。
- 各異議に回答する
- 必要に応じて設計を改訂する
- 決定ログを更新する
フェーズ 3 — 統合と裁定
インテグレーター／裁定者は、次の内容を確認します。
- 最終設計
- Decision Log
- 未解決の異議
裁定者は、次の事項を明示的に決定する必要があります。
- どの異議を受け入れるか
- どの異議を却下するか（根拠も示す）
Decision Log（必須成果物）
Decision Logには、次の内容を記録する必要があります。
- 決定事項
- 検討した代替案
- 提起された異議
- 解決方法と根拠
ログが完成していない設計は、有効と見なされません。
終了基準（厳守）
次のすべてを満たす場合に限り、マルチエージェント・ブレインストーミングを終了できます。
- Understanding Lockが完了している
- すべてのレビュアーエージェントが呼び出されている
- すべての異議が解決されているか、明示的に却下されている
- Decision Logが完成している
- 裁定者が設計を承認可能と宣言している
基準が1つでも満たされていない場合：
- レビューを続行する
- 実装に進まないでください このスキルがルーティングレイヤーまたはオーケストレーションレイヤーによって呼び出された場合、最終判断を APPROVED、REVISE、REJECT のいずれかで、簡潔な根拠とともに明示的に報告する必要があります。
このスキルが防ぐ失敗パターン
- アイデアの氾濫による混乱
- 合意の捏造
- 過信した単独エージェントによる設計
- 隠れた前提
- 時期尚早な実装
- 終わりのない議論
主な原則
- 設計者は1人、レビュアーは複数
- 創造性は一元化する
- 批評には制約を設ける
- 決定事項を明示する
- プロセスを必ず終結させる
最後に
このスキルが自信を持って答えるために存在する問いは、次の1つです。
「この設計が失敗した場合、早期に問題を発見するために、合理的にできることはすべて行ったか？」
答えが明確でない場合は、このスキルを終了しないでください。
使用するタイミング
このスキルは、概要で説明されているワークフローやアクションの実行に適用できます。
例
ユーザーのリクエスト：
このタスクに @multi-agent-brainstorming を使用してください。実装前に設計を検証し、隠れた前提を明らかにし、失敗パターンを特定するために、複数の専門エージェントによる構造化されたピアレビューのプロセスをシミュレートしてください。
制限事項
- このスキルは、タスクが上記の範囲に明確に一致する場合にのみ使用してください。
- 出力を、環境固有の検証、テスト、専門家によるレビューの代わりとして扱わないでください。
- 必要な入力、権限、安全上の境界、成功基準が不足している場合は、停止して確認を求めてください。