| name | repo-velocity |
| description | Measure the development speed / velocity / activity of any GitHub repository using objective metrics from the GitHub API — commits, lines added/deleted, merged-PR throughput, active contributors, time-to-merge, and release cadence. Compares multiple repos side by side. |
| when_to_use | Use when someone wants an objective read on how fast a GitHub project is moving — "how active is repo X", "is this project still maintained", "compare the velocity of these repos", "how many lines/commits/PRs per week", evaluating a dependency's health, or benchmarking OSS projects against each other. |
| argument-hint | OWNER/REPO[@BRANCH] [more repos…] [--window-days N] [--branch B] [--json] |
| allowed-tools | Bash, Read |
| user-invocable | true |
| metadata | {"version":"1.5","author":"Ability.ai","changelog":["1.5: Per-contributor leverage metrics — LOC+ per contributor per week and commits per contributor per week, in the JSON, the single-repo table, and the comparison table (+Lines/dev/wk column). Same caveats as the inputs: contributor counts are sampled on busy repos, LOC is churn, and solo-repo per-capita numbers are trivially inflated — read alongside absolute volume.","1.4: Honest LOC — lines added/deleted now come from summing per-commit line stats on the measured branch (GraphQL history; merge commits excluded to avoid double-counting merged branches). The compare endpoint is GONE from the LOC path: GitHub silently caps compare diffs at ~300 files, so on any large window it summed an arbitrary file subset — verified: Trinity 90d showed net -6,015 via compare vs ground-truth +213,589 (base..head diff) / +311,877 (churn) from a local clone; the new method matches the clone's no-merge churn to the digit. Repos beyond 2,000 in-window commits are extrapolated from the most recent 2,000 commits' date span and flagged.","1.3: Branch-aware measurement — commits/lines/contributors are no longer blindly measured on the default branch. The tool enumerates ALL branch heads (paginated GraphQL; GitHub's TAG_COMMIT_DATE ref ordering is unreliable for branches — verified it buried an active `dev` below stale feature branches), batch-counts in-window commits on every active branch, and measures the busiest development line. Stable-branch preference (default/dev/release names win unless a feature branch is >10% busier) stops short-lived feature branches — which contain the dev line's whole history — from stealing the headline. The default branch's in-window count is always reported alongside; `owner/repo@branch` and `--branch` pin it explicitly. Repos that develop on dev and merge to main at release (e.g. Trinity: 811 commits/90d on dev vs 294 on main) are no longer ~3x undercounted.","1.2: Drop the LAST /stats dependency — commit counts now use the Link-header rel=last trick (one request, exact, no 202). This also fixed a silent accuracy bug: /stats/commit_activity was undercounting commits ~40% vs ground-truth enumeration (verified: fd 90d = 73 both methods). The tool now makes ZERO 202-prone calls — every metric returns on the first run.","1.1: Stop depending on GitHub's flaky /stats/* endpoints — /stats/contributors and /stats/code_frequency both 202 indefinitely on some repos. Lines added/deleted now come from the compare endpoint (net diff base..head); active contributors from the commits list.","1.0: Initial version — objective repo velocity via gh api (commits, lines ±, merged-PR throughput, contributors, time-to-merge, release cadence); single-repo report, multi-repo comparison, and --json modes"]} |
| category | research-and-analysis |
Repo Velocity
ℹ️ First, set expectations: before anything else, print one short line with this skill's version and its most recent change — the top entry of metadata.changelog above — e.g. repo-velocity vX.Y — recent: <summary>. Then proceed.
Purpose
Give an objective, reproducible measure of how fast a GitHub repository is being developed — the kind of question "which OSS project ships faster?" actually deserves. It reports the components of CHAOSS Project Velocity (commits, merged PRs, contributors) plus raw code throughput (lines added/deleted per week) and flow metrics (time-to-merge, release cadence), for one repo or several side by side.
All data comes through the GitHub CLI (gh api), so it inherits the user's existing gh authentication and rate limits — no tokens to configure, and every run computes identically. The heavy lifting lives in a deterministic Python script (stdlib only), not in ad-hoc API calls, so results are consistent across runs.
State Dependencies
| Source | Location | Read | Write |
|---|
| GitHub REST API | via gh api (repo meta, stats/*, search/issues, pulls, releases) | ✅ | — |
| Analysis engine | ~/.claude/skills/repo-velocity/scripts/repo_velocity.py | ✅ | — |
This skill is read-only — it never writes to any repo or to GitHub. It only emits a report to the conversation (and, with --json, machine-readable output).
Prerequisites
- GitHub CLI authenticated:
gh auth status should show a logged-in account. If not, tell the user to run gh auth login (do not attempt the interactive login yourself — suggest they type ! gh auth login).
- Python 3 (stdlib only — no pip installs).
Process
-
Parse the target(s) from the argument string. Accept any mix of , full URLs, or — the script normalizes all of these, so pass them through verbatim. An optional suffix () pins the measured branch; without it the script auto-detects the busiest development branch per repo. Pull out an optional (default 90), (pin one branch for all repos), and if the user asked for raw output.
