mcpField
G
github-deep-research

github-deep-research

github.com/bytedance開発84.6k2.9k 回インストール今日更新
リポジトリ

github-deep-research について

GitHub API のデータとウェブ検索・取得を組み合わせ、包括的な Markdown レポートを作成するリサーチスキルです。段階的な探索、情報源の確認、分析を通じてリポジトリやテーマを調査します。

主な機能

  1. 014段階のリサーチワークフロー
  2. 02GitHub API によるリポジトリ情報
  3. 03ウェブ検索とページ取得
  4. 04引用付き Markdown レポート
  5. 05情報源の信頼度評価

活用シーン

  1. 01GitHub リポジトリの調査
  2. 02広い検索から技術的な詳細への掘り下げ
  3. 03根拠と引用をまとめたレポート作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/bytedance/deer-flow --skill github-deep-research

インストール後、Claude Code で/github-deep-researchを入力して読み込まれたか確認します。

同梱ファイルassets/report_template.mdscripts/github_api.py

詳細

GitHub ディープリサーチスキル

GitHub API、web_search、web_fetchを組み合わせた複数ラウンドの調査により、包括的なMarkdownレポートを作成します。

調査ワークフロー

  • ラウンド1：GitHub API
  • ラウンド2：情報の発見
  • ラウンド3：詳細調査
  • ラウンド4：深掘り

基本的な方法論

クエリ戦略

広範囲から絞り込む：まずGitHub APIを使い、次に一般的なクエリを実行し、調査結果に基づいて絞り込みます。

Round 1: GitHub API
Round 2: "{topic} overview"
Round 3: "{topic} architecture", "{topic} vs alternatives"
Round 4: "{topic} issues", "{topic} roadmap", "site:github.com {topic}"

情報源の優先順位：

  1. 公式ドキュメント／リポジトリ（最も重視）
  2. 技術ブログ（Medium、Dev.to）
  3. ニュース記事（信頼できる媒体）
  4. コミュニティでの議論（Reddit、HN）
  5. ソーシャルメディア（最も重視度が低く、意見の把握に使用）
調査ラウンド

ラウンド1 - GitHub API read_file()を使わずに、scripts/github_api.pyを直接実行します：

python /path/to/skill/scripts/github_api.py <owner> <repo> summary
python /path/to/skill/scripts/github_api.py <owner> <repo> readme
python /path/to/skill/scripts/github_api.py <owner> <repo> tree

利用可能なコマンド（github_api.pyの最後の引数）：

  • summary
  • info
  • readme
  • tree
  • languages
  • contributors
  • commits
  • issues
  • prs
  • releases

issuesコマンドは、プルリクエストを除くリポジトリのissueのみを返します。指定されたissueの上限数を満たす必要がある場合は、追加ページも取得します。プルリクエストは、別途prsを使って調査してください。

ラウンド2 - 情報の発見（web_searchを3～5回）

  • 概要を把握し、重要な用語を特定する
  • 公式ウェブサイト／リポジトリを見つける
  • 主なプレイヤー／競合相手を特定する

ラウンド3 - 詳細調査（web_searchとweb_fetchを5～10回）

  • 技術アーキテクチャの詳細
  • 重要な出来事の時系列
  • コミュニティの反応
  • 価値のあるURLの全内容を確認するため、web_fetchを使う

ラウンド4 - 深掘り

  • コミット履歴を分析して時系列を把握する
  • issue／PRを確認し、機能の進化を調べる
  • コントリビューターの活動を確認する

レポートの構成

assets/report_template.mdのテンプレートに従います：

  1. メタデータブロック - 日付、確信度、対象
  2. エグゼクティブサマリー - 主要な指標を含む2～3文の概要
  3. 時系列 - フェーズごとに日付を示す
  4. 主要な分析セクション - トピック別の詳細な分析
  5. 指標と比較 - 表、成長グラフ
  6. 強みと弱み - バランスの取れた評価
  7. 情報源 - カテゴリ別の参考資料
  8. 確信度の評価 - 確信度別の主張
  9. 方法論 - 使用した調査方法
Mermaid図

役立つ場合は図を含めます：

時系列（ガントチャート）：

gantt
    title Project Timeline
    dateFormat YYYY-MM-DD
    section Phase 1
    Development    :2025-01-01, 2025-03-01
    section Phase 2
    Launch         :2025-03-01, 2025-04-01

アーキテクチャ（フローチャート）：

flowchart TD
    A[User] --> B[Coordinator]
    B --> C[Planner]
    C --> D[Research Team]
    D --> E[Reporter]

比較（円グラフ／棒グラフ）：

pie title Market Share
    "Project A" : 45
    "Project B" : 30
    "Others" : 25

確信度の評価

情報源の質に基づいて確信度を設定します：

確信度基準
高（90%以上）公式ドキュメント、GitHubデータ、複数の裏付けとなる情報源
中（70～89%）信頼できる単一の情報源、最近の記事
低（50～69%）ソーシャルメディア、未検証の主張、古い情報

出力

レポートを次の名前で保存します：research_{topic}_{YYYYMMDD}.md

書式ルール
  • 日本語のコンテンツ：全角の句読点（，。：；！？）を使用
  • 技術用語：初出時にWiki／ドキュメントのURLを記載
  • 表：指標や比較に使用
  • コードブロック：技術的な例に使用
  • Mermaid：アーキテクチャ、時系列、フローに使用

ベストプラクティス

  1. 公式情報源から始める - リポジトリ、ドキュメント、企業ブログ
  2. コミット／PRから日付を確認する - 記事より信頼性が高い
  3. 主張を複数の情報源で照合する - 独立した情報源を2つ以上使う
  4. 食い違う情報を記録する - 矛盾を隠さない
  5. 事実と意見を区別する - 推測には明確なラベルを付ける
  6. 重要：必ずインライン引用を含める - 外部情報源に基づく各主張の直後に[citation:Title](URL)形式で記載する
  7. 検索結果からURLを抽出する - web_searchは{title, url, snippet}を返すため、必ずURLフィールドを使用する
  8. 調査しながら更新する - 最後まで統合を待たない
引用の例

良い例 - インライン引用あり：

The project gained 10,000 stars within 3 months of launch [citation:GitHub Stats](https://github.com/owner/repo).
The architecture uses LangGraph for workflow orchestration [citation:LangGraph Docs](https://langchain.com/langgraph).

悪い例 - 引用なし：

The project gained 10,000 stars within 3 months of launch.
The architecture uses LangGraph for workflow orchestration.

コメント

Markdown 対応