GitHub Deep Research Skill

GitHubAPI、web_search、web_fetch を組み合わせた複数ラウンドのリサーチで、包括的なマークダウンレポートを生成します。

リサーチワークフロー

• ラウンド1：GitHub API
• ラウンド2：Discovery（発見）
• ラウンド3：Deep Investigation（深掘り調査）
• ラウンド4：Deep Dive（詳細分析）

コア手法論

クエリ戦略

広から狭へ：GitHub APIから始めて、一般的なクエリを実行し、発見に基づいて絞り込みます。

ラウンド1：GitHub API
ラウンド2："{topic} overview"
ラウンド3："{topic} architecture", "{topic} vs alternatives"
ラウンド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

ラウンド2 - Discovery（3～5回の web_search）

• 概要を取得してキーワードを特定
• 公式ウェブサイト/リポジトリを検索
• 主要プレイヤー/競合他社を特定

ラウンド3 - Deep Investigation（5～10回の web_search + web_fetch）

• テクニカルアーキテクチャの詳細
• 重要なイベントのタイムライン
• コミュニティセンチメント
• 価値のあるURLに対して web_fetch を使用して全文コンテンツを取得

ラウンド4 - Deep Dive

• コミット履歴を分析してタイムラインを作成
• Issues/PRs をレビューして機能進化を確認
• 貢献者アクティビティをチェック

レポート構造

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/doc URL を記載
• テーブル：メトリクス、比較に使用
• コードブロック：技術的な例のために使用
• Mermaid：アーキテクチャ、タイムライン、フロー用

ベストプラクティス

1. 公式ソースから開始 - リポジトリ、ドキュメント、企業ブログ
2. コミット/PR から日付を検証 - 記事よりも信頼性が高い
3. クレームを三角測量 - 2 つ以上の独立したソース
4. 矛盾する情報に注記 - 矛盾を隠さない
5. 事実と意見を区別 - 推測は明確にラベル付け
6. 重要：常にインライン引用を含める - 外部ソースからのクレーム直後に [citation:タイトル](URL) 形式を使用
7. 検索結果から URL を抽出 - web_search は {title, url, snippet} を返す - 常に URL フィールドを使用
8. 随時更新 - 最後に統合するまで待たない

引用例

良い例 - インライン引用付き：

プロジェクトはローンチ後3ヶ月で10,000スターを獲得した [citation:GitHub Stats](https://github.com/owner/repo)。
アーキテクチャはワークフロー編成に LangGraph を使用している [citation:LangGraph Docs](https://langchain.com/langgraph)。

悪い例 - 引用なし：

プロジェクトはローンチ後3ヶ月で10,000スターを獲得した。
アーキテクチャはワークフロー編成に LangGraph を使用している。