brainstorm

ブレインストーミング

並列エージェントを使って、問題に対する複数の解決策を考案し、評価します。各提案者が独立してアプローチを設計し、その後、全員で互いの成果を批評します。リードがすべてを整理し、ユーザーが選択できるよう、体系的な比較を提示します。

使用する場面

• 「〜する最善の方法は？」など、自由度の高い設計上の質問
• 有効なアプローチが複数あり、トレードオフが明確でない場合
• 実装に着手する前に、解決策の選択肢を検討したい場合
• 後から変更するのが難しいアーキテクチャや設計上の判断
• ユーザーがブレインストーミング、アプローチの比較、または選択肢の評価を明示的に依頼した場合

使用しない場面

• 問題に明らかな解決策が1つだけある場合 — そのまま実行してください
• デバッグ — 代わりに competing-hypotheses を使用してください
• 並列調査が必要な複数の要素からなる問題 — 代わりに team-solve を使用してください

---

手順

あなたは、構造化されたブレインストーミングを進行するファシリテーターです。

調整プロトコル

チームメイト間のメッセージは非同期です。今送信したメッセージが、受信者の作業が終わるまで読まれないことがあります。調整にメッセージのタイミングを当てにすることはできません。代わりに、タスクのステータスを共有状態として、各エージェントが状況を把握します。

位置を示すマーカーとしてのタスクステータス

チームメイトがメッセージを受け取ったら、それが会話のどの時点のものかを「たった今」届いたと想定するのではなく、タスクのステータスを確認して判断します。

ステータス	設定者	意味
pending	リード	未着手、割り当て待ち
in_progress	チームメイト	作業中、または作業を終えてリードの確認を待機中
completed	リードのみ	リードがチームメイトの報告を読んだ — これが確認済みであることを示します

タスクを completed にするのはリードです。チームメイトではありません。自分のタスクが completed になったのを確認したチームメイトは、リードが報告を処理済みであり、新しいメッセージが最新の指示であることを把握できます。

チームメイトのプロトコル

各チームメイトの起動プロンプトに、次のルールを含めてください。

1. 作業を開始したら、タスクを in_progress にしてください
2. TaskGet で自分のタスクを読んでください — タスクの説明には必要な情報がすべて含まれています（レビューする提案、反映するフィードバックなど）。この情報を探すためにファイルシステムや他のエージェントのファイルを検索しないでください。
3. タスクの説明に必要な内容が欠けている場合（例：提案が含まれていないレビュータスク）、すぐにリードに伝えて待機してください。独自に補ってはいけません。
4. 作業が終わったら、SendMessage で報告を送信してから待機してください。すべての作業を停止し、TaskList を確認したり、新しいタスクを引き受けたりしないでください。そのまま待機してください。
5. 受信したメッセージに対応する前に、TaskGet でタスクのステータスを確認してください。
   • まだ in_progress → リードはまだ報告を確認していません。このメッセージは報告前に送られた可能性があります。作業をやり直すのではなく、現在の状況を返信してください。
   • completed → リードは報告を処理済みです。新しいタスクが割り当てられた場合、このメッセージには最新の指示が含まれています。作業を進めてください。
6. 報告を送信する前に、起動したすべてのサブエージェントが作業を終えていることを確認してください。バックグラウンドで作業を続けてはいけません。

リードのプロトコル

1. チームメイトの報告を読んだ後、そのタスクを completed にしてください（これが確認になります）
2. 新しい指示を送る前に、前のタスクが completed になっていること、新しいタスクが作成され割り当てられていることを確認してください
3. TaskList でフェーズの完了を確認してください。関連するすべてのタスクが想定どおりのステータスになっていることを確認し、メッセージを頭の中で追跡しないでください

フェーズ 1：問題の整理

エージェントを起動する前に、問題を明確に整理します。

1. ユーザーの入力を解析し、以下を把握します。
   • 問題：何を解決または決定する必要がありますか？
   • 制約：予算、スケジュール、技術スタック、互換性、チームのスキルセットなど
   • 目標：成功とはどのような状態ですか？ パフォーマンス、保守性、シンプルさ、拡張性など
   • 背景：現状はどうなっていますか？ すでに試したことや、候補から除外したことはありますか？
2. 問題の説明が不十分な場合は、明確な制約がブレインストーミングには必要であることを踏まえ、確認の質問をします。
3. 評価基準を定めます。提案を比較する際の観点です。一般的な例：
   • 複雑さ（実装に必要な労力）
   • リスク（起こりうる問題）
   • パフォーマンス／スケーラビリティ
   • 保守性（長期的なコスト）
   • 柔軟性（将来の変更にどの程度対応できるか）
   • この問題で重要な点に合わせて調整します。
4. 提案の幅を決めます。同じ案を N 通りに変えたものではなく、幅広いアプローチを目指します。たとえば：
   • 労力が最も少なく、構成要素も最も少ない直接的／シンプルなアプローチ
   • 最も多くのエッジケースに対応し、将来にも最も適応しやすい堅牢／綿密なアプローチ
   • 異なるパラダイムや創造的な再定義を取り入れた型破りなアプローチ
   • 問題に応じて調整します。すべてのブレインストーミングで大胆な案が必要とは限りません。また、無理に独創的な案を出すより、実用的なアプローチを 2 つ検討すべき問題もあります。
5. 整理した内容をユーザーに提示します。
   • 問題の説明、制約、評価基準
   • 提案者の予定人数（2～4 人）と、それぞれが担当する観点
   • 次のように確認します。「競合するアプローチを設計するため、N 人の提案者を起動します。進めてもよろしいですか？」

フェーズ 2：並行して提案を作成

提案は並行して、独立に作成します。互いの案から影響を受けてはいけません。

1. TeamCreate でチームを作成します。
2. 提案者ごとに TaskCreate で提案タスクを作成します。
3. 提案ごとに Task を使用し、team_name を指定して general-purpose のチームメイトを 1 人起動します。
   • 担当する観点に基づいた名前を付けます（例：simple-approach、event-driven-approach、plugin-architecture）。
   • 各提案者へのプロンプトには、以下を含める必要があります。
     • フェーズ 1 で整理した問題の説明、制約、評価基準のすべて
     • 担当する観点／方向性。ただし、根拠に従うよう強調します。調査の結果、その観点が適していないと分かった場合は、無理に押し通さず、その旨を伝えるよう指示します。
     • コードベース／背景を調査してアプローチを設計すること。変更は加えないことという指示
     • 上記の調整プロトコルにあるチームメイトプロトコル（そのままプロンプトにコピーします）
     • 以下のサブエージェント向けガイダンス（そのままプロンプトにコピーします）
     • 以下の提案フォーマットを使い、SendMessage で提案を報告するよう指示します。
   • 提案者を全員、並行して起動します。
4. 提案者から報告が届いたら、報告を確認したうえで各提案タスクを completed にし、ユーザーに簡単な進捗状況を伝えます。
5. 報告が届いても、提案者を終了させてはいけません。フェーズ 3 と 4 で必要になります。

提案者向けサブエージェントガイダンス

各提案者へのプロンプトに、以下を含めます。

Task ツールでサブエージェントを使い、コンテキストを絞ってください。 以下の作業のためにサブエージェントを起動します。

• コードベースを調査し、既存のパターン、依存関係、制約を把握する
• 検討中の特定のライブラリ、API、アプローチを調査する
• 特定の方向性を採用する前に、その実現可能性を確認する
• コードベース内で類似の問題がどのように解決されているかを調べる

各サブエージェントには、以下を報告させます。

1. 関連する調査結果 — 提案に関係する発見事項
2. 行き詰まり（1～2 文） — 実現できそうに見えても、実際にはできないアプローチとその理由

サブエージェントの種類を選ぶ際は、コードベースの検索には読み取り専用または調査に特化した種類を優先します。実現可能性をテストするコマンドの実行など、より深いツールアクセスが必要な対象分析には、すべての機能を備えた種類を使います。ただし、ファイルは変更しません。

提案の形式

各提案者は、レポートを次の形式で構成してください。

## Proposal: {title}

### Summary
{2-3 sentence overview of the approach}

### Design
- {how it works, key components, data flow}
- {which files/modules would be created or changed}
- {key implementation decisions and why}

### Strengths
- {what this approach does well}
- {which evaluation criteria it scores highest on}

### Weaknesses
- {known limitations or downsides}
- {which evaluation criteria it scores lowest on}

### Risks & Open Questions
- {what could go wrong}
- {unknowns that would need to be resolved during implementation}

### Effort Estimate
{relative sizing: small / medium / large, with brief justification}

### Confidence: {high/medium/low}
{how confident are you this approach would work well?}

フェーズ 3：相互レビュー

各提案者は、投票するだけでなく、他のすべての提案を実質的に批評します。

1. TaskList ですべての提案タスクが completed になったら、すべての提案を収集します
2. 各提案者について、TaskCreate でレビュータスクを作成します。タスクの説明には次の内容を含めてください。
   • 提案者自身の提案を除く、他のすべての提案の全文
   • フェーズ 1 の評価基準
   • 以下のレビュー手順と形式
3. 各レビュータスクを提案者に割り当て、レビュータスクの準備ができたことをメッセージで伝えます。タスクの説明に必要な情報がすべて含まれていることも伝えてください
4. レビューのメッセージはすべて並行して送信してください。提案者が同時にレビューします
5. レビュアーから報告が届いたら、報告を確認したうえで各レビュータスクを completed にし、ユーザーに簡潔な進捗状況を伝えます

レビュー手順

各レビューのメッセージには、次の内容を含めてください。

以下の他の提案をそれぞれレビューしてください。各提案について、率直に評価してください。競争しているのではなく、ユーザーが適切な判断を下せるよう支援することが目的です。具体的かつ建設的な意見を述べてください。

重要：

• 自分のアプローチとは大きく異なるものでも、実際の強みを見つけてください
• 提案者が見落としている可能性のある不足点やリスクを指摘してください
• 自分の提案と大きく重複している場合や、組み合わせられる可能性がある場合は、その点を指摘してください。ただし、本当に良くなる場合を除き、統合を主張しないでください。無理に妥協するより、優れた選択肢が複数あるほうが価値があります
• 他の提案を見て自分のアプローチを修正したいと思った場合は、その点を記してください。次の段階で修正する機会があります

レビューの形式

各レビュアーは、レポートを次の形式で構成してください。

## Reviews by {your proposal title}

### Review of "{other proposal title}"
**Strengths I see:**
- {what this approach does well that's worth preserving}

**Gaps or risks missed:**
- {things the proposer didn't address}

**Questions:**
- {things that are unclear or need more detail}

**Would I adopt any of this?**
{yes/no — and what specifically, if yes}

### Review of "{another proposal title}"
...

### Self-reflection
{After seeing the other proposals, what would you change about your own? Be specific.}

フェーズ 4：修正

提案者は、相互レビューのフィードバックを踏まえて提案を強化する機会が 1 回あります。

1. TaskList ですべてのレビュータスクが completed になったら、すべてのレビューを収集します
2. 各提案者について、TaskCreate で修正タスクを作成します。タスクの説明には次の内容を含めてください。
   • 他の提案者から寄せられた、自分の提案に対するレビューの全文
   • フェーズ 3 での自分自身の振り返り
   • 以下の修正手順
3. 各修正タスクを提案者に割り当て、修正タスクの準備ができたことをメッセージで伝えます。タスクの説明に必要な情報がすべて含まれていることも伝えてください
4. 修正のメッセージはすべて並行して送信してください
5. 修正済みの提案が届いたら、報告を確認したうえで各修正タスクを completed にし、ユーザーに簡潔な進捗状況を伝えます

修正手順

各修正メッセージには、次の内容を含めてください。

他の提案者からフィードバックを受け取りました。正当な不足点に対処するために提案を修正してください。ただし、他の提案に合わせるために、自分のアプローチの核を捨ててはいけません。目的は、あらゆるアプローチを混ぜ合わせることではなく、あなた自身のアプローチをできる限り強化することです。

具体的には、次の点を行ってください。

• レビュアーが指摘した不足点やリスクに、妥当なものがあれば対処する
• レビュアーが不明確だと感じた点を明確にする
• 他の提案の優れたアイデアは、自分のアプローチを根本的に変えずに本当に改善できる場合に限り取り入れる
• レビュアーの批判が当てはまらない場合や、誤解に基づいている場合は、その理由を簡潔に説明する

以前と同じ提案の形式を使い、変更点を示してください。最後に「v1 からの変更点」というセクションを追加し、何をどのような理由で修正したかを記載してください。

フェーズ 5：構造化された比較

リードがすべての情報を統合し、ユーザー向けにわかりやすく比較します。

1. TaskList ですべての改訂タスクが completed になったら、最終提案を集めます

2. トレードオフマトリクスを作成し、フェーズ 1 の評価基準に照らして各提案を評価します。

   評価基準	提案 A	提案 B	提案 C
   複雑さ	...	...	...
   リスク	...	...	...
   ...	...	...	...

3. 各提案について、次の点を要約します。

   • 主な考え方（1～2 文）
   • 主な強み（検討する価値がある理由）
   • 主なリスク（最も大きな問題になり得ること）
   • 他の提案者の総意（このアプローチについて他の提案者が同意した点）

4. 意外な一致点を挙げます。すべての提案者が同じリスクを指摘した場合や、複数の提案に共通する同じ側面を評価した場合は、強調します

5. 提案が実質的なトレードオフの異なる段階にある場合（例：シンプルだが制限がある案と、複雑だが柔軟な案）、それぞれを独立した選択肢として提示します。ユーザーから求められない限り、妥協案にまとめようとしてはいけません

6. ある提案が明らかに優れている場合は推奨案を提示します。そうでない場合は、選択が好みや優先事項によることを説明します

7. ユーザーに提示し、どの方向に進めたいか（または、さらに検討したいか）を尋ねます

フェーズ 6：引き継ぎ

このスキルは推奨案の提示までで、実装は行いません。

1. ユーザーがアプローチを選んだら、次の内容を含む明確な概要としてまとめます。
   • 選択された提案（最終改訂版）
   • 主な決定事項とその根拠
   • 既知のリスクとその緩和策
   • 推奨する実装順序または最初の手順
2. すべてのチームメイトにシャットダウン要求を送り、終了する前に各チームメイトの確認を待ちます
3. その後、ユーザーは直接実装するか、構造化された実装のために概要を team-solve に引き継ぐことができます

ルール

• 提案時の独立性 — フェーズ3までは、提案者同士がお互いの作業を見てはいけません
• 誠実なピアレビュー — レビュアーは建設的な批評を行い、別の案を損なおうとする競争相手になってはいけません
• 多様性の維持 — 目標は、意見を収束させることではなく、異なる優れた選択肢を示すことです。正反対の方向性を持つ2つの提案のほうが、どちらにも寄らない妥協案を1つ出すより優れています
• 変革ではなく改善 — フェーズ4では提案を強化しますが、置き換えることはしません。提案者がアプローチを根本的に変えたいと思った場合、それは元の視点が誤っていたという兆候であり、他の提案に合わせて変えるべきではありません
• 提案者は2〜4人 — 2人未満ではブレインストーミングにならず、4人を超えると効果が薄れ、レビュー疲れが生じます
• タスクのステータスを正とする — メッセージのタイミングではなく、TaskUpdate のステータスを通じて連携してください。必ず TaskList で状態を確認してください
• 報告後、チームメイトは待機する — 報告を送った後は停止して待機してください。タスクのステータスを確認せずに、新しい作業を自分に割り当てたり、キューにあるメッセージに対応したりしないでください
• completed にするのはリードの役割 — タスクを completed にするのはリードだけです。これにより、確認が完了し、やり取りを締めくくります
• サブエージェントのコストは低く、コンテキストのコストは高い — 提案者はすべてを自分で進めるのではなく、調査をサブエージェントに任せてください
• 報告前にサブエージェントを完了させる — 報告を送る前に、起動したすべてのサブエージェントが完了するまで待ってください
• タスクに内容を含める — レビューおよび改訂タスクには、提案やフィードバックの全文をタスクの説明に含めてください。チームメイトは、必要な情報をすべて確認するために、割り当てられたタスクを TaskGet してください。提案やフィードバックを探すために、ファイルシステム、チーム設定、他のエージェントのスクラッチファイルを検索してはいけません
• 内容が不足している場合は待機して確認する — チームメイトがレビューまたは改訂タスクを受け取った際に、必要な提案やフィードバックがタスクの説明に含まれていない場合は、直ちにリードに「タスクに必要な内容がありません。提供されるまで待機します」と伝え、停止してください。他の場所を探して内容を補おうとしてはいけません
• 実装は行わない — このスキルが作成するのは推奨案であり、コードではありません。team-solve または直接の実装担当者に引き継いでください
• チームメイトがアイドル状態になるのは通常のことです。作業の順番が来たら、メッセージを送ってください
• チームメイトから応答がない場合は？ — 妥当な時間内に報告がない場合は、タスクのステータスを確認してください。行き詰まっている場合は、代わりの担当者を起動し、ユーザーに知らせてください