What a code quality checker measures (and what it doesn't)
Quality here means maintainability, not correctness. A code quality checker looks at the shape of the code: how big the files and functions are, how deeply nested the logic gets, whether the same block is copy-pasted across files, whether dead and commented-out code is piling up, whether naming and conventions are consistent, and whether the repo has the basics: a README, a .gitignore, a lockfile. None of that changes whether the app runs today; all of it changes how hard tomorrow's change will be.
It is not a bug finder and not a test runner. A checker won't tell you the app is broken. It tells you the app is expensive to change, which is the problem that shows up three months in when a "quick" edit touches six duplicated copies. quality·vibes scores exactly these six categories, each starting at 100 and losing points per finding by severity, combined into one weighted score out of 100.
Whole-repo checker vs. a linter
A linter (ESLint, Ruff, and friends) checks one file at a time against style and syntax rules. It's invaluable and you should run one, but it can't see the repo. Cross-file duplication, a module nobody imports anymore, a codebase that's inconsistent between its old half and its new half: these only exist at the whole-repo level, and a per-file linter is blind to them by design.
A whole-repo code quality checker reads the codebase as one thing. That's the level where maintainability actually lives, and it's what quality·vibes scores: it streams the repo archive in memory, runs deterministic heuristics across the whole tree, then adds a Claude review pass that reads for the judgment calls rules miss. The two together produce a score, a ranked findings list, and a fix for each.
How to check a repo's quality in under a minute
Paste the GitHub link. quality·vibes fetches the same public archive anyone can download (nothing written to disk) and returns a score out of 100 with a letter grade (A ≥90 down to F), the six category subscores so you can see whether the problem is structure or duplication or hygiene, and every finding with its file, line, and a one-paste Claude prompt to fix it. Private repos work too, by installing the GitHub App on the repositories you pick.
The score is the summary; the subscores are the diagnosis. A repo scoring 78 with structure at 45 and everything else near 100 has one specific, fixable problem, oversized files, not a vague "needs cleanup." That's the difference between a checker that grades you and one that tells you what to do next.
how it works
- 01
Paste a GitHub link
Public repos need nothing but the URL; private repos work by installing the GitHub App on the repositories you choose, which reads their contents and can write nothing. The archive is streamed in memory, never written to disk.
- 02
Read the overall score
Scored out of 100 with a letter grade (A ≥90, B ≥80, C ≥65, D ≥50, F below), the one-number summary of maintainability.
- 03
Use the six subscores as a diagnosis
Structure, readability, duplication, dead code, consistency, hygiene. The low bar tells you what kind of mess it is, not just that there is one.
- 04
Work the findings list
Each issue comes with a file, line, why it matters, and a ready-to-paste Claude prompt with behaviour-preserving constraints.
- 05
Re-check to confirm
Fix, re-scan, watch the score move. The free tier covers about five scans a month.
frequently asked
Is a code quality checker the same as a linter?
No. A linter checks one file at a time for style and syntax; a code quality checker reads the whole repo for maintainability: cross-file duplication, dead modules, oversized files, inconsistency. Run both: the linter for per-file rules, the checker for the repo-level picture.
Does it check quality or find bugs?
Quality, meaning how maintainable and clean the code is, not whether it's correct. It won't tell you the app is broken; it tells you the app is expensive to change, which is the problem tests don't catch.
Do I need to install anything?
No. quality·vibes runs from a GitHub link in the browser: paste the URL, get a scored report in under a minute. Nothing to install, nothing cloned to your machine, nothing written to disk on ours.
Can I check a repo I didn't write?
Yes, as long as it's public, which makes it useful for sizing up a codebase before you inherit it or a dependency before you adopt it. Paste the link and read the score and subscores.
Last updated July 16, 2026