Deep Research

<!-- STATIC CONTEXT BLOCK START - Optimized for prompt caching --> <!-- All static instructions, methodology, and templates below this line --> <!-- Dynamic content (user queries, results) added after this block -->

Core System Instructions

目的: 8段階パイプライン(Scope → Plan → Retrieve → Triangulate → Synthesize → Critique → Refine → Package)を通じて、引用サポート済みで検証済みの研究レポートを配信し、ソース信頼性スコアリングと段階的なコンテキスト管理を実施します。

コンテキスト戦略: このスキルは2025年のコンテキストエンジニアリング最適実践を使用します:

• 静的指示のキャッシング(このセクション)
• 段階的情報開示(必要な場合のみ参考文献を読み込み)
• 「中央での喪失」の回避(重要情報は開始/終了時に配置、埋もれさせない)
• コンテキストナビゲーション用の明確なセクションマーカー

---

Decision Tree (最初に実行)

リクエスト分析
├─ シンプルな検索? → 停止: このスキルではなくWebSearchを使用
├─ デバッグ? → 停止: 標準ツールを使用、このスキルではない
└─ 複雑な分析が必要? → 続行

モード選択
├─ 初期段階の探索? → quick(3段階, 2-5分)
├─ 標準的な研究? → standard(6段階, 5-10分) [デフォルト]
├─ 重要な決定? → deep(8段階, 10-20分)
└─ 包括的なレビュー? → ultradeep(8+段階, 20-45分)

実行ループ(段階ごと)
├─ [methodology](./reference/methodology.md#phase-N)から段階指示を読み込み
├─ 段階タスクを実行
├─ 該当する場合は並列エージェントをスポーン
└─ 進捗を更新

検証ゲート
├─ `python scripts/validate_report.py --report [path]`を実行
├─ 合格? → 配信
└─ 失敗? → 修正(最大2回の試行) → 失敗したまま? → エスカレーション

---

Workflow (Clarify → Plan → Act → Verify → Report)

自立性原則: このスキルは独立して動作します。クエリコンテキストから仮定を推測してください。重大なエラーまたは理解不可能なクエリの場合のみ停止してください。

1. Clarify(明確化) (ほぼ不要 - 自立性を優先)

デフォルト: 自立的に進行します。クエリシグナルから仮定を導き出してください。

批判的に曖昧な場合のみ質問してください:

• クエリが理解不可能(例: 「その件について研究してください」)
• 矛盾した要件(例: 「迅速な50ソースの超深層分析」)

疑う場合: 標準モードで進行してください。ユーザーが必要に応じてリダイレクトします。

デフォルト仮定:

• 技術的なクエリ → 技術的対象者を想定
• 比較クエリ → バランスの取れた視点が必要と想定
• トレンドクエリ → 特に指定がない限り過去1-2年と想定
• 標準モードは大多数のクエリのデフォルト

---

2. Plan (計画)

モード選択基準:

• Quick (2-5分): 探索、大まかな概要、時間制約あり
• Standard (5-10分): ほとんどのユースケース、バランスの取れた深さ/速さ [デフォルト]
• Deep (10-20分): 重要な決定、徹底的な検証が必要
• UltraDeep (20-45分): 重大な分析、最大の厳密性

計画を発表して実行してください:

• 簡潔に述べてください: 選択したモード、推定時間、ソース数
• 例: 「標準モード研究を開始(5-10分、15-30ソース)」
• 承認を待たずに進行してください

---

3. Act (実行) (段階実行)

すべてのモードが実行:

• Phase 1: SCOPE - 境界を定義 (method)
• Phase 3: RETRIEVE - 並列検索実行(5-10並行検索+エージェント) (method)
• Phase 8: PACKAGE - テンプレートを使用してレポートを生成

Standard/Deep/UltraDeepが実行:

• Phase 2: PLAN - 戦略策定
• Phase 4: TRIANGULATE - 主張ごとに3以上のソースで検証
• Phase 4.5: OUTLINE REFINEMENT - 証拠に基づいて構造を適応 (WebWeaver 2025) (method)
• Phase 5: SYNTHESIZE - 新しい洞察を生成

Deep/UltraDeepが実行:

• Phase 6: CRITIQUE - レッドチーム分析
• Phase 7: REFINE - ギャップに対応

重大: 「中央での喪失」を回避してください

• セクション内に主な発見を開始と終了に配置し、埋もれさせない
• 明確なヘッダーとマーカーを使用
• 構造: サマリー → 詳細 → 結論(詳細が中央に挟まれていない)

段階的なコンテキスト読み込み:

• methodologyセクションをオンデマンドで読み込み
• templateはPhase 8でのみ読み込み
• すべてをインラインでしない - 外部ファイルを参照

反ハルシネーション プロトコル(重大)

• ソース接地: すべての事実的主張は直ちに特定のソース[N]を引用しなければならない
• 明確な境界: FACTS(ソースから)とSYNTHESIS(あなたの分析)を区別
• 明示的なマーカー: 「According to [1]...」または「[1] reports...」をソース根拠の文に使用
• ラベル付きなしの推測なし: 推測を「This suggests...」とマークし、「Research shows...」としない
• 引用前に検証: ソースが実際にXを述べているかどうか不確実な場合、引用を捏造しない
• 不確実な場合: 参照を発明するのではなく「X についてのソースは見つかりません」と言う

並列実行要件(速度の場合は重大)

Phase 3 RETRIEVE - 必須並列検索:

1. クエリを分解してから任意の検索を実行する前に5-10の独立した検索角度に
2. 単一のメッセージ内に ALL 検索をスタート複数のツール呼び出し(連続ではない)
3. FFF パターン用の品質閾値監視:
   • ソース数と平均信頼性スコアを追跡
   • 閾値に到達時に進行(モード固有、方法論を参照)
   • さらなる深さのための背景検索を継続
4. 3-5の並列エージェントをスポーン Task ツールを使用した深掘り調査用

正しい実行例:

[8+の並列ツール呼び出しを含む単一メッセージ]
WebSearch #1: コア主題セマンティック
WebSearch #2: 技術キーワード
WebSearch #3: 直近2024-2025フィルタリング
WebSearch #4: アカデミックドメイン
WebSearch #5: 批判的分析
WebSearch #6: 業界トレンド
Task agent #1: アカデミック論文分析
Task agent #2: 技術ドキュメント深掘り

❌ 間違い(連続実行):

WebSearch #1 → 結果を待つ → WebSearch #2 → 待つ → WebSearch #3...

✅ 正しい(並列実行):

1つのメッセージで同時にすべての検索+エージェントをスタート

---

4. Verify (検証) (常に実行)

Step 1: 引用検証 (捏造されたソースをキャッチ)

python scripts/verify_citations.py --report [path]

チェック:

• DOI解決(引用が実際に存在することを確認)
• タイトル/年マッチング(不一致メタデータを検出)
• 疑わしいエントリにフラグを付与(2024+でDOIなし、URLなし、検証失敗)

疑わしい引用が見つかった場合:

• フラグ付きエントリを手動で確認
• 捏造されたソースを削除または置き換え
• クリーンになるまで再実行

Step 2: 構造と品質の検証

python scripts/validate_report.py --report [path]

8つの自動チェック:

1. エグゼクティブサマリーの長さ(50-250語)
2. 必須セクションの有無(+推奨: 主張表、反対証拠)
3. 引用が[1]、[2]、[3]でフォーマットされている
4. 参考文献が引用と一致
5. プレースホルダーテキストなし(TBD、TODO)
6. 単語数が妥当(500-10000)
7. 最小10ソース
8. 壊れた内部リンクなし

失敗した場合:

• 試行1: フォーマット/リンクを自動修正
• 試行2: 手動確認+修正
• 2回の失敗後: 停止 → 問題を報告 → ユーザーに質問

---

5. Report (報告)

重大: 包括的で詳細な Markdown レポートを生成

ファイル構成(重大 - クリーンなアクセシビリティ):

1. ドキュメントに整理されたフォルダを作成:

• 常に専用フォルダを作成: ~/Documents/[TopicName]_Research_[YYYYMMDD]/
• 研究質問から清潔なトピック名を抽出(特殊文字を削除、アンダースコア/CamelCaseを使用)
• 例:
  • 「psilocybin research 2025」 → ~/Documents/Psilocybin_Research_20251104/
  • 「compare React vs Vue」 → ~/Documents/React_vs_Vue_Research_20251104/
  • 「AI safety trends」 → ~/Documents/AI_Safety_Trends_Research_20251104/
• フォルダが存在する場合は使用し、存在しない場合は作成
• これにより、クリーンな整理と簡単なアクセシビリティが保証される

2. すべての形式を同じフォルダに保存:

Markdown(プライマリソース):

• 保存先: [Documentsフォルダ]/research_report_[YYYYMMDD]_[topic_slug].md
• コピーも保存先: ~/.claude/research_output/(内部追跡)
• すべての発見を含む完全詳細レポート

HTML(マッキンゼースタイル - 常に生成):

• 保存先: [Documentsフォルダ]/research_report_[YYYYMMDD]_[topic_slug].html
• マッキンゼーテンプレート: mckinsey_template
• デザイン原則: シャープなコーナー(border-radiusなし)、ニュートラルなコーポレートカラー(紺#003d5c、グレー#f8f9fa)、超コンパクトレイアウト、情報ファースト構造
• 重要なメトリクスダッシュボードをトップに配置(トップの3-4つの主要定量的発見を抽出)
• 密集情報の提示にはデータテーブルを使用
• 14pxベースフォント、コンパクト間隔、装飾的なグラデーションや色なし
• Attribution Gradients (2025): 各引用[N]を<span class="citation">でラップし、ネストされたツールチップdivを使用してソース詳細を表示
• ブラウザで生成後に自動的に開く

PDF(プロフェッショナル印刷 - 常に生成):

• 保存先: [Documentsフォルダ]/research_report_[YYYYMMDD]_[topic_slug].pdf
• generating-pdf スキルを使用(一般的なエージェント付きTask ツール経由)
• ヘッダーとページ番号を備えたプロフェッショナルな書式設定
• デフォルトのPDFビューアで生成後に自動的に開く

3. ファイルネーミング規約: すべてのファイルが簡単にマッチするために同じベース名を使用:

• research_report_20251104_psilocybin_2025.md
• research_report_20251104_psilocybin_2025.html
• research_report_20251104_psilocybin_2025.pdf

長さ要件(段階的組立でアンリミテッド):

• Quick モード: 2,000+ 語(基本的品質閾値)
• Standard モード: 4,000+ 語(包括的分析)
• Deep モード: 6,000+ 語(徹底的な調査)
• UltraDeep モード: 10,000-50,000+ 語(制限なし - 証拠が保証する限り包括的)

アンリミテッド長がどのように機能するか: 段階的ファイル組立により、セクションごと生成でアンリミテッド報告書長を可能にします。 各セクションは直ちにファイルに書き込まれます(出力トークン制限を回避)。 多くの発見を持つ複雑なトピック? 20、30、50+の発見を生成 - 制約なし!

コンテンツ要件:

• テンプレートを正確な構造として使用
• 各セクションを適切な深さに生成(証拠で決定、単語ターゲットではない)
• 具体的なデータ、統計、日付、数字を含める(曖昧なステートメントではない)
• セクションあたり複数の段落と証拠(必要なだけ多く)
• 各セクションは焦点を当てた生成注意を得る
• サマリーを書かない - 完全分析を書く

文体基準:

• ナラティブドリブン: 流暢なプローズで書く。各発見は物語(開始(コンテキスト)、中間(証拠)、終了(含意))を語る
• 精密性: すべての単語は意図的に選択され、意図を持つ
• 経済性: 不要な部分をなくし、複雑な文法や不要な修飾語を削除
• 明確性: 正確な数字は文に組み込まれ、隔離されていない(「この研究は死亡率を23%削減することを示した」)
• 直接性: 装飾なしに発見を述べる
• シグナル対ノイズ: 密集情報、読者の時間を尊重

箇条書きポリシー(アンチファティーグ施行):

• 箇条書きをまばらに使用: 異なるリスト(製品名、会社ロスター、列挙ステップ)のみ
• 決してプライマリコンテンツ配信として箇条書きを使用しない - 思考が分裂
• 各発見セクションは実質的なプローズパラグラフが必要(最小3-5パラグラフ)
• 例: 「• 市場規模: $2.4B」ではなく、「世界市場は2023年に24億ドルに達し、消費者需要と規制の追い風によって支えられた[1]。」と書く

アンチファティーグ品質チェック(各セクションに適用): セクションが完全と考える前に、検証:

• パラグラフ数: メジャーセクション(##見出し)≥3パラグラフ
• プローズファースト: <20%がコンテンツの箇条書き(≥80%は流暢なプローズでなければならない)
• プレースホルダーなし: 「Content continues」、「Due to length」、「[Sections X-Y]」のゼロインスタンス
• 証拠が豊富: 具体的なデータポイント、統計、引用(曖昧なステートメントではない)
• 引用密度: メジャーな主張は同じ文内で引用

チェックが失敗した場合: セクションを再生成してから次に進む。

ソースアトリビューション標準(捏造防止に重大):

• 直ちの引用: すべての事実的主張の直後に[N]引用が同じ文
• 直接ソースを引用: 事実的ステートメントに「According to [1]...」または「[1] reports...」を使用
• 事実と統合を区別:
  • ✅ 良い: 「Mortality decreased 23% (p<0.01) in the treatment group [1].」
  • ❌ 悪い: 「Studies show mortality improved significantly.」
• 曖昧なアトリビューションなし:
  • ❌ 決して: 「Research suggests...」、「Studies show...」、「Experts believe...」
  • ✅ 常に: 「Smith et al. (2024) found...」[1]、「According to FDA data...」[2]
• 推測を明示的にラベル付け:
  • ✅ 良い: 「This suggests a potential mechanism...」(分析、事実ではない)
  • ❌ 悪い: 「The mechanism is...」(引用なしに事実として提示)
• 不確実性を認める:
  • ✅ 良い: 「No sources found addressing X directly.」
  • ❌ 悪い: ギャップを埋めるために引用を捏造
• テンプレートパターン: 「[数字/データを持つ具体的な主張] [Citation]. [分析/含意]。」

ユーザーに配信:

1. エグゼクティブサマリー(チャットにインライン)
2. 整理されたフォルダパス(例: 「All files saved to: ~/Documents/Psilocybin_Research_20251104/」)
3. 3つのすべての形式が生成されたことの確認:
   • Markdown(ソース)
   • HTML(マッキンゼースタイル、ブラウザで開かれた)
   • PDF(プロフェッショナル印刷、ビューアで開かれた)
4. ソース品質評価サマリー(ソース数)
5. 次のステップ(関連がある場合)

生成ワークフロー: 段階的ファイル組立(アンリミテッド長)

Phase 8.1: セットアップ

# 研究質問からトピックスラッグを抽出
# フォルダを作成: ~/Documents/[TopicName]_Research_[YYYYMMDD]/
mkdir -p ~/Documents/[folder_name]

# frontmatter を含む初期 markdown ファイルを作成
# ファイルパス: [Documents folder]/research_report_[YYYYMMDD]_[topic_slug].md

Phase 8.2: 段階的なセクション生成

重大な戦略: 各セクションを個別に生成し、Write/Editツールを使用してファイルに書き込みます。 これにより、各生成を管理可能に保ちながらアンリミテッドなレポート長が可能になります。

出力トークン制限セーフガード(重大 - Claude Code デフォルト: 32K):

Claude Code デフォルト制限: 32,000出力トークン(≈24,000語合計/スキル実行あたり) これはハードリミットであり、スキル内では変更できません。

これが何を意味するか:

• 総出力(あなたのテキスト+すべてのツール呼び出しコンテンツ) <32,000トークン
• 32,000トークン ≈ 最大24,000語
• 安全マージンを残す: ターゲット ≤20,000語合計出力

モードごとの現実的なレポートサイズ:

• Quick モード: 2,000-4,000語 ✅(制限をはるかに下回る)
• Standard モード: 4,000-8,000語 ✅(快適に制限下)
• Deep モード: 8,000-15,000語 ✅(注意深く達成可能)
• UltraDeep モード: 15,000-20,000語 ⚠️(制限時、綿密に監視)

>20,000語のレポート: ユーザーはスキルを複数回実行する必要があります:

• 実行1: 「Part 1を生成(セクション1-6)」 → part1.mdに保存
• 実行2: 「Part 2を生成(セクション7-12)」 → part2.mdに保存
• ユーザーが手動でマージするか、Claude にファイルのマージを要求

自動継続戦略(真のアンリミテッド長):

単一実行でレポートが18,000語を超える場合:

1. セクション1-10を生成(18K語未満に保つ)
2. コンテキスト保存ファイルを保存して継続状態
3. Task ツール経由で継続エージェントをスポーン
4. 継続エージェント: 状態を読む → 次のバッチを生成 → 必要に応じて次エージェントをスポーン
5. 完了するまで再帰的にチェーン続行

これにより、1エージェントあたり32K制限を尊重しながら真のアンリミテッド長が実現

引用追跡の初期化:

citations_used = []  # この列をワーキングメモリ全体で保持

セクション生成ループ:

パターン: セクションコンテンツを生成 → Write/Editツールでそのコンテンツを使用 → 次セクションに進む 各Write/Editコールは1つのセクションを含む(≤セクションあたり2,000語)

1. エグゼクティブサマリー (200-400語)

   • セクションコンテンツを生成
   • ツール: Write(file, content=frontmatter + エグゼクティブサマリー)
   • 使用された引用を追跡
   • 進捗: 「✓ エグゼクティブサマリー」

2. Introduction (400-800語)

   • セクションコンテンツを生成
   • ツール: Edit(file, old=last_line, new=old + Introduction セクション)
   • 使用された引用を追跡
   • 進捗: 「✓ Introduction」

3. Finding 1 (600-2,000語)

   • 完全な発見を生成
   • ツール: Edit(file, append Finding 1)
   • 使用された引用を追跡
   • 進捗: 「✓ Finding 1」

4. Finding 2 (600-2,000語)

   • 完全な発見を生成
   • ツール: Edit(file, append Finding 2)
   • 使用された引用を追跡
   • 進捗: 「✓ Finding 2」

...すべての発見に対して継続(各発見 = 1つの Edit ツール呼び出し、≤2,000語)

重大: 10発見 × 1,500語 = 15,000語の発見がある場合 各Edit呼び出しが1,500語(2,000語リミット下)のため、これはOK ファイルは15,000語に成長しますが、単一のツール呼び出しは制限を超えません

4. 統合と洞察

   • 生成: ソースステートメント以上の新しい洞察(統合に必要なだけ長く)
   • ツール: Edit(ファイルに追加)
   • 追跡: 引用を抽出し、citations_usedに追加
   • 進捗: 「Generated Synthesis ✓」

5. 制限と注意事項

   • 生成: 反対証拠、ギャップ、不確実性(適切な深さ)
   • ツール: Edit(ファイルに追加)
   • 追跡: 引用を抽出し、citations_usedに追加
   • 進捗: 「Generated Limitations ✓」

6. 推奨事項

   • 生成: 直ちのアクション、次のステップ、研究ニーズ(適切な深さ)
   • ツール: Edit(ファイルに追加)
   • 追跡: 引用を抽出し、citations_usedに追加
   • 進捗: 「Generated Recommendations ✓」

7. 参考文献(重大 - すべての引用)

   • 生成: citations_usedリストから COMPLETE 参考文献を含む EVERY 引用
   • フォーマット: [1]、[2]、[3]... [N] - 各引用は完全なエントリを得る
   • 検証: citations_usedリストをチェック - リストに[1]から[73]が含まれている場合、73エントリすべてを生成
   • NO 範囲([1-50])、NO プレースホルダー(「Additional citations」)、NO 切り詰め
   • ツール: Edit(ファイルに追加)
   • 進捗: 「Generated Bibliography ✓ (N citations)」

8. 方法論付録

   • 生成: 研究プロセス、検証アプローチ(適切な深さ)
   • ツール: Edit(ファイルに追加)
   • 進捗: 「Generated Methodology ✓」

Phase 8.3: 自動継続決定ポイント

セクション生成後、単語数をチェック:

総出力 ≤18,000語の場合: 正常に完了

• 参考文献を生成(すべての引用)
• 方法論を生成
• 完全なレポートを検証
• ~/.claude/research_output/にコピーを保存
• 完了! ✓

総出力が18,000語を超える場合: 自動継続プロトコル

Step 1: 継続状態を保存 ファイルを作成: ~/.claude/research_output/continuation_state_[report_id].json

{
  "version": "2.1.1",
  "report_id": "[unique_id]",
  "file_path": "[レポート.mdへの絶対パス]",
  "mode": "[quick|standard|deep|ultradeep]",

  "progress": {
    "sections_completed": [完了したセクションIDのリスト],
    "total_planned_sections": [合計カウント],
    "word_count_so_far": [現在の単語数],
    "continuation_count": [この継続がどれ、1で開始]
  },

  "citations": {
    "used": [1, 2, 3, ..., N],
    "next_number": [N+1],
    "bibliography_entries": [
      "[1] フル引用エントリ",
      "[2] フル引用エントリ",
      ...
    ]
  },

  "research_context": {
    "research_question": "[元の質問]",
    "key_themes": ["theme1", "theme2", "theme3"],
    "main_findings_summary": [
      "Finding 1: [100語サマリー]",
      "Finding 2: [100語サマリー]",
      ...
    ],
    "narrative_arc": "[現在のストーリー位置: beginning/middle/conclusion]"
  },

  "quality_metrics": {
    "avg_words_per_finding": [計算される平均],
    "citation_density": [1000語あたりの引用],
    "prose_vs_bullets_ratio": [例: 「85% prose」],
    "writing_style": "technical-precise-data-driven"
  },

  "next_sections": [
    {"id": N, "type": "finding", "title": "Finding X", "target_words": 1500},
    {"id": N+1, "type": "synthesis", "title": "Synthesis", "target_words": 1000},
    ...
  ]
}

Step 2: 継続エージェントをスポーン

Task ツール一般的なエージェントで使用:

Task(
  subagent_type="general-purpose",
  description="深い研究レポート生成を続行",
  prompt="""
継続タスク: 既存の深い研究レポートの生成を続行しています。

重大な指示:
1. 継続状態ファイルを読む: ~/.claude/research_output/continuation_state_[report_id].json
2. コンテキストを理解するために既存レポートを読む: [状態からのfile_path]
3. フローと文体を理解するために最後の3つの完了セクションを読む
4. 状態からの研究コンテキストを読む: テーマ、ナラティブアーク、文体
5. 状態からの引用番号付けを継続: state.citations.next_number
6. 状態から品質メトリクスを保持(平均語数、引用密度、プロー比)

コンテキスト保存:
- 研究質問: [状態から]
- 確立されたキーテーマ: [状態から]
- ここまでの発見: [状態からのサマリー]
- ナラティブ位置: [状態から]
- 文体: [状態から]

あなたのタスク:
次のセクションバッチを生成(18,000語下に保つ):
[状態からのnext_sections]

Write/Editツールを使用して既存ファイルに追加: [file_path]

品質ゲート(各セクション前に検証):
- セクションあたりの語数: [avg_words_per_finding]の±20%内
- 引用密度: [citation_density]±0.5/1K語を一致
- プロー比: ≥80%プロー保持(箇条書きではない)
- テーマ整合: セクションはkey_themesに関連付け
- スタイル一貫性: [writing_style]と一致

セクション生成後:
- さらにセクションが残る場合: 状態を更新し、次の継続エージェントをスポーン
- 最終セクション: 完全な参考文献を生成、レポートを検証、状態ファイルをクリーンアップ
"""
)

Step 3: 継続状態を報告 ユーザーに伝える:

📊 レポート生成: Part 1 完了(Nセクション、X語)
🔄 スポーンされたエージェント経由で自動継続中...
   次のバッチ: [セクションリスト]
   進捗: [X%] 完了

Phase 8.4: 継続エージェント品質プロトコル

継続エージェント開始時:

コンテキスト読み込み(重大):

1. continuation_state.json を読む → ALL コンテキストを読み込み
2. 既存レポートファイルを読む → 最後の3セクションをレビュー
3. パターンを抽出:
   • 文構造の複雑性
   • 使用される技術用語
   • 引用プレースメント パターン
   • パラグラフ転換スタイル

事前生成チェックリスト:

• 研究コンテキストを読み込み(テーマ、質問、ナラティブアーク)
• フローのための以前のセクションをレビュー
• 引用番号付けを読み込み(N+1から開始)
• 品質ターゲットを読み込み(語数、密度、スタイル)
• ナラティブアーク内での位置を理解(beginning/middle/end)

セクションごとの生成:

1. セクションコンテンツを生成
2. 品質チェック:
   • 単語数: ターゲット±20%内
   • 引用密度: 確立されたレートと一致
   • プロー比: ≥80%プロー
   • テーマ接続: key_themesに関連付け
   • スタイルマッチ: quality_metrics.writing_styleと一致
3. チェックが失敗した場合: セクションを再生成
4. 合格した場合: ファイルに書き込み、状態を更新

ハンドオフ決定:

• 計算: 現在の単語数 + 残セクション × avg_words_per_section
• 合計 <18K の場合: 残りのセクションを生成 + 完成
• 合計 >18K の場合: 部分的なバッチを生成、状態を更新、次エージェントをスポーン

最終エージェント責任:

• 最終コンテンツセクションを生成
• 状態から COMPLETE 参考文献を生成: state.citations.bibliography_entriesから ALL 引用を使用
• レポート全体を読む
• 検証を実行: python scripts/validate_report.py --report [path]
• continuation_state.jsonを削除(クリーンアップ)
• ユーザーにメトリクス付きで完了を報告

アンチファティーグ組み込み: 各エージェントは管理可能なチャンク(≤18K語)を生成し、品質を保つ。 コンテキスト保存により継続境界を超えた一貫性を保証。

HTML を生成(マッキンゼースタイル)

1. ./templates/mckinsey_report_template.htmlから McKinsey テンプレートを読む

2. 発見から3-4つの主要な定量的メトリクスをダッシュボード用に抽出

3. MD から HTML 変換用に Python スクリプトを使用:

   cd ~/.claude/skills/deep-research
   python scripts/md_to_html.py [markdown_report_path]
   

   スクリプトは2つの部分を返す:

   • Part A ({{CONTENT}}): 参考文献を除くすべてのセクション、適切に HTML に変換
   • Part B ({{BIBLIOGRAPHY}}): 参考文献セクションのみ、HTML としてフォーマット

   重大: スクリプトがすべての変換を自動的に処理:

   • ヘッダー: ## → <div class="section"><h2 class="section-title">、### → <h3 class="subsection-title">
   • リスト: マークダウン箇条書き → <ul><li>適切なネスト付き
   • テーブル: マークダウンテーブル → <table> thead/tbody付き
   • パラグラフ: テキストは <p> タグでラップ
   • 太字/斜体: text → <strong>、text → <em>
   • 引用: [N]はツールチップ変換のために保存

4. 引用ツールチップを追加(Attribution Gradients): {{CONTENT}}の各[N]引用(参考文献以外)に、対話的ツールチップをオプションで追加:

   <span class="citation"
     >[N]
     <span class="citation-tooltip">
       <div class="tooltip-title">[ソースタイトル]</div>
       <div class="tooltip-source">[著者/出版社]</div>
       <div class="tooltip-claim">
         <div class="tooltip-claim-label">主張をサポート:</div>
         [この引用を含む文を抽出]
       </div>
     </span>
   </span>
   

   注: このステップは速度のためにオプション。基本的な[N]引用で十分。

5. テンプレート内のプレースホルダーを置き換え:

   • {{TITLE}} - レポートタイトル(MD の最初の##見出しから抽出)
   • {{DATE}} - 生成日(YYYY-MM-DD フォーマット)
   • {{SOURCE_COUNT}} - ユニークなソースの数
   • {{METRICS_DASHBOARD}} - ステップ2からのメトリクス HTML
   • {{CONTENT}} - Part A からの HTML(スクリプト出力)
   • {{BIBLIOGRAPHY}} - Part B からの HTML(スクリプト出力)

6. 重大: NO EMOJIS - 最終 HTML から絵文字文字を削除

7. 保存先: [folder]/research_report_[YYYYMMDD]_[slug].html

8. HTML を検証(必須):

   python scripts/verify_html.py --html [html_path] --md [md_path]
   

   • チェック合格: ステップ9に進む
   • チェック失敗: エラーを修正して再実行

9. ブラウザで開く: open [html_path]

PDF を生成

1. Task ツール一般的なエージェントで使用
2. generating-pdf スキルを入力として markdown を呼び出し
3. 保存先: [folder]/research_report_[YYYYMMDD]_[slug].pdf
4. PDF は完了時に自動的に開く

---

Output Contract

フォーマット: テンプレートに正確に従う包括的な Markdown レポート

必須セクション(すべて詳細である必要があります):

• エグゼクティブサマリー(2-3の簡潔なパラグラフ、50-250語)
• Introduction(2-3パラグラフ: 質問、範囲、方法論、仮定)
• メイン分析(4-8の発見、各300-500語と引用[1]、[2]、[3]付き)
• 統合と洞察(500-1000語: パターン、新しい洞察、含意)
• 制限と注意事項(2-3パラグラフ: ギャップ、仮定、不確実性)
• 推奨事項(3-5直ちのアクション、3-5次のステップ、3-5さらなる研究)
• 参考文献(重大 - 以下のルールを参照)
• 方法論付録(2-3パラグラフ: プロセス、ソース、検証)

参考文献要件(ゼロ許容 - 完全な参考文献なしでレポートは使用不可):

• ✅ レポート本文で使用された EVERY 引用[N]を含めなければならない(レポートが[1]-[50]を持つ場合、50エントリすべてを書く)
• ✅ フォーマット: [N] 著者/組織(年)。"タイトル"。出版物。URL(取得: 日付)
• ✅ 各エントリは独自の行に、完全なメタデータ付き
• ❌ プレースホルダーなし: 決して「[8-75] Additional citations」、「...continue...」、「etc.」、「[Continue with sources...]」を使用しない
• ❌ NO 範囲: [3]、[4]、[5]...を個別に書く、「[3-50]」ではない
• ❌ 切り詰めなし: 30ソースが引用される場合、すべての30エントリを完全に書く
• ⚠️ 参考文献にプレースホルダーまたは欠けた引用が含まれている場合、検証は失敗
• ⚠️ 完全な参考文献がないレポートはガベージ - 主張を検証する方法がない

厳格に禁止:

• プレースホルダーテキスト(TBD、TODO、[citation needed])
• 無引用の主な主張
• 壊れたリンク
• 欠けた必須セクション
• 詳細な分析ではなく、短いサマリー
• 具体的な証拠のない曖昧なステートメント

文体基準(重大):

• ナラティブドリブン: 理解を段階的に構築する完全な文を持つ流暢なプローズで書く
• 精密性: 各単語を意図的に選択 - すべての単語は意図を持つ必要がある
• 経済性: 不要な部分をなくし、不要な形容詞、複雑な文法を削除
• 明確性: 正確な技術用語を使用し、曖昧さを避ける。正確な数字を文に組み込み、箇条書きではない
• 直接性: 装飾なしに発見を明確に述べる
• シグナル対ノイズ: 高い情報密度、読者の時間を尊重
• 箆条書き規律: 異なるリスト(製品、会社、ステップ)にのみ箇条書きを使用。デフォルトはプローズパラグラフ
• 精密性の例:
  • 悪い: 「significantly improved outcomes」 → 良い: 「reduced mortality 23% (p<0.01)」
  • 悪い: 「several studies suggest」 → 良い: 「5 RCTs (n=1,847) show」
  • 悪い: 「potentially beneficial」 → 良い: 「increased biomarker X by 15%」
  • 悪い: 「• Market: $2.4B」 → 良い: 「The market reached $2.4 billion in 2023, driven by consumer demand [1].」

品質ゲート(検証により施行):

• 最小2,000語(標準モード)
• 平均信頼性スコア>60/100
• メジャーな主張あたり3+ソース
• 事実対分析の明確な区別
• すべてのセクション現在で詳細

---

Error Handling & Stop Rules

直ちに停止した場合:

• 同じエラーで2つの検証失敗 → 一時停止、報告、ユーザーに質問
• 徹底的な検索後に<5ソース → 制限を報告、方向を要求
• ユーザーが中断/範囲を変更 → 新しい方向を確認

段階的な低下:

• 5-10ソース → 制限に注記、追加検証を進める
• 時間制約に到達 → 部分的な結果をパッケージ化、ギャップをドキュメント
• 高優先度の批評問題 → 直ちに対処

エラー形式:

⚠️ 問題: [説明]
📊 コンテキスト: [試行されたもの]
🔍 試行: [解決ステップ]
💡 オプション:
   1. [オプション1]
   2. [オプション2]
   3. [オプション3]

---

Quality Standards (常に施行)

すべてのレポートは以下が必須:

• 10+ソース(より少ない場合はドキュメント)
• メジャーな主張あたり3+ソース
• エグゼクティブサマリー<250語
• URL付きフル引用
• 信頼性評価
• 制限セクション
• ドキュメント化された方法論
• プレースホルダーなし

優先事項: 速度より徹底性。品質 >速度。

---

Inputs & Assumptions

必須:

• 研究質問(文字列)

オプション:

• モード(quick/standard/deep/ultradeep)
• 時間制約
• 必須の視点/ソース
• 出力フォーマット

仮定:

• ユーザーは検証済み、引用サポート済み情報が必要
• トピックに10-50ソースが利用可能
• 時間投資: 5-45分

---

When to Use / NOT Use

使用する場合:

• 包括的分析(10+ソースが必要)
• テクノロジー/アプローチ/戦略の比較
• 最先端レビュー
• マルチパースペクティブ調査
• 技術的決定
• 市場/トレンド分析

使用しない場合:

• シンプルな検索(WebSearch を使用)
• デバッグ(標準ツールを使用)
• 1-2検索の回答
• 時間制約のある迅速な回答

---

Scripts (オフライン、Python stdlib のみ)

場所: ./scripts/

• research_engine.py - オーケストレーションエンジン
• validate_report.py - 品質検証(8チェック)
• citation_manager.py - 引用追跡
• source_evaluator.py - 信頼性スコアリング(0-100)

外部依存は不要。

---

Progressive References (オンデマンドで読み込み)

これらはインラインにしない - 参照のみ:

• Complete Methodology - 8段階の詳細
• Report Template - 出力構造
• README - 使用ドキュメント
• Quick Start - 高速参照
• Competitive Analysis - OpenAI/Gemini比較

コンテキスト管理: 現在の段階のためだけにオンデマンドでファイルを読み込み。すべてのコンテンツを事前読み込みしない。

---

<!-- STATIC CONTEXT BLOCK END --> <!-- ⚡ 上記コンテンツはキャッシュ可能(>1024トークン、静的) --> <!-- 📝 以下: 動的コンテンツ(ユーザークエリ、取得データ、生成レポート) --> <!-- この構造により、プロンプトキャッシング経由で85%レイテンシー削減を可能にする -->

---

Dynamic Execution Zone

ユーザークエリ処理: [実行中にユーザー研究質問がここに挿入される]

取得情報: [検索結果とソースがここに蓄積される]

生成分析: [発見、統合、レポートコンテンツがここで生成される]

注: このセクションはスキル定義では空。コンテンツは実行時のみ入力。