code-health
Repowise Code Health scores every file in a repository on a 1–10 scale using deterministic biomarkers including McCabe complexity, nesting depth, class cohesion, clone detection, and untested hotspots, without requiring LLM calls. Use dashboard mode to identify the lowest-scoring files needing refactoring across the entire codebase, or targeted mode with specific file paths to get detailed biomarker findings and ranked refactoring suggestions before or after code changes.
git clone --depth 1 https://github.com/repowise-dev/repowise /tmp/code-health && cp -r /tmp/code-health/plugins/claude-code/skills/code-health ~/.claude/skills/code-healthSKILL.md
# Code Health with Repowise Repowise scores **every file 1–10** from deterministic biomarkers — 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): repo-level KPIs plus 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 biomarker 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. ## How to use the results 1. For "what should I refactor?" → dashboard mode, then `get_health(targets=[worst files], include=["refactoring"])` and present the ranked suggestions, not just the scores. 2. For a specific file → report the score, the top 2–3 biomarker findings, and what each one means in plain language. Avoid dumping the raw payload. 3. 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. 4. Untested-hotspot / coverage questions → tell the user coverage biomarkers light up once they ingest a report: `repowise health --coverage cov.lcov` (LCOV / Cobertura / Clover). ## CLI equivalents - `repowise health` — KPIs + lowest-scoring files - `repowise health --refactoring-targets` — ranked by impact / effort - `repowise health --trend` — snapshots + declining alerts - `repowise health --coverage <file>` — ingest coverage, light up untested-hotspot ## Error handling If `get_health` reports no repository, suggest `/repowise:init`. Code health is computed even in index-only mode (no LLM needed), so it should be available whenever the repo is indexed.
Use when a task asks why code is built a certain way, proposes architectural changes, compares implementation approaches, or mentions decision markers such as WHY, DECISION, TRADEOFF, or ADR in a Repowise-indexed repository.
>
Use when exploring, understanding, or answering questions about a Repowise-indexed codebase, including architecture, where code is implemented, how a module works, or which files are relevant before reading source.
Use when the user asks about unused code, cleanup, deleting files or exports, refactoring old areas, reducing bundle size, code hygiene, technical debt, or maintenance in a Repowise-indexed repository.
Use before modifying, refactoring, moving, or deleting files in a Repowise-indexed repository, especially shared utilities, core modules, public APIs, or files the user did not explicitly identify.