---

name: unleash-the-agents description: > Launch all available agents in parallel waves for open-ended hypothesis generation on problems where the correct domain is unknown. Use when facing a cross-domain problem with no clear starting point, when single-agent approaches have stalled, or when diverse perspectives are more valuable than deep expertise. Produces a ranked hypothesis set with convergence analysis and adversarial refinement. license: MIT allowed-tools: Read Write Edit Bash Grep Glob Agent ToolSearch TeamCreate TaskCreate TaskUpdate TaskList SendMessage metadata: author: Philipp Thoss version: "1.2" domain: swarm complexity: advanced language: multi tags: swarm, parallel, hypothesis-generation, multi-agent, brainstorming, convergence locale: ja source_locale: en source_commit: be74aff5 fence_basis_commit: be74aff5 translator: "Claude + human review" translation_date: "2026-05-03"

Unleash the Agents

オープンエンドな問題のための多様な仮説を生成するため、利用可能なすべてのエージェントを並列波で相談する。各エージェントは独自のドメインレンズを通して推論する — kabalist がゲマトリアでパターンを見出し、martial-artist が条件分岐を提案し、contemplative がデータと座って構造に気づく。独立した視点間の収束が、仮説に価値がある主要信号。

使用タイミング

• 正しいアプローチが未知のクロスドメイン問題に直面するとき
• 単一エージェントまたは単一ドメインアプローチが停滞または信号を生まなかった
• 問題が真に多様な視点（より多くの計算ではなく）から利益を得る
• 仮説生成（実行ではなく）が必要 — 実行にはチームを使う
• 自明でない角度を逃すことが実コストを伴う高ステークス決定

入力

• 必須: 問題ブリーフ — 問題、5+ 具体例、解決として何が数えられるかの明確な記述
• 必須: 検証方法 — 仮説が正しいかをテストする方法（プログラム的テスト、専門家レビュー、null モデル比較）
• 任意: エージェントサブセット — 含めるまたは除外する特定エージェント（既定: すべての登録エージェント）
• 任意: 波サイズ — 波あたりエージェント数（既定: 10）
• 任意: 出力フォーマット — エージェント応答用の構造化テンプレート（既定: 仮説 + 推論 + 信頼度 + テスト可能予測）

手順

ステップ1: ブリーフを準備する

ドメイン専門性に関係なく任意のエージェントが理解できる問題ブリーフを書く。含む:

1. 問題声明: 何を発見または決めようとしているか（1-2 文）
2. 例: 少なくとも 5 つの具体的入力/出力例またはデータポイント（多いほど良い — 3 はほとんどのエージェントがパターンを見出すには少なすぎる）
3. 既知の制約: 既に知っていること、既に試したこと
4. 成功基準: 正しい仮説をどう認識するか
5. 出力テンプレート: 応答が欲しい正確なフォーマット
6. すべての主張の出典: 各事実が issue、自分の計画、自分自身の読み、前セッションのノートのいずれに由来するかを述べ、これから作り出すつもりの最終状態は意図したものとして明示する

## Brief: [Problem Title]

**Problem**: [1-2 sentence statement]

**Examples**:
1. [Input] → [Output]  (explain what's known)
2. [Input] → [Output]
3. [Input] → [Output]
4. [Input] → [Output]
5. [Input] → [Output]

**Already tried**: [List failed approaches to avoid rediscovery]

**Success looks like**: [Testable criterion]

**Respond with**:
- Hypothesis: [Your proposed mechanism in one sentence]
- Reasoning: [Why your domain expertise suggests this]
- Confidence: [low/medium/high]
- Testable prediction: [If my hypothesis is correct, then X should be true]

期待結果： 自己完結したブリーフ — このテキストだけを受け取るエージェントが問題について推論するに必要なすべてを持つ。

失敗時： 5 つの例または検証方法を表現できないなら、問題はマルチエージェント相談に準備できていない。まずスコープを狭める。

ステップ2: 波を計画する

利用可能なすべてのエージェントを列挙し ~10 の波に分ける。最初の 2 波には順序は重要でない; 後続の波には、波間知識注入が結果を改善する。

# List all agents from registry
grep '  - id: ' agents/_registry.yml | sed 's/.*- id: //' | shuf

エージェントを波に割り当てる。最初に 4 波を計画する — すべてが必要にならないかもしれない（ステップ4 の早期停止を参照）。

Wave	Agents	Brief variant
1-2	20 agents	Standard brief
3	10 agents + advocatus-diaboli	Brief + emerging consensus + adversarial challenge
4+	10 agents each	Brief + "X is confirmed. Focus on edge cases and failures."

期待結果： すべてのエージェントが割り当てられた波割当表。後続の波に情報を与えるよう Wave 3（後ではなく）に advocatus-diaboli を含める。

失敗時： 20 未満のエージェントが利用可能なら、2-3 波に減らす。パターンは 10 ほど少ないエージェントでも動くが、収束信号は弱い。

ステップ3: 波を起動する

各波を並列エージェントとして起動する。コスト効率のため sonnet モデルを使う（価値は個々の深さではなく視点の多様性から来る）。

Option A: Agent ツール生成（推奨）

これは通常の対話セッションのための経路。波の各エージェントについて、Agent ツール（subagent_type をエージェントタイプ、例: kabalist、geometrist に設定）を介して、ブリーフとドメイン固有フレーミング付きでサブエージェントとして生成する:

Use the [agent-name] agent to analyze this problem through your domain expertise.
[Paste the brief]
Think about this from your specific perspective as a [agent-description].
[For non-technical agents: add a domain-specific framing, e.g., "What patterns
does your tradition recognize in systems that exhibit this kind of threshold behavior?"]
Respond exactly in the requested format.

Agent ツールと run_in_background: true で波内のすべてのエージェントを同時に起動し、セッションの単一の暗黙チームの下で SendMessage により調整する。波間知識注入を可能にするため次の波を起動する前に波が完了するのを待つ（ステップ4）。

Option B: TeamCreate（FleetView / cloud のみ）

TeamCreate は 非推奨であり、通常の対話セッションからはゲートで除外されている — そこでは ToolSearch("select:TeamCreate") は何も返さず、team_name は無視される（セッションは単一の暗黙チームを持つ）。それが 実際に 現れる場所（FleetView / cloud）では、チームメイト毎のタスク所有権とシャットダウンライフサイクルを伴う 名前付きチームオブジェクト を加える（Task* ツール自体は対話セッションでも動く — 動かないのはチームのスコープ化だけ）:

1. チームを作成: TeamCreate({ description: "Wave 1: open-ended hypothesis generation" })
2. TaskCreate でエージェント毎にタスクを作成（ブリーフ + ドメイン固有フレーミング）
3. subagent_type をエージェントタイプに設定して Agent ツールで各エージェントをチームメイトとして生成
4. owner 付き TaskUpdate でタスクを割り当て; TaskList で監視
5. 波の間で、SendMessage({ type: "shutdown_request" }) を介してチームをシャットダウンし、更新されたブリーフ（ステップ4）で次を開始

組込チーム調整 — チームメイト毎の所有権とライフサイクル、波を越えて引き継がれるステータス — を与えるが、チームのスコープ化は TeamCreate が現れる場所にしか存在しない。対話セッションでは Option A を使う。

オプションの選択

	Agent tool (Option A)	TeamCreate (Option B)
Availability	Every session (primary)	FleetView / cloud only (gated)
Best for	All interactive unleashes	Cloud runs wanting a shared task list
Coordination	SendMessage, manual collection	Task list, messaging, ownership
Inter-wave handoff	Track via the brief update	Task status carries over

期待結果： 各波が 2-5 分以内に ~10 構造化応答を返す。応答に失敗するまたはオフフォーマット出力を返すエージェントは記されるがパイプラインをブロックしない。

失敗時： 波の 50% 超が失敗するなら、ブリーフの明確さを確認する。一般的原因: 出力テンプレートが曖昧、または非ドメインエージェントが推論するに例が不十分。

ステップ4: 波間知識を注入する（早期停止を評価）

波 1-2 の後、次の波を起動する前に現れる信号を抽出する。

1. 完了した波からの応答を繰り返しテーマでスキャン
2. 最も一般的な仮説ファミリー（収束信号）を特定
3. 早期停止閾値を確認: 20 エージェント後にトップファミリーが既に null モデル期待の 3x を超えるなら、強い信号がある。Wave 3 を adversarial + 精緻化波として計画し、その後の停止を検討
4. 次の波のためにブリーフを更新:

**Update from prior waves**: [N] agents independently proposed [hypothesis family].
Build on this — what explains the remaining cases where this hypothesis fails?
Do NOT simply restate this finding. Extend, challenge, or refine it.

早期停止ガイダンス: すべての unleash がすべてのエージェントを必要とするわけではない。よく定義された問題ドメイン（例: コードベース解析）には、収束はしばしば 30-40 エージェントで安定する。抽象的またはオープンエンドな問題（例: 未知の数学変換）には、正しいドメインが真に予測不能なため、フルロスターが価値を加える。各波後に収束を確認 — トップファミリーのカウントと null モデル比が plateau しているなら、追加波は減少する戻りを yield する。

これが再発見（後の波が独立に早い波が既に見つけたものを再導出する）を防ぎ、後のエージェントを問題の縁へ向ける。

期待結果： 後の波が現れる合意のギャップに対処するより微妙でターゲット化された仮説を生む。

失敗時： 2 波後に収束が現れないなら、問題が制約不足かもしれない。スコープを狭めるかより多くの例を提供することを検討する。

ステップ5: 集めて重複排除する

すべての波が完了したら、すべての応答を単一ドキュメントに集める。仮説をファミリーにグループ化して重複排除:

1. すべての仮説声明を抽出
2. メカニズムでクラスタ（語法ではなく — 「modular arithmetic mod 94」と「cyclic group over Z_94」は同じファミリー）
3. ファミリーあたりの独立発見をカウント
4. 収束でランク: より多くのエージェントによって独立に発見されたファミリーが上位にランク

期待結果： 収束カウント、貢献エージェント、代表的テスト可能予測を伴う仮説ファミリーのランク付きリスト。

失敗時： すべての仮説が一意（収束なし）なら、信号対ノイズ比が低すぎる。問題がより多くの例を必要とするか、エージェントがより厳しい出力フォーマットを必要とする。

ステップ6: Null モデルに対して検証する

収束が共有訓練データの成果物ではなく意味があることを保証するため、null モデルに対してトップ仮説をテストする。

• プログラム的検証: 仮説がテスト可能な公式またはアルゴリズムを生むなら、保留例に対して実行
• Null モデル: N エージェントが偶然で同じ仮説ファミリーに収束する確率を見積もる（例: K 妥当な仮説ファミリーがあれば、ランダム収束確率は ~N/K）
• 閾値: 収束が null モデル期待の 3x を超えるなら信号が意味がある

期待結果： トップ仮説ファミリーが偶然レベル収束を有意に超えるか、プログラム的検証をパスする。

失敗時： トップ仮説が検証に失敗したら、第二ランクファミリーを確認する。どのファミリーもパスしなければ、問題は異なるアプローチ（より深い単一専門家解析、より多くのデータ、再定式化された例）を要するかもしれない。

ステップ7: Adversarial 精緻化

好まれるタイミング: 合成後ではなく Wave 3。 Wave 3 に（波間知識注入と並んで）advocatus-diaboli を含めることが、すべての波が完了した後の独立した adversarial パスより効果的。早期挑戦が Waves 4+ を、挑戦されていない合意に積み重ねるのではなく批判に対して精緻化させる。

adversarial パスが既に Wave 3 の一部だったなら、このステップは最終確認になる。そうでなければ（例: それなしに全波を実行した）、今 advocatus-diaboli（または senior-researcher）を生成する。構造化されたパスには、Agent ツールを介して両エージェントを並列サブエージェントとして生成し、合意に対して SendMessage で調整する:

Here is the consensus hypothesis from [N] independent agents:
[Hypothesis]
[Supporting evidence and convergence stats]

Your job: find the strongest counterarguments. Where does this fail?
What alternative explanations are equally consistent with the evidence?
What experiment would definitively falsify this hypothesis?

期待結果： 反論、エッジケース、反証実験のセット。仮説が adversarial 精査を生き残るなら、統合の準備ができている。良い adversarial パスは時に合意を 部分的に擁護する — 不完全でも設計が代替よりも良いと見出す。

失敗時： adversarial エージェントが致命的欠陥を見出したら、批判をターゲット化されたフォローアップ波（Tier 3+ 反復モード — 特定批判に対処するに最も位置付けられた 5-10 エージェントを選ぶ）にフィードバックする。

ステップ8: チームに引き渡す

Unleash は問題を見つけ、チームがそれらを解決する。検証された仮説ファミリーを実行可能な issue に変換し、それから各々を解決する焦点的チームを組み立てる。

1. 検証された仮説ファミリー毎に GitHub issue を作成（create-github-issues スキルを使う）
2. 収束強度とインパクトで issue を優先順位付け
3. 各 issue について、小チームを組み立てる — 合致する定義を読み、そのメンバーを Agent ツール（subagent_type）を介してサブエージェントとして生成し、SendMessage で調整する:
   • 問題ドメインに合う teams/ の事前定義チーム定義があれば、それを使う
   • 適合チームが存在しなければ、opaque-team（適応的役割割り当てを伴う N shapeshifters）を既定とする — それはカスタム構成を要求せずに未知の問題形を扱う
   • 少なくとも 1 つの非技術エージェント（例: advocatus-diaboli、contemplative）を含む — 技術エージェントが見逃す実装リスクを彼らが捕える
   • 急ぎを防ぐためフェーズ間で REST チェックポイントを使う
4. パイプラインは: unleash → triage → team-per-issue → resolve

期待結果： 各仮説ファミリーがチームが割り当てられた追跡 issue にマップする。Unleash が診断を生み、チームが修正を生む。

失敗時： チーム構成が問題に合わなければ、再割り当てする。Shapeshifter エージェントは研究と設計はできるが書き込みツールを持たない — チームリードが彼らのコード提案を適用しなければならない。

バリデーション

• すべての利用可能エージェントが相談された（または意図的なサブセットが正当化と共に選ばれた）
• 応答が構造化、解析可能なフォーマットで集められた
• 仮説が独立収束で重複排除されランクされた
• トップ仮説が null モデルまたはプログラム的テストに対して検証された
• adversarial パスが合意に挑戦した
• 最終仮説がテスト可能予測と既知の制限を含む

よくある落とし穴

• ブリーフの例が少なすぎる: エージェントはパターンを見つけるに 5+ 例が必要。3 例では、ほとんどのエージェントが表面レベルパターンマッチングまたはテンプレートエコー（異なる言葉でブリーフを繰り返す）に頼る。
• 情報源を一つの声に混ぜる: issue、自分の計画、自分自身の読み、前セッションのノートを混ぜ合わせたブリーフは、それらの間の継ぎ目を失う。すると意図した最終状態が「issue によれば…」としてエージェントに届き、彼らは存在しない事実を探すことに労力を費やす。すべての主張に出典を明記する（ステップ1、要素6）。これは unleash 波ではなくピアセッションについて docs/investigations/lead-support-coordination-2026-09-15.md に記録された。
• 検証経路なし: 仮説をテストする方法なしには、信号をノイズと区別できない。収束だけでは必要だが十分でない。
• メタファー応答: ドメイン専門エージェント（mystic、shaman、kabalist）は解析が難しい豊かなメタファー的推論で応答するかもしれない。出力テンプレートに「あなたの仮説をテスト可能な公式またはアルゴリズムとして表現」を含める。
• 波を越える再発見: 波間知識注入なしでは、波 3-7 が独立に波 1-2 が既に見つけたものを再発見する。常に波の間でブリーフを更新する。
• 収束を過剰解釈: メカニズムファミリーへの 43% 収束は印象的に聞こえるが、ベースレートを確認する。妥当なメカニズムファミリーが 3 つしかないなら、ランダム収束は ~33%。
• 単一ファミリー支配を期待: 抽象問題（パターン認識、暗号）は一つの支配的仮説ファミリーを生む傾向がある。多次元問題（コードベース解析、システム設計）は複数の有効ファミリーにわたって広い収束を生む — これはパターンの失敗ではなく予想され健全。
• 非技術エージェントへの汎用フレーミング: 非技術エージェントの貢献の質は、ブリーフが彼らのドメイン言語で問題をどうフレームするかに依存する。「あなたの伝統はこの閾値のシステムについて何を言うか？」は構造的洞察を生む; 汎用ブリーフは何も生まない。問題の自然なドメイン外のエージェントにはドメイン固有フレーミングに投資する。
• これを実行に使う: このパターンは仮説を生成し、実装ではない。検証された仮説を持ったら、それらを issue に変換しチームに引き渡す（ステップ8）。パイプラインは unleash → triage → team-per-issue。

関連スキル

• forage-solutions — 解空間探索のためのアントコロニー最適化（補完: より狭いスコープ、より深い探索）
• build-coherence — 競合アプローチ間で選ぶための bee 民主主義（このスキル後にトップ仮説間で選ぶために使う）
• coordinate-reasoning — エージェント間情報フロー管理のためのスティグマージック調整
• coordinate-swarm — 分散システムのためのより広いスワーム調整パターン
• expand-awareness — 狭める前のオープン知覚（補完: 個別エージェント準備として使う）
• meditate — 起動前に文脈ノイズをクリア（ステップ1 の前に推奨）