get_change_risk

Before merging, your agent should know whether this particular change is a routine one or an unusual one for this repo. get_change_risk scores a commit or a base..head range from the shape of its diff: how many lines, how many files, how scattered across directories, and how experienced the author is. It reads the live checkout, so it needs no index refresh and works on a branch you indexed an hour ago.

It is deliberately different from get_risk, which scores indexed files by path and can report blast radius. get_change_risk scores the change. That means it catches risky small diffs that a file-level view misses.

No LLM, no network. It is pure git plus learned constants, so the same diff always scores the same.

When to call

• Before merging a commit or PR range, as a triage signal.
• On a branch you want to compare against the repo's own norm.
• When the diff matters more than the files, for example a three-line change spread across six subsystems.

Parameters

Returns

Read the top three fields first. They are repo-relative and they are what you triage on.

Note that drivers are reported relative to the model's baseline commit (the calibration-corpus mean), not to your repo. So a small change can legitimately read "more lines added than baseline" while still ranking Below typical for a repo of large commits.

What it measures

The model uses Kamei-style change metrics over the diff:

The score is a plain L2-logistic over standardized, log-compressed features, so every feature's push on the result is exact rather than inferred.

Impacted tests

impacted_tests lists the tests that the per-test coverage map proves execute the change's changed lines. That is line-precise, so it is a narrower set than get_risk's file-level tests_to_run. It is capped at ten, with total and truncated reporting overflow.

missing_tests buckets the rest: untested_changes (covered file but uncovered change), stale_test_candidates (covered lines whose guarding test file is not in the diff), covered, and no_coverage_data.

Prior fixes

When the changed files carry counted bug fixes, the response includes prior_fixes: per file, how many past bug-fix commits touched it (fix_count), how many of the change's lines fall inside ranges one of those fixes replaced (overlapping_lines), and how long ago the most recent was (last_fix_days_ago). total_fixes counts distinct commits, not rows. The block is absent entirely on an index with no fix history.

overlapping_lines is labelled approximate in the payload, and that label carries weight: a past fix's ranges are numbered against its own parent commit, so anything that moved lines in between shifts them. Read it as "this neighbourhood has been patched before", not "this exact line". The fix_count beside it has no such caveat.

The block is aggregate and never names the commit that introduced a bug. File-level SZZ attribution measured 74.5% precision on this repo's frozen judgments, which is enough to count fixes and not enough to accuse a commit of causing them.

Example

get_change_risk()

get_change_risk(
    revspec="main..HEAD",
    extensions=[".py"],
    exclude_patterns=["tests/"],
)

Things worth knowing

• Filters apply to both sides. extensions and exclude_patterns filter the change and the recent commits sampled for its percentile, so the comparison stays like for like.
• Project-wide rules belong in a repository-root .riskignore. Those patterns apply automatically and combine with anything passed in the call.
• An empty diff produces a warning field, which usually means a bad revspec or over-tight extension and exclusion filters.
• baseline: 0 disables percentile ranking, which leaves only the corpus-anchored score. Avoid it unless the repo is too young to have a distribution.
• No cross-repo fields. This tool is pure diff shape. Blast radius and co-change partners belong to get_risk.

The same scoring is available from the shell as repowise risk.