Github Deep Research

GitHub Deep Research Skill

Multi-round research combining GitHub API, search_web, fetch_page to produce comprehensive markdown reports.

Research Workflow

For focused source questions, skip repository statistics and broad web discovery. Read the relevant directory and documentation first, batch independent file reads, and answer as soon as the requested facts have evidence. tree reads only the directory in path; use page/next_page for its entries. file returns numbered lines and next_line; pass that value as start_line for the next window. A line_truncated=true line is incomplete evidence and must be labelled as such. Content operations (file, readme, tree) require an explicit ref; never omit it or silently switch the user's commit to the default branch. For long files, use a literal query to locate the relevant passage before paging further.

• Round 1: GitHub API
• Round 2: Discovery
• Round 3: Deep Investigation
• Round 4: Deep Dive

Core Methodology

Query Strategy

Broad to Narrow: Start with GitHub API, then general queries, refine based on findings.

Copy code
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}"

Source Prioritization:

1. Official docs/repos (highest weight)
2. Technical blogs (Medium, Dev.to)
3. News articles (verified outlets)
4. Community discussions (Reddit, HN)
5. Social media (lowest weight, for sentiment)

Research Rounds

Round 1 - GitHub API Call the authorized github_query tool. The bundled scripts/github_api.py is retained as upstream reference, not executed in the sandbox:

textCopy code
github_query(owner="<owner>", repo="<repo>", operation="summary")
github_query(owner="<owner>", repo="<repo>", operation="readme", ref="<commit-sha-or-explicit-ref>")
github_query(owner="<owner>", repo="<repo>", operation="tree", ref="<commit-sha-or-explicit-ref>")

Available operations:

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

Also use file with path to read source files, or tags. Lists accept page and per_page; follow next_page until null within the tool limits. truncated=true means the sample is not exhaustive. Contributor observations are not a total count. Only public repositories are supported; never request tokens from the user or run the bundled script to bypass a denied operation. Treat the returned evidence path as an audit pointer only; do not pass it to read_file or execute. For source claims, call file with the exact immutable commit in ref, then cite the returned GitHub URL and line range.

Round 2 - Discovery (3-5 search_web)

• Get overview and identify key terms
• Find official website/repo
• Identify main players/competitors

Round 3 - Deep Investigation (5-10 search_web + fetch_page)

• Technical architecture details
• Timeline of key events
• Community sentiment
• Use fetch_page on valuable URLs for full content

Round 4 - Deep Dive

• Analyze commit history for timeline
• Review issues/PRs for feature evolution
• Check contributor activity

Report Structure

Follow template in assets/report_template.md:

1. Metadata Block - Date, confidence level, subject
2. Executive Summary - 2-3 sentence overview with key metrics
3. Chronological Timeline - Phased breakdown with dates
4. Key Analysis Sections - Topic-specific deep dives
5. Metrics & Comparisons - Tables, growth charts
6. Strengths & Weaknesses - Balanced assessment
7. Sources - Categorized references
8. Confidence Assessment - Claims by confidence level
9. Methodology - Research approach used

Mermaid Diagrams

Include diagrams where helpful:

Timeline (Gantt):

Architecture (Flowchart):

Comparison (Pie/Bar):

Confidence Scoring

Assign confidence based on source quality:

Output

Save report as: research_{topic}_{YYYYMMDD}.md

Formatting Rules

• Chinese content: Use full-width punctuation（，。：；！？）
• Technical terms: Provide Wiki/doc URL on first mention
• Tables: Use for metrics, comparisons
• Code blocks: For technical examples
• Mermaid: For architecture, timelines, flows

Best Practices

1. Start with official sources - Repo, docs, company blog
2. Verify dates from commits/PRs - More reliable than articles
3. Triangulate claims - 2+ independent sources
4. Note conflicting info - Don't hide contradictions
5. Distinguish fact vs opinion - Label speculation clearly
6. CRITICAL: Always include inline citations - Use [citation:Title](URL) format immediately after each claim from external sources
7. Extract URLs from search results - search_web returns {title, url, snippet} - always use the URL field
8. Update as you go - Don't wait until end to synthesize

Citation Examples

Good - With inline citations:

markdownCopy code
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).

Bad - Without citations:

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