pre-modification-check
About pre-modification-check
A Repowise skill for checking change risk in indexed codebases before editing files. It surfaces hotspots, dependents, ownership, test gaps, and security signals to help developers gauge impact.
Key features
- 01File hotspot and risk assessment
- 02Dependents and impact surface
- 03Co-change partner detection
- 04Ownership and bus-factor signals
- 05Test gap and security indicators
Use cases
- 01Checking risk before editing a file
- 02Estimating impact before changing an API
- 03Planning a refactor across related files
MCP support
Uses Repowise get_risk and get_context MCP tools to assess target files and retrieve context before modifications; get_health can also inform larger refactors.
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ repowise-dev/ repowise --skill pre-modification-checkAfter installing, type/pre-modification-checkin Claude Code to confirm it loaded.
Details
From the project READMEPre-Modification Check with Repowise
Before modifying files in a Repowise-indexed codebase, assess the impact.
Before editing a file
Call get_risk(targets=["path/to/file.py"]). Per file it returns
hotspot_score, trend, risk_type, impact_surface (top 3),
dependents_count, co_change_partners, primary_owner,
test_gap, and security_signals. Read it for:
- Bug-fix history (
defect_profile) — present only on files with counted fixes:fix_countover the trailing 6 months,last_fix_days_ago, abug_magnetflag for sustained recent fix pressure, andtop_symbols(the per-symbol counts are approximate — read them as "mostly here"). A file that keeps getting fixed is the strongest single signal that the next edit breaks something; lead with it. - Hotspot status (
hotspot_score,trend) — high-churn × complex? Extra care needed. - Dependents (
dependents_count,impact_surface) — how wide is the blast radius? - Co-change partners — files that change together with this one (often without an import link); you may need to update them too.
- Ownership / bus factor — who owns it, and whether a single author maintains it.
- Test gap & security signals — flag untested or security-sensitive files before touching them.
When modifying multiple files
Batch all targets into one call: get_risk(targets=["file1.py", "file2.py", "module/"]).
When to warn the user
If get_risk shows:
- A
defect_profilewithbug_magnetset — say so plainly: this file has been fixed repeatedly and recently - Hotspot score above 90th percentile — mention this is a frequently-changed, high-risk file
- More than 10 dependents — list the top dependents; API changes here will break consumers
- Bus factor of 1 — note that a single person maintains this code
- Risk type is "bug-prone" or "high-coupling" — flag explicitly before making changes
Before refactoring or moving code
Call get_context(targets=["file.py"]) first to understand the full context: what uses this file, what decisions govern it, and why it's structured this way. This prevents accidentally violating architectural decisions.
For a heavy refactor, also call get_health(targets=["file.py"]) — the
marker findings (complexity, deep nesting, low cohesion, duplication) tell
you what to improve while you're in there, and give you a before/after score.
Error handling
If get_risk returns a tool error, the MCP server may not be running. Proceed with the modification but note that risk assessment was unavailable.