deep-research

ディープリサーチ — 幅広く調べ、何も失わない

このスキルが防ごうとしている失敗パターンは、大規模な並列リサーチで80〜100Kトークン分の詳細を集め、各サブエージェントが削った要約を返し、オーケストレーターがさらに短いブリーフへ圧縮し、生の調査結果は一時的なエージェントのトランスクリプト（スクラッチパッドのタスク出力）にしか残らず、コンテナが回収されると消えてしまう、というものです。 結果として、高コストのリサーチが薄い成果物になり、詳細が失われます。これをしてはいけません。

ルール：永続的な成果物を2つ作る。1つだけで済ませない

重要なリサーチでは必ず、以下の2つを作成し、ディスクに保存します。

1. 統合版 — ブリーフ／回答（表、主張、推奨事項）。
2. 完全な付録 — ソース／企業／観点ごとの詳細（生の数値、資金調達履歴、提供領域、日付、ソースURLの原文）で、統合版で圧縮されたもの。

保存した統合版が収集した情報より大幅に短い場合、詳細との整合を取るために付録を使います。詳細はチャットやトランスクリプトだけでなく、永続的な場所に必ず残します。「チャットで要約した」は保存したことになりません。

調査を並列展開する

1. 観点を計画する — 異なる観点（企業、ソースの種類、サブ質問）ごとにサブエージェントを1つ割り当てます。どのモデルを使うか、その理由とともにユーザーに伝えます（サブエージェントのモデル注記ルール）。
2. サブエージェントのプロンプトで、ディスクへの書き込みを必須にする。 すべてのリサーチ用サブエージェントは、ソースを原文のまま含めて、完全な調査結果を永続ファイル（例：セッションのスクラッチパッドディレクトリに観点ごとに1ファイル）へ書き込み、返すのは短い参照先と主要な調査結果だけにします。エージェントが返した要約を記録として当てにしてはいけません。構造上、要約は削られており、トランスクリプトも一時的なものです。
3. ソースを原文のまま記録する — すべての主張に、[番号] [ソースURL] [日付] [報告値か推定値か]を付けます。圧縮で最初に失われるのはURLなので、必ず残します。
4. 記憶ではなくファイルをもとに統合する — 書き込んだファイルを読み返して統合版を作成し、情報がひそかに抜け落ちないようにします。
5. 完了とする前に、両方の成果物を保存する — 統合版と付録の両方をコミット／書き込みます。これで保存完了です。

保存先

• リリース済みの動作に関する技術リサーチ → ユーザーが行動するために必要ならdocs/ページに、そうでなければCLAUDE.mdのkeyFilesから参照するコントリビューター向けメモに保存し、孤立したドキュメントにならないようにします。どちらにするかはpublic-vs-internal-docsとdoc-tiersに従って決めます。
• 競合、市場、価格設定、Go-to-Market、またはロードマップに関するリサーチ → このリポジトリのどのディレクトリにも保存しません。 このリポジトリは公開されており、no-product-strategy-hereは無条件のルールです。ファイルを削除しても、履歴や他のブランチには残ります。調査結果は回答で共有し、人間が非公開の場所に保存できるようにします。
• どちらか判断に迷ったら、確認します。ただし、「保存先が不明」を「どこにも保存しない」にしてはいけません。

やってはいけないこと

• 15エージェントによる並列調査の成果物として、チャットで1段落の要約だけを提示しないでください。
• ブリーフを短くするためにソース／URL／日付を削らないでください。その詳細は付録に記載します。
• 完全版を、コミットしていない一時的なトランスクリプトやスクラッチパッドにしか残さないでください。