github-profile-analyzer: a deterministic scorer for GitHub profiles

Fourteen categories and 43 sampled rules

The project scores a GitHub profile without asking a language model to describe it. The project page presents it as a deterministic analyzer that works across 14 weighted categories, and the same page states that 43 sampled rules evaluate account age, contribution patterns, repository quality, release discipline, security posture and community health. Underneath sit 38 baseline metrics, from GPG signature ratio to release cadence, plus 45 anomaly signals covering burst contributions, self-merge ratios, fork abandonment and commit monotony. That is the central design decision. Most profilers either dump raw numbers with no context, or wrap a model in a prompt and accept whatever narrative comes back. Here the weights are published, the same profile always produces the same score, and the result is meant to be comparable across people and across time.

One deep-dive pass, roughly 30 GitHub API requests

The collection layer is organised around a single pass rather than a long crawl. A batched GraphQL query loads the profile core: contribution calendar, social graph, gists, pinned items and two years of contribution history. Repository discovery then runs through paginated GraphQL, and the top repositories are enriched in batches of four with languages, releases, community files, dependency manifests, CI status and per-commit statistics including additions, deletions and signature validity. Weekly activity, punch cards, participation splits, contributor rankings and churn series are derived from data already fetched instead of costing extra REST calls. Search aggregators compute global counters such as external pull request acceptance rate, discussion answers and issue resonance in a single request. Community health profiles and Actions run histories then add documentation coverage and live CI pass rates for the top five repositories.

Rules that report themselves as unavailable

The part that separates this from a scoring toy is the refusal to guess. The documentation says rules that cannot be computed truthfully from public data, naming branch protection and follower history as examples, report themselves as unavailable rather than producing a number. Anomaly signals carry sampling caveats and confidence ratings, and are framed as context rather than verdicts, with burst patterns and self-merge ratios presented as things to look into, not accusations of misconduct. Every metric also carries a sampling window and a data-source label, and low scores come with remediation hints attached. If you intend to use the output to judge a person, that distinction matters: a profile that scores poorly because a rule was unavailable is a different case from one that scores poorly because the behaviour was present.

Cloning the repo and starting the dev server on Node.js 22

Setup is short but it is not a single-package install. The listed prerequisites are Node.js 22 and up with npm, a GitHub OAuth application with a client id and secret, personal access tokens for the analysis pool, a Neon PostgreSQL database and an Upstash Redis instance. Clone and install like this:

git clone https://github.com/0xarchit/github-profile-analyzer.git
cd github-profile-analyzer
npm install

Once the environment file is filled in, the development server comes up on port 3000:

npm run dev

The test suite runs through Vitest, and the production path is a build followed by a start:

npm run test

npm run build
npm run start

A separate smoke script exists with a quick and a standard variant, so you can check that a deployment actually reaches GitHub before trusting a report.

The environment file is the real specification

Configuration lives in a `.env.local` file, and the variable list is the practical spec of the project. `GITHUB_TOKENS` holds a comma-separated pool used for analysis, with `GITHUB_PAT_TOKENS` available as an optional secondary pool. `DATABASE_WRITE` is the Neon PostgreSQL connection string, `GITHUB_CLIENT_ID` and `GITHUB_CLIENT_SECRET` are the OAuth application credentials, `JWT_SECRET` signs sessions, `ENCRYPTION_SECRET` is the AES-256-GCM key, `UPSTASH_URL` and `UPSTASH_TOKEN` back caching and rate limiting, and `NEXT_PUBLIC_APP_URL` is the public base URL of the deployment. The platform layer matters as much as the scoring layer: GitHub OAuth login with verified-star guest access, server-side rate limiting and encrypted session handling, snapshot history with side-by-side comparison, and PDF report export. One design decision deserves a flag. The package manifest is marked private and named gitscore, so there is no published npm package to depend on. You run this from source or you deploy it.

SSE streaming next to a plain JSON endpoint

The API surface exposes both a streaming and a non-streaming path for the same deterministic engine, which tells you the project expects long waits. `GET /api/analyze/deterministic/stream` runs the engine with Server-Sent Events progress streaming, and `GET /api/analyze/deterministic` runs it and returns JSON. The project page says all results stream to the dashboard over SSE so each phase can be watched as it completes. The rest of the lifecycle is covered too: `GET /api/contributions` fetches contribution data, `GET /api/scans/[id]` retrieves a stored scan, `GET /api/star-status` verifies repository-star access, and `POST /api/auth/github` with `GET /api/auth/github/callback` drive the OAuth handshake, alongside `GET /api/auth/me` and `POST /api/auth/logout` for session identity and termination. There is also a `POST /api/analyze` route labelled legacy AI-assisted analysis, which is a fair signal about where the project has moved.

Where a fixed rule set beats a generated summary

The comparison worth making is with LLM-assisted profile summaries, and the difference is architectural rather than cosmetic. A generated summary is a sample: it can sound different for the same profile, it can over-claim from sparse data, and two people reading two runs get two different verdicts. The deterministic engine trades expressiveness for repeatability, computing each factor, exposing points earned against points possible, and publishing the weights so a score can be argued with rather than merely read. The cost of that choice is that a rule either has a computable public signal or it reports as unavailable, so the tool will refuse to assess things like branch protection. Deployment is heavier than a script as well: Next.js 16 with React 19, Neon serverless PostgreSQL, Upstash Redis, JWT sessions through jose, react-pdf for export, Tailwind CSS v4, Zod validation and Vitest testing, deployed to Cloudflare Workers through the OpenNext adapter, with a `migrations/` directory and `wrangler.jsonc` in the tree.

What to check before you trust a number

Two things decide whether this tool is useful to you. The first is coverage. The scoring reads the first 100 repositories, and the project description says it only includes forks where the user has contributions, to avoid fake results. Profiles with more than 100 repositories, or with heavy activity outside the sampled window, are being judged on a slice. The second is the sampling caveat attached to every metric, which is the only way to know whether a low score reflects behaviour or missing data. The project is not archived, and the last push was on 2026-10-02. It carries an MIT licence, and the repository publishes no GitHub releases, so there is no tagged version to pin and no changelog to read before upgrading. For a self-hosted analysis service, that matters: you take the main branch as it stands.

Editorial conclusion

Adopt github-profile-analyzer when you need the same profile to score the same way twice, and when you can supply a GitHub OAuth app, a Neon database, Upstash Redis and a token pool. Skip it for a quick one-off read, because the deterministic engine sits behind a full Next.js deployment with OAuth, session encryption and rate limiting. Before committing, confirm that GITHUB_TOKENS, DATABASE_WRITE, JWT_SECRET, ENCRYPTION_SECRET, UPSTASH_URL and UPSTASH_TOKEN are all populated, since a missing service breaks the run instead of degrading to a partial report.

Frequently asked questions

Official sources

1. 0xarchit/github-profile-analyzer on GitHub
2. Issues
3. License: MIT
4. Project website
5. README