GitHub Deep Research スキル
GitHub API、web_search、web_fetchを組み合わせた多段階調査。包括的なMarkdownレポートを生成します。
調査ワークフロー
- ラウンド1: GitHub API
- ラウンド2: 発見
- ラウンド3: 詳細調査
- ラウンド4: 深掘り
核となる方法論
クエリ戦略
広範から詳細へ: GitHub APIから開始し、一般的なクエリに進み、調査結果に基づいて絞り込みます。
ラウンド1: GitHub API
ラウンド2: "{トピック} 概要"
ラウンド3: "{トピック} アーキテクチャ", "{トピック} vs 代替手段"
ラウンド4: "{トピック} 課題", "{トピック} ロードマップ", "site:github.com {トピック}"
情報源の優先順位付け:
- 公式ドキュメント/リポジトリ（最優先）
- 技術ブログ（Medium、Dev.to）
- ニュース記事（検証済み媒体）
- コミュニティ議論（Reddit、HN）
- ソーシャルメディア（最低優先度、感情分析用）
調査ラウンド
ラウンド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
ラウンド2 - 発見 (3～5回の web_search)
- 概要を把握し、主要キーワードを特定
- 公式ウェブサイト/リポジトリを発見
- 主要プレイヤー/競合を特定
ラウンド3 - 詳細調査 (5～10回の web_search + web_fetch)
- 技術アーキテクチャの詳細
- 主要イベントのタイムライン
- コミュニティの感情
- 価値のあるURLに対して
web_fetchを使用し、全文を取得
ラウンド4 - 深掘り
- コミット履歴を分析してタイムラインを作成
- Issue/PRをレビューして機能の進化を把握
- コントリビューターの活動を確認
レポート構成
assets/report_template.md のテンプレートに従ってください:
- メタデータブロック - 日付、信頼度、主題
- エグゼクティブサマリー - 主要メトリクスを含む2～3文の概要
- 時系列タイムライン - 日付付きの段階別内訳
- 主要分析セクション - トピック別の詳細調査
- メトリクスと比較 - 表、成長チャート
- 長所と短所 - バランスの取れた評価
- 情報源 - カテゴリ別の参照リスト
- 信頼度評価 - 信頼度レベル別の主張
- 方法論 - 使用した調査アプローチ
Mermaid図表
役立つ場合は図表を含めてください:
タイムライン (ガントチャート) :
gantt
title プロジェクトタイムライン
dateFormat YYYY-MM-DD
section フェーズ1
開発 :2025-01-01, 2025-03-01
section フェーズ2
リリース :2025-03-01, 2025-04-01
アーキテクチャ (フローチャート) :
flowchart TD
A[ユーザー] --> B[コーディネーター]
B --> C[プランナー]
C --> D[調査チーム]
D --> E[レポーター]
比較 (円グラフ/棒グラフ) :
pie title 市場シェア
"プロジェクトA" : 45
"プロジェクトB" : 30
"その他" : 25
信頼度スコアリング
情報源の品質に基づいて信頼度を割り当てます:
| 信頼度 | 基準 |
|---|---|
| 高 (90%以上) | 公式ドキュメント、GitHubデータ、複数の裏付けのある情報源 |
| 中 (70～89%) | 単一の信頼できる情報源、最近の記事 |
| 低 (50～69%) | ソーシャルメディア、未確認の主張、古い情報 |
出力
レポートを research_{topic}_{YYYYMMDD}.md として保存します。
フォーマットルール
- 日本語コンテンツ: 全角の句読点（、 。： ；！？）を使用
- 技術用語: 初出時にWiki/ドキュメントURLを記載
- 表: メトリクス、比較に使用
- コードブロック: 技術的な例に使用
- Mermaid図表: アーキテクチャ、タイムライン、フローに使用
ベストプラクティス
- 公式情報源から始める - リポジトリ、ドキュメント、企業ブログ
- コミット/PRから日付を検証する - 記事よりも信頼性が高い
- 主張を三角測量する - 2つ以上の独立した情報源
- 矛盾する情報を記載する - 矛盾を隠さない
- 事実と意見を区別する - 推測は明確にラベル付けする
- 重要: 常にインライン引用を含める - 外部情報源からの各主張の直後に
[citation:Title](https://raw.githubusercontent.com/bytedance/deer-flow/main/URL)形式を使用 - 検索結果からURLを抽出する - web_searchは{title, url, snippet}を返すため、常にurlフィールドを使用
- 進捗に応じて更新する - 最後まで待ってから統合しない
引用例
良い例 - インライン引用あり:
このプロジェクトはリリースから3か月以内に10,000スターを獲得しました [citation:GitHub統計](https://github.com/owner/repo)。
アーキテクチャはワークフローオーケストレーションにLangGraphを使用しています [citation:LangGraph Docs](https://langchain.com/langgraph)。
悪い例 - 引用なし:
このプロジェクトはリリースから3か月以内に10,000スターを獲得しました。
アーキテクチャはワークフローオーケストレーションにLangGraphを使用しています。