Code Health Score: Repowise Puts Numbers on Your Repo’s Technical Debt
We mentioned Repowise in passing when we covered the knowledge graphs trend for code — it showed up as one more in a list of five. It deserves better than that. Repowise isn’t just another tool that builds a graph on your repo. It’s the only one from that list making a claim the others don’t even attempt: that it can score your code 1 to 10 and that score actually predicts where bugs will show up.
It’s worth taking a closer look.
What Repowise actually is
pip install repowise, run repowise init on your project, and it builds five things at once:
- Graph — dependency graph via tree-sitter across 15 languages, call resolution, PageRank/centrality
- Git — hotspots (churn × complexity), % ownership, hidden coupling via co-change pairs, bus factor
- Docs — an LLM-generated wiki per module, regenerated incrementally on each commit
- Decisions — architectural decision records mined from eight sources, tagged as verified/fuzzy/unverified
- Code Health — 25 deterministic biomarkers, zero LLM calls, under 30 seconds on a 3,000-file repo
Then it exposes all of that to Claude Code, Codex, or any MCP client through nine tools. That part—graph, git, docs, decisions—is spiritually pretty similar to what we’ve already seen with codebase-memory-mcp and Context7. The Code Health layer is where Repowise is doing something nobody else in that space is doing.
The part that’s actually new: a score validated against real defects
Most “code quality score” tools—and there are many—hand-tune their weights based on what seems reasonable. Repowise’s proposal is different: the weights behind its 25 biomarkers (McCabe complexity, deep nesting, brain methods, LCOM4 cohesion, god classes, clone detection, untested hotspots, churn, ownership dispersion, and more) are calibrated against a real historical corpus of defects, not hand-picked.
To be clear about what this means: it’s Repowise’s own benchmark, published in their repowise-bench repo with methodology and confidence intervals included—not a third-party independent audit. It’s worth testing on your own repo before taking the numbers as revealed truth, but at least the methodology is transparent enough to review.
This is what they report, measured across the same 2,770 files in 9 languages, at the same commit, against the same defect labels, compared head-to-head against a “leading commercial tool” they don’t name:
| Metric (paired tests) | Repowise | Commercial Tool |
|---|---|---|
| Recall @ 20% of line budget | 0.173 | 0.074 |
| Effort-aware ranking (Popt) | 0.607 | 0.462 |
| Defect density (Alert:Healthy ratio) | 2.18× | 0.56× |
| Discrimination (ROC AUC) | 0.731 | 0.705 |
Separately, across 21 open-source repos covering the nine “Full tier” languages, they report a mean cross-project ROC AUC of 0.74 (95% CI: 0.68–0.79) for identifying which files end up receiving bug fixes in the following six months—no data leakage, since the health scores are locked in at a historical commit and results measured afterward. They also report the score holds up when controlling for file size (it’s not just “flag the biggest files”) and it holds on an external published dataset (PROMISE/jEdit) it was never tuned on.
Self-reported, yes. But it’s the kind of self-reported claim that comes with a methodology document attached, which already puts it a notch above typical marketing graphics.
Getting it running
pip install repowise # or: uv tool install repowise
cd your-project
repowise init # builds the five layers — one time
repowise serve # spins up the MCP server + local dashboard
The graph, git, dead-code, and health layers build in minutes with no LLM calls—with repowise init --index-only you get a queryable index almost instantly. The only slow part is the docs generation layer, which you can leave running in the background. After the initial index, each commit-triggered update takes under 30 seconds.
If you’re specifically working with Claude Code, you can skip the manual setup:
/plugin marketplace add repowise-dev/repowise
/plugin install repowise@repowise
That registers the MCP server, installs the hook, and adds the slash commands /repowise:* (init, health, risk, dead-code, decision, …).
For the health score specifically, once indexed:
repowise health # KPIs + worst-scoring files
repowise health --coverage cov.lcov # ingest LCOV/Coverage/Clover → untested-hotspots detection
repowise health --refactoring-targets # ranking by impact/effort
repowise health --trend # snapshots + alerts for decline/predicted decline
The nine MCP tools
Most code tools for MCP are built around individual entities—a file, a symbol—which forces your agent to chain a dozen calls. Repowise’s tools are built around tasks: you pass multiple targets and get complete context in a single round-trip.
| Tool | What it does |
|---|---|
get_overview() |
Architecture summary, module map, entry points — the first call on any unfamiliar repo |
get_answer(question) |
Hybrid retrieval + graph expansion → a cited answer with confidence score |
get_context(targets, include?) |
Context card per file/module/symbol — batch multiple targets at once |
get_symbol("file.py::Name") |
Raw source code of a symbol, with exact line boundaries |
search_codebase(query, kind?) |
Semantic search filterable by implementation/test/config/doc |
get_risk(targets, changed_files?) |
Hotspot scores, dependents, co-change partners — with PR mode included |
get_why(query?, targets?) |
Architectural decision records + supersession chain |
get_dead_code(...) |
Unreachable code by confidence level |
get_health(targets?, include?) |
The 25-biomarker score, per file or at dashboard level |
Their reference example—adding rate limiting to all API endpoints—claims 5 tool calls instead of about 30 greps-and-reads. That aligns with the general pattern of “structured index beats file-by-file exploration” we’re seeing in nearly all these tools, including the ~70% reduction in tool calls and ~89% fewer file reads that Repowise reports in its own agent efficiency benchmarks.
How it stacks up against alternatives
Repowise is self-hostable (AGPL-3.0), doesn’t need cloud, and is BYOK for any LLM calls it does make (docs generation). Compared to DeepWiki, Swimm, and CodeScene—the closest comparison points—it’s the only one combining behavioral intelligence via git, a health score validated against defects, auto-generated docs, MCP-native tools, and architectural decision tracking in a single self-hosted package. CodeScene is the closest analog on the health-score side, but it’s not MCP-native and doesn’t do architectural decisions or auto-generated docs.
There’s also a hosted version (repowise.dev) for teams that don’t want to run it themselves, plus a free GitHub PR bot that comments on hotspots and health decline per PR with no LLM calls.
Is it worth it?
If you’re already convinced by the “give your agent a persistent map instead of making it re-explore your repo every session” proposal we saw with codebase-memory-mcp, Repowise does the same and adds a genuinely differentiated layer on top — one that tries to answer “which files will actually break” instead of just “which files are related”. That’s a harder claim to sustain and harder to fake. It’s worth pointing it at your own repo and comparing the files with the worst repowise health scores against your last six months of bug fix commits — that’s the proof that really matters here, more than any graph in their README.
Have you already tried it on your own repo, or are you sticking with the pure knowledge graph for now? Let us know how well the health score predicted your actual pain points 