council

Council

このスキルを使用すると、同じ質問を調査する複数のサブエージェントを、まず異なるモデルで、次に異なる視点を割り当てて連携させ、それぞれの報告をまとめて一つの推奨案を作成できます。

このスキルは、アーキテクチャ上のトレードオフ、リスクの高いバグ修正、コードレビューのレッドチーム分析、ロールアウトの判断、インシデント分析、「この代替案を追求する価値はあるか」といった、判断が重要なタスクに最適です。

ワークフロー

1. 評議会の質問を定める

評議会が回答すべき判断を一文で述べます。以下を明確にします。

• 検討対象となる選択肢または仮説。
• 調査するコードベース、ブランチ、PR、Issue、設計、成果物。
• エージェントを読み取り専用にするか、コードの変更を許可するか。
• 正確性、リスク、実装コスト、テスト可能性、ロールアウトの安全性、プロダクトの動作など、最終的な判断基準。

ユーザーの依頼が曖昧な場合は、必要最低限の確認だけを行います。それ以外の場合は、妥当な既定値を選んで進めます。

2. 評議会のメンバーを選ぶ

モデルの多様性を優先します。利用可能な起動設定で複数の有用なモデルを選べない場合、またはユーザーが特定のモデルを明示的に求めている場合を除き、異なる視点を与えた同一モデルのエージェント3人を既定の構成にしないでください。モデルの多様性を確保できない場合は、視点のみを多様化する構成に切り替える前に、その旨を簡潔に伝えます。

3人構成の評議会で推奨する既定のメンバーは以下のとおりです。

• Opus 4.7、または利用可能な最も強力な Claude／Opus 推論モデル：アーキテクチャ、正確性、エッジケースの分析。
• GPT 5.5、または利用可能な最も強力な GPT／Codex モデル：実装を踏まえたレビュー、実現可能性、テスト戦略。
• Kimi 2.6、GLM 5.1、または利用可能な最も強力なオープンソース／ローカルモデルなどのオープンソースモデル：反対意見からの批評、隠れた前提、別の捉え方。

アクティブなハーネスでこれらのモデルを利用できない場合は、同じ系統から最も近いモデルを選び、代替したことを記載します。オープンソースモデルが利用できない場合は、可能であれば3つ目の異なるフロンティアモデルを使用します。それもできない場合は、残りのモデルのうち最も強力なものを使い、意図的に敵対的または専門的な視点を割り当てます。

各メンバーにモデルと視点の両方を割り当てます。モデルごとに視点を変えるのではなく、視点が重複しないようにしてください。たとえば、すべてのメンバーに一般的なアーキテクチャレビューを依頼してはいけません。視点の組み合わせとして、以下が有用です。

• アーキテクチャ／正確性のレビュアー。
• 実装／テスト可能性のレビュアー。
• レッドチーム、セキュリティ、パフォーマンス、またはプロダクトリスクのレビュアー。
• 自明に見える解決策に反論する、逆張りのレビュアー。

異なる子エージェントに異なるモデルが必要な場合は、モデルの選択が呼び出し全体に適用されるため、別々の run_agents 呼び出しで起動します。要求したモデルが想定とは異なる設定で解決された場合は、解決後の起動設定を正とし、タスクの実行が不可能にならない限り、その設定で続行します。

読み取り専用の調査では、すべての子エージェントを同じチェックアウトで作業させ、ファイルを編集しないよう明示します。実装やプロトタイピングを行う評議会では、ローカルの子エージェントごとに専用の git worktree とブランチを用意し、作業が衝突しないようにします。

3. 起動前の概要説明

明示的なオーケストレーションの依頼では、起動する予定の評議会メンバーと各メンバーの調査内容をユーザーに簡潔に伝えてから、承認を待って run_agents を呼び出してください。

共有する概要には、次の内容を含めてください。

• リポジトリのパスまたは成果物の場所。
• 現在のブランチまたはベースとなるコンテキスト。
• 回答するべき正確な質問。
• 関連する背景情報と既知の懸念事項。
• 分かっている場合は、確認が必要なファイルやシンボル。
• 制約事項、特に読み取り専用、コミット禁止、PR 作成禁止。
• 想定するレポート形式。

タスクのタイトルが長くなりすぎないよう、起動時のプロンプトは短くしてください。概要が長く、起動時の検証で問題が起きる場合は、最小限のプロンプトで起動し、その直後に子エージェントへ概要全文を送ってください。

4. 構造化されたレポートを依頼する

各評議会メンバーに、次の内容を返すよう依頼してください。

1. 確認した正確なファイルパス、シンボル、ドキュメント、または証拠。
2. 現在の動作または現在の実装。
3. 評価対象となる代替案。
4. 正しさに関するリスクとエッジケース。
5. 実装およびテストにかかるコスト。
6. 推奨事項：現行の方法を維持する、代替案を採用する、またはハイブリッド方式を使う。
7. 確信度と不明点。

各メンバーには独立して調査するよう促してください。意図的に第 2 ラウンドの批評を行う場合を除き、ある子エージェントの調査結果をほかのメンバーに共有しないでください。

5. レポートを収集する

完了メッセージが届いたら順次確認してください。ライフサイクル上の成功だけを根拠にせず、役立つ情報は子エージェントのレポートから取得してください。

レポートに重要な証拠が不足している場合や、裏付けのない主張が含まれている場合は、代わりのエージェントを起動するのではなく、同じ子エージェントに絞った追加質問を送ってください。既存の子エージェントはコンテキストを保持しているため、追加質問にも再利用してください。

6. 推奨事項をまとめる

投票数ではなく、証拠の質に基づいてレポートを比較してください。最終回答では、次の点を説明してください。

• 推奨事項を最初に示す。
• 合意点と意見の相違点を明らかにする。
• 判断基準に照らして、推奨案が優れている理由を説明する。
• ユーザーが示した懸念に明確に回答する。
• 回答が冗長にならない範囲で、関連するファイルパスやシンボルを示す。
• 「今すぐ実施すること」と、任意の将来的な強化策を区別する。
• 確信度と重大な不明点に言及する。

やり取りの要約ではなく、簡潔な意思決定メモを優先してください。ユーザーが必要としているのは、中間過程の詳細ではなく、要点をまとめた推奨事項です。

最終回答のテンプレート

タスクに応じて別の形式が必要な場合を除き、次の形式を使用してください。

## Recommendation

[One or two sentences with the decision.]

## Why

- [Key reason 1]
- [Key reason 2]
- [Key reason 3]

## Tradeoffs and risks

- [Risk or caveat]
- [Testing/rollout implication]

## Final call

[Concrete next step: merge current change, pursue alternative, hybrid, run tests, etc.]

実務上の注意

• 評議会が読み取り専用の場合は、ファイルの変更、コミット、ブランチの作成、PR の作成をしないよう子エージェントに伝えてください。
• 評議会で PR またはブランチの作業を行う場合は、リポジトリの通常のバージョン管理ルールに従い、ローカルでの並行編集には分離されたワークツリーを使用してください。
• 評議会がコードレビューの指摘に関するものである場合、根本の問題に実際に対処するまではレビューコメントを解決済みにしないでください。
• ユーザーから明示的に求められない限り、ユーザー向けの要約に内部の子エージェント ID を含めないでください。