mcpField
P
pre-modification-check

pre-modification-check

github.com/repowise-devTesting & quality8.0k65 installsUpdated today
Repository

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

  1. 01File hotspot and risk assessment
  2. 02Dependents and impact surface
  3. 03Co-change partner detection
  4. 04Ownership and bus-factor signals
  5. 05Test gap and security indicators

Use cases

  1. 01Checking risk before editing a file
  2. 02Estimating impact before changing an API
  3. 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-check

After installing, type/pre-modification-checkin Claude Code to confirm it loaded.

Details

From the project README

Pre-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_count over the trailing 6 months, last_fix_days_ago, a bug_magnet flag for sustained recent fix pressure, and top_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_profile with bug_magnet set — 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.

Comments

Markdown supported