change-review

Change Review with Repowise

When a diff is on the table, Repowise turns "what files changed" into "what does this change put at risk" — fusing git history (churn, ownership, co-change) with graph topology (dependents, impact surface), test gaps, security signals, and the architectural decisions that govern the touched code.

Two complementary risk signals — use both:

• repowise risk (CLI) scores the whole change as one unit (a commit or a base..head range) → a single 0–10 defect-risk score with drivers (lines added/deleted, files, directories, subsystems, change entropy, author familiarity). No LLM, no network. This is the pre-merge gate: "how risky is this change overall?"
• get_risk(changed_files=…) (MCP) works per file and returns the directive block — the specific things to check inside the diff.

Score the whole change first

repowise risk <revspec>     # HEAD, a commit SHA, or base..head (e.g. main..HEAD)

Read the score and its top drivers — a high score from large diffusion (many dirs/subsystems) or low author familiarity tells you where to look hardest. Add --ext .py,.ts to count only certain file types, --format json for a machine-readable breakdown.

Then drill into the directive block

Call get_risk in PR mode by passing the changed files:

get_risk(targets=<changed files>, changed_files=<same changed files>)

The response carries a directive block — read it first, it's three short lists:

• will_break — files/symbols that depend on what changed but are not in the diff. These are the likely breakages. Check each one.
• missing_cochanges — files that historically change together with the changed files but were left untouched. Often a forgotten update.
• missing_tests — changed code with a test gap. Flag for new/updated tests.

pr_blast_radius holds the fuller dossier behind those three lists.

Then go deeper where it matters

1. Why does this code exist? For any non-trivial changed file, call get_why(query="<file>") — don't let a change silently contradict a recorded architectural decision. Surface conflicts_with / supersedes hits.
2. Did the change make health worse? get_health(targets=<changed files>, include=["biomarkers"]) — call out new complexity, deep nesting, or duplication the diff introduced.
3. Who should review? get_risk ownership + co-change signals suggest the people with the most context on the touched code.

Getting the diff

• A GitHub PR: gh pr diff <number> (or gh pr view <number> --json files).
• A branch: git diff --name-only main...HEAD.
• Working tree: git status --porcelain.
• CLI shortcut for a range: repowise risk main..HEAD scores a branch/PR range for defect risk directly.

Write the review around evidence

Lead with a risk level and the directive findings, each tied to a concrete file. Distinguish "will break" (a dependent outside the diff) from "worth a look" (a co-change or health regression). Don't pad with findings the tools didn't support.

Error handling

If get_risk errors or returns nothing, the MCP server may be down or the repo unindexed — say so and review from the raw diff, noting that Repowise context was unavailable. Suggest /repowise:init if the repo isn't indexed.