Find where your developer experience breaks, before your users do.
A linter cannot tell you that pnpm build exits 1 on a clean clone. DX Score runs your documented setup in a sandbox and reports what happened, with the commands that prove it and a fix to hand your coding agent.
For maintainers, developer experience and platform teams, and anyone shipping a CLI, an SDK or an API.
Run it as a check, not a website
The gates are the part that belongs in CI. Five are decided in code from exit codes and timings alone; two more publish only when the code and the model agree, and read unverified when they do not. A fired gate is a fact you can block a merge on. The score is a summary of the run; the gate is the thing to act on.
The same checks ship as Agent Skills for Claude Code, so they run on your machine or your own runner: against a working tree you have not pushed, with no quota, no sign-in, and nothing leaving your infrastructure. Use the hosted audit when you want a shareable report with a transcript anyone can check.
Then ask Claude run developer-experience-auditor on this repo. Forty-three skills, all of them on GitHub.
On a pull request, run it against the head commit and fail the job when a gate fires. Run it on the paths that can break a quickstart — the README, the manifest, the lockfile — rather than on every push.
Error: Failed to fetch with no cause or request idOne audit gives you
Your quickstart has 15 minutes to work
We start from a clean clone with no credentials and follow your documented path exactly as written: install, build, the first example, and the check that proves it worked. Then one command we expect to fail, because how a tool explains an error is part of the experience.
Install, build and test have their own standard of 10 minutes. A run we cannot finish inside our own limits is reported as unverified with no score, never as a failure.
Nine weighted areas
Time to first value carries the most weight, then the API, then errors and recovery. The other six are CLI and configuration, documentation, SDK, local development, testing and quality, and release and compatibility. Weights re-normalise when an area does not apply, so a CLI with no HTTP API is not marked down for missing one.
We do not grade your claims. We test the experience.
Your CI runs these commands too, with your cache, your credentials, a toolchain it was configured with, and the commands your team wrote. We start from nothing and run only what your README tells a stranger to run. That is why every number here carries the class of evidence that produced it.
Some failures are not a deduction. A broken install, a build that does not reproduce, or a quickstart that never reaches a verified outcome fires a gate, and a fired gate is a FAIL whatever the number says. That is why the report leads with the transcript rather than the number.
What you do with a finding
How we run it
Commands run in a per-audit sandbox as an unprivileged user, with no credentials and no network beyond an allowlist of package registries and source hosts.
We clone and run. We never write to your repository and never open a pull request against it.
A public repository's report has a shareable URL, and one recent finding is shown on this page. Private reports are visible only to you.
GitHub's repo scope is the narrowest that can read a private one. We ask for it only when you point us at one, and the token never enters the sandbox.
Point it at a repository and read the transcript.