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 /prompts: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-health3description: Use when the user asks about code health, code quality, complexity, technical debt, risky or hard-to-maintain files, what to refactor next, untested hotspots, or coverage gaps in a Repowise-indexed codebase (.repowise/ directory exists). Also use for before/after health reads 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 `/prompts:repowise-init`. Code health is61computed even with a template-rendered wiki (no LLM needed), so it should be available62whenever the repo is indexed.