Code quality checker: score a whole repo from its GitHub link

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. clean·vibes scores exactly these six categories, each starting at 100 and losing points per finding by severity, combined into one weighted 0–100 score.

A linter (ESLint, Ruff, and friends) checks one file at a time against style and syntax rules — 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 clean·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 producing a score, a ranked findings list, and a fix for each.

Paste the GitHub link. clean·vibes fetches the same public archive anyone can download — no OAuth, nothing written to disk — and returns a 0–100 score 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, via sign in with GitHub.

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.