unleash-the-agentsLaunch 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 convergen…
Independent GitHub snapshot · Automated classification · Original documentation governs
オープンエンドな問題のための多様な仮説を生成するため、利用可能なすべてのエージェントを並列波で相談する。各エージェントは独自のドメインレンズを通して推論する — kabalist がゲマトリアでパターンを見出し、martial-artist が条件分岐を提案し、contemplative がデータと座って構造に気づく。独立した視点間の収束が、仮説に価値がある主要信号。
ドメイン専門性に関係なく任意のエージェントが理解できる問題ブリーフを書く。含む:
## 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 つの例または検証方法を表現できないなら、問題はマルチエージェント相談に準備できていない。まずスコープを狭める。
利用可能なすべてのエージェントを列挙し ~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 ほど少ないエージェントでも動くが、収束信号は弱い。
各波を並列エージェントとして起動する。コスト効率のため sonnet モデルを使う（価値は個々の深さではなく視点の多様性から来る）。
これは通常の対話セッションのための経路。波の各エージェントについて、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）。
TeamCreate は 非推奨であり、通常の対話セッションからはゲートで除外されている — そこでは ToolSearch("select:TeamCreate") は何も返さず、team_name は無視される（セッションは単一の暗黙チームを持つ）。それが 実際に 現れる場所（FleetView / cloud）では、チームメイト毎のタスク所有権とシャットダウンライフサイクルを伴う 名前付きチームオブジェクト を加える（Task* ツール自体は対話セッションでも動く — 動かないのはチームのスコープ化だけ）:
TeamCreate({ description: "Wave 1: open-ended hypothesis generation" })TaskCreate でエージェント毎にタスクを作成（ブリーフ + ドメイン固有フレーミング）subagent_type をエージェントタイプに設定して Agent ツールで各エージェントをチームメイトとして生成owner 付き TaskUpdate でタスクを割り当て; TaskList で監視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% 超が失敗するなら、ブリーフの明確さを確認する。一般的原因: 出力テンプレートが曖昧、または非ドメインエージェントが推論するに例が不十分。
波 1-2 の後、次の波を起動する前に現れる信号を抽出する。
**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 波後に収束が現れないなら、問題が制約不足かもしれない。スコープを狭めるかより多くの例を提供することを検討する。
すべての波が完了したら、すべての応答を単一ドキュメントに集める。仮説をファミリーにグループ化して重複排除:
期待結果： 収束カウント、貢献エージェント、代表的テスト可能予測を伴う仮説ファミリーのランク付きリスト。
失敗時： すべての仮説が一意（収束なし）なら、信号対ノイズ比が低すぎる。問題がより多くの例を必要とするか、エージェントがより厳しい出力フォーマットを必要とする。
収束が共有訓練データの成果物ではなく意味があることを保証するため、null モデルに対してトップ仮説をテストする。
期待結果： トップ仮説ファミリーが偶然レベル収束を有意に超えるか、プログラム的検証をパスする。
失敗時： トップ仮説が検証に失敗したら、第二ランクファミリーを確認する。どのファミリーもパスしなければ、問題は異なるアプローチ（より深い単一専門家解析、より多くのデータ、再定式化された例）を要するかもしれない。
好まれるタイミング: 合成後ではなく 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 エージェントを選ぶ）にフィードバックする。
Unleash は問題を見つけ、チームがそれらを解決する。検証された仮説ファミリーを実行可能な issue に変換し、それから各々を解決する焦点的チームを組み立てる。
create-github-issues スキルを使う）subagent_type）を介してサブエージェントとして生成し、SendMessage で調整する:
teams/ の事前定義チーム定義があれば、それを使うopaque-team（適応的役割割り当てを伴う N shapeshifters）を既定とする — それはカスタム構成を要求せずに未知の問題形を扱うadvocatus-diaboli、contemplative）を含む — 技術エージェントが見逃す実装リスクを彼らが捕える期待結果： 各仮説ファミリーがチームが割り当てられた追跡 issue にマップする。Unleash が診断を生み、チームが修正を生む。
失敗時： チーム構成が問題に合わなければ、再割り当てする。Shapeshifter エージェントは研究と設計はできるが書き込みツールを持たない — チームリードが彼らのコード提案を適用しなければならない。
docs/investigations/lead-support-coordination-2026-09-15.md に記録された。forage-solutions — 解空間探索のためのアントコロニー最適化（補完: より狭いスコープ、より深い探索）build-coherence — 競合アプローチ間で選ぶための bee 民主主義（このスキル後にトップ仮説間で選ぶために使う）coordinate-reasoning — エージェント間情報フロー管理のためのスティグマージック調整coordinate-swarm — 分散システムのためのより広いスワーム調整パターンexpand-awareness — 狭める前のオープン知覚（補完: 個別エージェント準備として使う）meditate — 起動前に文脈ノイズをクリア（ステップ1 の前に推奨）