Methodology
The goal is not to pretend public GitHub is the whole truth. The goal is to make the visible surface more legible, comparable, and harder to misuse.
Optional private supplement
ShipSleuth defaults to public-only analysis, but users can optionally enter self-reported private activity — additional commits, PRs, repos, releases, active days, and lines changed — to produce a more complete picture. When supplemented:
Private supplement values are self-reported and not verified by ShipSleuth. They are meant to reduce the structural blind spot of private work, not to replace proper diligence. The analysis always indicates when private data has been included.
Calculator-first
Earlier drafts experimented with composite scoring and leaderboard-style presentation. ShipSleuth now prioritizes direct metrics and context to avoid false precision.
Percentile anchor calibration
When ShipSleuth says “Top ~0.1%” for a metric, it interpolates your value against a table of anchor thresholds derived from real GH Archive data. Here is how each one was derived.
Anchors are derived from GH Archive data queried via ClickHouse Playground (July 2026, covering the preceding 90 days). GH Archive captures all public GitHub events — pushes, PRs, releases, etc. — and ClickHouse provides free, zero-auth SQL access to the full dataset.
GitHub reports 100M+ total accounts (Octoverse 2023). Most are inactive. Querying GH Archive for distinct actors with at least 1 public PushEvent in the last 90 days yields ~8.7M accounts (8,677,027). Filtering out known bot/CI accounts (dependabot, renovate, github-actions, etc.) brings the human pool to ~8.6M — bots account for only ~0.4% of push-active accounts.
Last refreshed: 2026-07-21.
GH Archive counts PushEvents, not individual commits. Each push contains ~1-3 commits on average, so we apply a ×2 multiplier. Raw GH Archive percentiles (push events): P50=4, P90=28, P99=178, P99.99=12,793.
GH Archive PullRequestEvent(action=closed). Only 42,055 actors closed any public PRs in 90 days (~0.5% of pushers), so percentiles for this metric are within that cohort, not among all pushers — and the recorded actor is the account that closed the PR (often a maintainer), not necessarily its author. Cohort percentiles: P50=1, P90=2, P99=10, P99.99=2,796.
GH Archive count of PushEvent + PullRequestEvent + IssuesEvent + PullRequestReviewCommentEvent per actor over 365 days (~18.6M non-bot actors — a wider universe than the 8.7M pushers, since it includes accounts that only open issues or review). P50=5, P75=16, P90=47, P95=91, P99=340, P99.9=1,597, P99.99=14,829. ShipSleuth scrapes the in-window contribution count, so these 365-day thresholds are scaled to your analysis window before comparison. This is an event-count proxy for GitHub's contribution number, which counts individual commits rather than pushes. Last refreshed: 2026-07-21.
Not available in GH Archive. Estimated anchors are retained for reference but no percentile badge is shown for this metric since we cannot validate the thresholds against real population data. The raw metric value is still displayed.
GH Archive distinct repos per actor. P50=1, P75=2, P90=4, P95=5, P99=11, P99.99=264. Most devs push to just 1 repo. Maintaining 11+ active repos in 90 days puts you in the Top ~1%.
GH Archive ReleaseEvents. Only 88,682 actors published any releases in 90 days (~1% of active devs), so percentiles are within the publisher cohort. Among publishers: P50=1, P75=2, P90=3, P95=5, P99=15, P99.99=478.
GH Archive distinct push dates per actor. P50=2, P75=5, P90=11, P95=17, P99=41, P99.99=72. The median developer pushes on just 2 distinct days per quarter. Active days are capped at window length (72 days = Top ~0.01% for a 90-day window — shipping most weekdays all quarter).
GH Archive distinct pushers per repo owner, across ~8.6M owners with public push activity. Over 90% of owners have just 1 contributor (themselves). P99=4, P99.9=10, P99.99=44. Having 4+ distinct contributors puts an owner in the Top ~1%.
Your value is placed between the two nearest anchors. The percentile axis is interpolated in log-space (not linearly) because developer activity follows a power-law distribution — a small number of developers are orders of magnitude more active than the median. Log-interpolation respects this shape.
Thresholds are scaled from each metric's calibration window to your analysis window (most metrics are calibrated on 90 days; profile contributions on 365; commits/week is a rate and never scales). A 30-day window scales 90-day thresholds to 1/3. The effective window is clamped to 9–720 days: beyond ~2 years, contributor churn makes linear scaling unreliable, so longer windows are compared against 720-day thresholds and percentiles for 2y+ windows should be read as generous upper bounds. The percentile axis stays the same — “Top ~1%” always means Top ~1% of the stated cohort.
Overall score
The composite score is a weighted average of 7 log-scaled dimensions (volume 30%, breadth 19%, consistency 18%, releases 10%, recency 10%, collaboration 8%, concentration 5%). The score itself is then mapped to a percentile tier using a separate set of anchors calibrated against the expected score distribution. A score of 85+ maps to Top 1%; a score of 30 maps to Top 50%.
Transparency note: Unlike per-metric percentiles (which are derived directly from GH Archive population data), the overall score anchors are estimated based on the expected distribution of composite scores. There is no way to query GH Archive for a composite score that only exists inside ShipSleuth. The individual metrics feeding the score are well-calibrated, but the overall percentile mapping is an informed estimate, not a measurement.
Builder · AI usage methodology
Builder is the AI agent usage layer of the analyzer, folded into the main page rather than living at a separate URL. It tracks your own AI coding usage across Claude Code, Codex, Gemini CLI, and Cursor. The web page never reaches into your machine. Instead, a local CLI scans on-disk state, emits a JSON blob, and you paste it into the "Add your AI agent usage" section that appears below the analyzer form. The methodology below is the privacy contract that lets us do this honestly.
Each supported tool has its own adapter under src/lib/ai-usage/adapters/ that knows where the tool stores its state and which fields are safe to read. Every adapter returns the same UsageRecord shape and nothing else. The shape is enforced by a .strict()zod schema, which means any unknown key — a leaked prompt, a stray cwd, a session UUID — causes the record to be rejected before it ever leaves the CLI. The same schema runs again in the browser before the blob is stored.
The date field is validated as YYYY-MM-DD(UTC). Anything finer — hours, minutes, timezone-local times — fails schema validation. This is a deliberate guard against work-schedule inference from sub-day timestamps. The CLI takes each event's ISO timestamp, truncates to its UTC date, and aggregates from there.
Cursor stores chat history alongside usage metadata in SQLite at state.vscdb. The Cursor adapter unions two read-only sources via better-sqlite3. Source A globs User/workspaceStorage/*/state.vscdb for per-workspace databases and reads the legacy aiService.prompts and aiService.generations keys from each ItemTable. Source B opens the global User/globalStorage/state.vscdb and streams cursorDiskKV rows where the key matches bubbleId:% — this is where Cursor 0.43+ keeps current-format chat data, including per-call inputTokens/outputTokens. From every row the extractor pulls only the UTC day (from unixMs, createdAt, clientRpcSendTime, clientSettleTime, or clientEndTime), one of modelType / model / modelId / modelName / lastUsedModel (capped at 80 chars), and integer token counts. Every other column and JSON property — chat text, images, file paths, workspace names, conversation IDs — is discarded inside the extractor. The CLI is the only place that touches the file, and the strict schema is the second wall: even if the query were widened, the resulting object would be rejected before serialization.
The Builder section reads and writes a single localStorage key. The dashboard you see is rendered entirely from that key. Nothing is uploaded automatically, and there is no background telemetry. The one way Builder data leaves your browser is when you toggle AI agent metrics on the stats card and copy the share link: a trimmed copy of the aggregated stats (top 5 models, top 4 tools, last 30 daily entries) rides inside the URL itself, deflated and base64url-encoded under ?agent=v1.…. No server persists it — the URL is the data. To be honest about it, that URL ends up in the recipient's browser history, in Vercel's default request logs (no persistence beyond standard retention), and in any link-unfurler the recipient pastes it through. If that's uncomfortable for a given dashboard, leave the AI agent toggles off.
settings.json. Without it, the adapter detects the install but reports zero records.