Code Health with Repowise
Repowise scores every file 1–10 from deterministic markers — McCabe
complexity, deep nesting, brain methods, class cohesion (LCOM4), god classes,
clone detection, untested hotspots, function-level churn, ownership dispersion,
and more. Zero LLM calls; pure local analysis. The weights are calibrated
against a real defect corpus, so a low score means more likely to harbour bugs,
not just bigger.
Pick the mode by what you pass
- Dashboard —
get_health() (no targets): a directive naming what to fix
first, then repo-level KPIs and the lowest-scoring files. Start here for "how
healthy is this codebase?" or "what should we clean up?".
- Targeted —
get_health(targets=["src/x.py", "src/y.py"]): per-file score
and the specific marker findings driving it. Use before/after a refactor,
or to explain why a file is flagged.
Useful include flags
get_health(targets=[...], include=[...]):
"biomarkers" — always return the findings list (what's wrong, where).
"refactoring" — deterministic, ranked refactoring suggestions (by impact/effort).
"coverage" — surface coverage data when it's been ingested.
"trend" — recent health snapshots + declining / predicted-decline signal.
include adds blocks; only=[...] subtracts them.
How to use the results
- For "what should I refactor?" → dashboard mode, lead with
directive, then
get_health(targets=[worst files], include=["refactoring"]) and present the
ranked plans, not just the scores.
- Rank by
weighted_deficit, not score — the score floors at 1.0.
- For a specific file → report the score, the top 2–3 marker findings, and
what each one means in plain language. Avoid dumping the raw payload.
- Check
unresolved before calling a file clean: a target listed there matched
nothing, and not_indexed means run repowise update.
- Before editing a flagged file → cross-check
get_risk(targets=[...]); a file
that is both low-health and a churn hotspot deserves the most care.
- Untested-hotspot / coverage questions → tell the user coverage markers
light up once they ingest a report:
repowise coverage add cov.lcov
(LCOV / Cobertura / Clover; a coverage.py .coverage also builds the
per-test map), then re-run repowise health.
CLI equivalents
repowise health — KPIs + lowest-scoring files
repowise health --refactoring-targets — ranked by impact / effort
repowise health --trend — snapshots + declining alerts
repowise coverage add <file> — ingest coverage, light up untested-hotspot
Error handling
If get_health reports no repository, suggest /repowise:init. Code health is
computed even with a template-rendered wiki (no LLM needed), so it should be available
whenever the repo is indexed.
1---2name: code-health-23description: Use when the user asks about code health, code quality, complexity, technical debt, which files are risky or hard to maintain, what to refactor next, untested hotspots, or coverage gaps in a Repowise-indexed codebase (.repowise/ directory exists). Also use to get a before/after health read when planning or finishing a refactor.4---56# Code Health with Repowise78Repowise scores **every file 1–10** from deterministic markers — McCabe9complexity, deep nesting, brain methods, class cohesion (LCOM4), god classes,10clone detection, untested hotspots, function-level churn, ownership dispersion,11and more. Zero LLM calls; pure local analysis. The weights are calibrated12against a real defect corpus, so a low score means *more likely to harbour bugs*,13not just *bigger*.1415## Pick the mode by what you pass1617- **Dashboard** — `get_health()` (no targets): a `directive` naming what to fix18 first, then repo-level KPIs and the lowest-scoring files. Start here for "how19 healthy is this codebase?" or "what should we clean up?".20- **Targeted** — `get_health(targets=["src/x.py", "src/y.py"])`: per-file score21 and the specific marker findings driving it. Use before/after a refactor,22 or to explain *why* a file is flagged.2324## Useful `include` flags2526`get_health(targets=[...], include=[...])`:27- `"biomarkers"` — always return the findings list (what's wrong, where).28- `"refactoring"` — deterministic, ranked refactoring suggestions (by impact/effort).29- `"coverage"` — surface coverage data when it's been ingested.30- `"trend"` — recent health snapshots + declining / predicted-decline signal.3132`include` adds blocks; `only=[...]` subtracts them.3334## How to use the results35361. For "what should I refactor?" → dashboard mode, lead with `directive`, then37 `get_health(targets=[worst files], include=["refactoring"])` and present the38 ranked plans, not just the scores.392. Rank by `weighted_deficit`, not `score` — the score floors at 1.0.403. For a specific file → report the score, the top 2–3 marker findings, and41 what each one means in plain language. Avoid dumping the raw payload.424. Check `unresolved` before calling a file clean: a target listed there matched43 nothing, and `not_indexed` means run `repowise update`.445. Before editing a flagged file → cross-check `get_risk(targets=[...])`; a file45 that is both low-health *and* a churn hotspot deserves the most care.466. Untested-hotspot / coverage questions → tell the user coverage markers47 light up once they ingest a report: `repowise coverage add cov.lcov`48 (LCOV / Cobertura / Clover; a coverage.py `.coverage` also builds the49 per-test map), then re-run `repowise health`.5051## CLI equivalents5253- `repowise health` — KPIs + lowest-scoring files54- `repowise health --refactoring-targets` — ranked by impact / effort55- `repowise health --trend` — snapshots + declining alerts56- `repowise coverage add <file>` — ingest coverage, light up untested-hotspot5758## Error handling5960If `get_health` reports no repository, suggest `/repowise:init`. Code health is61computed even with a template-rendered wiki (no LLM needed), so it should be available62whenever the repo is indexed.