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.