team-solve

Team Solve

並行して調査した後、順番に実装し、1つ以上の問題を調査して解決します。

使用する場面

• 対応すべき問題やテーマが複数あるタスク
• 複数の領域を同時に調査すると効果的なコードベースの変更
• 独立した調査トラックに分割できる作業
• 変更を加える前に、根拠を構造的に集めたい場合

---

手順

あなたは、調査してから解決するワークフローを統括するチームリードです。

連携プロトコル

チームメイト間のメッセージは非同期です。今送ったメッセージが、相手の現在の作業が終わるまで読まれない場合があります。メッセージが届くタイミングを連携に当てにしてはいけません。代わりに、各エージェントの状況を共有するのはタスクのステータスです。

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

チームメイトがメッセージを受け取ったら、「たった今」届いたと推測するのではなく、タスクのステータスを確認して会話のどこに位置するか判断します。

ステータス	設定者	意味
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でフェーズの完了を確認します。関連するすべてのタスクが想定どおりのステータスになっていることを確認し、メッセージのやり取りを記憶だけで管理してはいけません。
4. 実装トラックを切り替える際は、次に進む前にgit statusを実行し、作業ツリーがクリーンであることを確認します。

フェーズ1：問題の分解

1. ユーザーの入力を分析して、個別の問題やテーマを特定します。
2. 問題が曖昧、または詳細が不足している場合は、先に確認の質問をします。
3. 関連する問題を2～5つの調査トラックにまとめます（各トラックを1人のチームメイトに割り当てます）。
4. 分解内容をユーザーに提示します。
   • 各トラックと、割り当てる問題を列挙します。
   • filter-investigatorやoutput-researcherなど、各チームメイトの役割を示す名前を付けます。
   • 「調査担当者N人を並行して起動します。進めてもよろしいですか？」と尋ねます。

フェーズ 2：並行調査

調査は並行して進めます。

1. TeamCreate でチームを作成します
2. TaskCreate で各調査トラックのタスクを作成します
3. 各トラックにつき 1 人の general-purpose チームメイトを、team_name を指定して Task で起動します
   • 各チームメイトへのプロンプトには、以下を含めてください。
     • 調査する具体的な問題
     • 調査のみを行い、変更は加えないという指示
     • 上記の Coordination Protocol にあるチームメイトプロトコル（そのままプロンプトにコピーしてください）
     • 以下のサブエージェント向けガイダンス（そのままプロンプトにコピーしてください）
     • 以下のレポート形式を使い、SendMessage で調査結果を報告する指示
   • すべての調査担当者を並行して起動してください。1 人の完了を待ってから次の担当者を起動してはいけません
4. 報告が届いても、調査担当者をシャットダウンしないでください。フェーズ 4 でも担当者はコンテキストを保持します

調査担当者向けサブエージェントガイダンス

各調査担当者のプロンプトに以下を含めてください。

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

• 特定のファイル、モジュール、サブシステムの調査
• Git 履歴、ログ、大規模なコードベースの検索
• 成果につながらない可能性のある調査上の寄り道

各サブエージェントは、以下を報告してください。

1. 関連する調査結果 — 調査に関係する重要な発見
2. 誤解を招く情報（1～2 文）— 関連がありそうに見えるものの、実際には関係がないものとその理由。早めに明らかにすることで、行き詰まりを再調査する時間を防げます。

主な調査結果が確定している場合でも、誤解を招く情報を報告してください。他のエージェントが同じ行き詰まりを再調査するのを防げます。

サブエージェントから報告を受けたら、以下のいずれかを判断してください。

• 調査結果をそのまま使う — 要約だけで十分に進められる場合
• 自分で詳しく調べる — サブエージェントが有望な情報を見つけ、結論を出す前に自分でもその領域を直接確認したい場合。たとえば、相反する証拠を直接調べる必要がある場合、サブエージェントの評価への確信が低い場合、または複雑な状態や処理フローについて直接把握する必要がある場合です。

サブエージェントの種類を選ぶ際、オープンエンドなコードベースの検索では読み取り専用または調査に特化したタイプを優先し、より深いツールアクセスが必要な対象を絞った分析では、すべての機能を使えるタイプを選んでください。

調査担当者のレポート形式

各調査担当者は、以下の形式で報告してください。

## Track: {description}

### Findings
- {what was discovered, root causes, relevant code paths}

### Proposed Approach
- {what to change, which files, how}

### Risks & Edge Cases
- {what could go wrong with this approach}
- {what adjacent code/features could be affected}
- {what happens if data is unexpected or flow is interrupted}

### Red Herrings
- {things explored that weren't relevant, and why}

### Confidence: {high/medium/low}
{brief justification}

### Dependencies
- {does this approach depend on or conflict with other tracks?}

フェーズ 3：ディスカッションのチェックポイント

1. 調査担当者から報告が届いたら、報告を確認したうえで各調査タスクを completed にし、ユーザーに簡潔な進捗状況を伝えます
2. TaskList ですべての調査タスクが completed になったら、調査結果をまとめます。
   • トラックごとの主な調査結果
   • 提案するアプローチと確信度
   • トラック間の競合や依存関係
   • 波及効果 — すべてのトラックを横断して評価します。
     • 「～に何が起こるか」— ドキュメント、隣接機能、API 利用者、共有状態、キャッシュ
     • 「～の場合に何が起こるか」— 想定外のデータ、中断された処理フロー、同時アクセス、ロールバック
   • 推奨する実装順序（依存関係の解決を先に行い、次にリスクの高いもの、最後に残りの順に進めます）
3. 調査によって想定とは異なる問題だと判明した場合は、その旨を伝えてください。元の計画に固執せず、トラックの見直しを提案します
4. ユーザーに「実装に進みますか。それともアプローチを見直しますか？」と尋ねます

フェーズ 4：順次実装

実装は一度に 1 つのトラックずつ行います。これにより、次のことを防げます。

• 1 つのコミットに、関連のない作業が混在する
• 変更が同時進行していることによる、分かりにくいビルド／テストの失敗
• チームメイトが共有コードを編集した際のファイル競合

1. 各トラックについて（ユーザーと合意した順に）、リードプロトコルに従います。 a. このトラックの実装タスクを作成します。**タスクの説明には、次の内容を含めてください。**実施する作業、以下のサブエージェント向けガイダンス、および（後続のトラックの場合）前のトラックの「変更内容」サマリー b. 元の調査担当者にタスクを割り当て、実装タスクの準備ができたことをメッセージで伝えます。必要な情報はすべてタスクの説明に記載されています c. 待機します。調査担当者が作業し、報告を送信して、待機状態になります d. 報告を読みます。実装タスクをcompleted（完了）にします（あなたの確認を示します）。 e. git statusを実行して、作業ツリーがクリーンであることを確認します。未コミットの変更や残っているファイルがない状態にします f. 簡単な健全性チェックとして、関連するテスト／チェックを実行します g. その後でのみ、次のトラックに進みます
2. 並列化の例外：トラック間でファイルの重複が一切なく、かつコードベースに、失敗が入り交じって分かりにくくなる可能性のある共有ビルド／テストパイプラインがない場合に限り、並列実装を検討します。並列化が安全だと思われる場合は、その理由を説明してユーザーに確認してください。
3. 部分的な失敗：
   • 調査担当者の報告で確信度が低いと示された場合、または実行可能な内容が見つからなかった場合は、実装に着手する前にユーザーと相談します。トラックを取り下げる、別のトラックに統合する、さらに調査する、などの選択肢があります
   • トラックの途中で実装に失敗した場合は、次のトラックに進む前に停止し、ロールバックするかアプローチを調整するかをユーザーと相談します

実装に関するサブエージェント向けガイダンス

実装指示を送る際は、以下を含めてください。

実装ロジックに集中できるよう、サブエージェントを活用してください。 次の作業にはサブエージェントを起動します。

• 反復的な編集 — 多数のファイルにわたる類似の変更（インポートの更新、テストファイル全体での名前変更、複数のモジュールへのパターン適用）
• 影響分析 — 関数のシグネチャを変更する前に、その関数を呼び出している箇所をすべて特定する、API のすべての利用者を確認する
• 探索的な読み込み — 変更によってモジュールの前提が崩れないかを確認する、隣接するコードのエッジケースを検証する
• バックグラウンドでのテスト実行 — 次の変更に取り組んでいる間にテストを実行する

重要： トラックの完了を報告する前に、すべてのサブエージェントの作業が完了するのを待ってください。完了を報告する時点で、バックグラウンド作業が実行中のままにならないようにしてください。

フェーズ 5：検証

1. バリデーターを起動する前に、TaskListで実装タスクがすべてcompletedになっていることを確認し、git statusを実行して作業ツリーがクリーンであることを確認します
2. 新しいgeneral-purposeチームメイトをvalidatorという名前で起動します。起動プロンプトには、Coordination Protocol のTeammate Protocol（原文のまま）、フェーズ 1 の元の問題、フェーズ 3 で合意した実装方針、調査担当者が指摘したリスク領域、変更したファイルの一覧（またはgit diffの範囲）を含める必要があります。差分はプロンプトに直接含めることを優先してください。大きすぎる場合は、mktemp（例：mktemp /tmp/team-solve-diff.XXXXXX）で一時ファイルに書き込み、そのパスからバリデーターに読み込ませてください。バリデーターには次のことを指示します。
   • プロジェクトのテスト／lint／型チェック用ツールを特定し、適切なチェックを実行する
   • 変更したすべてのファイルを確認し、正確性と一貫性を検証する
   • フェーズ 1 の各問題が実際に解決されているか確認する
   • 意図しない副作用やリグレッションがないか調べる
   • SendMessageを通じて、詳細を添えて合否を報告する
3. 検証に失敗した場合：
   • 失敗した項目を担当する調査担当者に戻し、修正を依頼します
   • 修正後に検証を再実行します
4. 検証に合格したら、すべてのチームメイトにシャットダウン要求を送り、最終結果をユーザーに報告する前に、各チームメイトからの確認を待ちます

ルール

• 並行して調査し、順番に実装する — 調査には並列処理が有効ですが、実装は順序立てて進めるのが効果的です
• タスクのステータスを正とする — メッセージの送信タイミングではなく、TaskUpdate のステータスを通じて連携してください。状態を確認するため、必ず TaskList を確認してください。
• 報告後、チームメイトは待機する — 報告を送った後は、作業を止めて待機してください。タスクのステータスを先に確認せず、新しい作業を自分で割り当てたり、キューにあるメッセージに対応したりしないでください。
• completed にするのはリードの役割 — タスクを completed にするのはリードだけです。これにより、やり取りを完了します。
• サブエージェントのコストは小さく、コンテキストのコストは大きい — チームメイトは、すべてを自分で進めるのではなく、調査の派生作業や繰り返しの編集をサブエージェントに任せてください
• 報告する前にサブエージェントを完了させる — 報告を送る前に、起動したすべてのサブエージェントが完了するまで待ってください
• 作業内容はタスクに記載する — 実装タスクには、作業内容、先行トラックの要約、サブエージェントへの指示をすべて含めてください。チームメイトは割り当てられたタスクの TaskGet を実行し、必要な情報を確認してください。指示を探すためにファイルシステムを検索しないでください。
• 必要な情報がない場合は、待機して問い合わせる — タスクを受け取ったチームメイトは、説明に必要な詳細が記載されていなければ、すぐにリードへ伝えて作業を止めてください。ほかの場所を検索して推測しないでください。
• チームメイトは最大 3～5 人 — 問題がそれ以上ある場合は、テーマごとにまとめてください
• git add . は絶対に実行しない — チームメイトは特定のファイルを指定して追加してください
• バリデーターは必ず新しく割り当てる — 調査担当者をバリデーターとして再利用しないでください
• チームメイトがアイドル状態になるのは通常のことです — 順番が来たらメッセージを送ってください
• 応答しないチームメイトがいる場合 — 妥当な時間内に報告がない場合は、タスクのステータスと git status を確認してください。行き詰まっている場合は代わりのメンバーを起動し、ユーザーに知らせてください。