code-health
GitHub基于Repowise进行代码健康度分析,通过复杂度、技术债务等指标评分,辅助识别高风险文件、规划重构优先级及检测覆盖盲区。
Trigger Scenarios
Install
npx skills add repowise-dev/repowise --skill code-health -g -y
SKILL.md
Frontmatter
{
"name": "code-health",
"description": "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."
}
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): adirectivenaming 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, thenget_health(targets=[worst files], include=["refactoring"])and present the ranked plans, not just the scores. - Rank by
weighted_deficit, notscore— 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
unresolvedbefore calling a file clean: a target listed there matched nothing, andnot_indexedmeans runrepowise 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.coveragealso builds the per-test map), then re-runrepowise health.
CLI equivalents
repowise health— KPIs + lowest-scoring filesrepowise health --refactoring-targets— ranked by impact / effortrepowise health --trend— snapshots + declining alertsrepowise 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.
Version History
- 370793f Current 2026-08-19 23:15
- b5f4753 2026-07-25 05:12


