awesome-skills/github-repo-insights

GitHub Repo Insights

Collect current GitHub data first, then separate observed facts from interpretation. Do not reuse traffic numbers from an older conversation when live access is available.

Collect a snapshot

Run the bundled collector from this skill directory:

python3 scripts/collect_github_repo_insights.py OWNER/REPO --output /tmp/github-repo-insights.json

Require Python 3.10+ and an authenticated GitHub CLI (gh auth status).

Omit OWNER/REPO inside a local checkout to detect it with gh repo view.

The script uses authenticated gh access and collects:

• repository metadata and current stars, forks, watchers, issues, and latest release;
• the rolling 14-day views and unique visitors;
• the rolling 14-day clones and unique cloners;
• popular referrers and popular repository paths;
• recent daily star events through GitHub GraphQL;
• recent-seven-day versus previous-seven-day count comparisons.

Traffic endpoints require push access. Preserve access.traffic.status: "unavailable" as unavailable; never report it as zero. Public metadata and star momentum can still be analyzed.

Read references/metrics.md before interpreting traffic, attribution, conversion proxies, or missing data.

Analyze in this order

1. Reach: Report 14-day views and unique visitors with the exact window and source.
2. Usage intent: Report clones and unique cloners separately from views.
3. Momentum: Compare the latest seven daily counts with the previous seven for views, clones, and stars. Name the peak dates.
4. Acquisition: Rank referrers. Distinguish GitHub-internal, search, social, community, and direct/unknown traffic.
5. Content demand: Explain which README, docs, releases, issues, or other paths received attention.
6. Context: Connect releases, README changes, Trending appearances, posts, or launches only when dates align and evidence exists.
7. Next action: Recommend one or two changes tied to the observed bottleneck, such as onboarding, localization, release packaging, search capture, or community follow-up.

Reporting rules

• Lead with the growth conclusion, then show the evidence.
• State that traffic data comes from GitHub's repository Traffic API and covers a rolling 14-day window.
• Never sum daily unique visitor or unique cloner values; GitHub's top-level unique count is the valid window total.
• Treat stars-per-view and clones-per-view only as directional ratios, not user conversion rates.
• Do not claim a referrer caused growth merely because dates overlap. Label causal explanations as inference.
• Separate unavailable, zero, and incomplete data.
• Compare publish dates with event dates when discussing launches, Trending, releases, or community posts.
• Avoid vanity-only summaries. Explain what changed, why it likely changed, and what to do next.

Default output

Use this compact structure unless the user requests a dashboard or historical report:

## Current momentum
One-sentence conclusion.

- 14-day views / unique visitors
- 14-day clones / unique cloners
- recent 7d vs previous 7d views, clones, and stars
- peak dates

## Where attention comes from
Ranked referrers and what they imply.

## What people inspect
Popular paths and onboarding/content implications.

## Interpretation
Proven facts, explicit inference, and important limitations.

## Next move
One or two evidence-linked actions.

For recurring monitoring, save each JSON snapshot outside the skill directory with an ISO-date filename. GitHub does not provide long-term Traffic history after the rolling window expires.