Change risk
See everything a change reaches, before it merges.
Every caller the diff can break, the files that usually move with it, the tests to run (picked from the call graph, even with no coverage report), who should review, and which other branches are editing the same files.
No LLM in the path · the same diff gets the same answer
Blast radius · from the call graph
1 signature changed · 5 direct dependents · 23 more within three hops
worker/jobs.py, cli/replay.py +3billing/ledger.py · 9 of 11 commits, not in this PRtests/test_hooks.py, tests/test_replay.py · inferredfeat/refunds · same file, 3 days agoBefore you merge
Add billing/ledger.py or say why it stays. It changed with this file 9 of the last 11 times.
Illustrative pull request · the fields the PR bot and get_risk return
Measured, not claimed
- 97.5%
- of the tests it picks for a change are right, with no coverage run
- 47 targets, checked against per-test coverage
- 95.7%
- precision of which tests reach a file, from the graph alone
- 46 links, checked against per-test coverage
- 0.976 to 0.995
- call-edge precision against the Go and TypeScript compilers
- The graph the blast radius walks
- 0
- LLM calls from the diff to the PR comment
- Same change, same answer, every run
Sound familiar?
Green checks. Broken production.
- 01
The reviewer did not know about the other caller.
- 02
Two files always change together, and one was left out.
- 03
The whole suite runs for a one-line change.
What makes it different
Six things a reviewer needs, before anyone asks.
- Blast radius
Every caller and dependent the diff can break.
Walked through imports, calls and framework edges, so the reviewer sees the second caller nobody mentioned.
- Missing co-changes
The partner file this change forgot.
Files history moves with these, flagged when the pull request leaves them out.
- Tests to run
The few tests that guard this change.
Picked from the call graph with no coverage report needed. Add one and the answer becomes measured.
- Reviewers
The people who own the code in its path.
Suggested from ownership of the files the change reaches, not from a rota.
- Branch overlap
Who else is editing the same files right now.
Every open branch that touches your files, so the conversation happens before the merge conflict.
- Merge gate
A CI check that asks for a second look.
Fail a pull request that ranks above a percentile you choose, on GitHub Actions or GitLab CI.
Install the PR bot
In depth
What a change reaches, one question at a time.
Blast radius
Every file the change can break, from the real graph.
Repowise walks out from the changed lines through imports, calls, type references and framework edges, so a route handler counts as a caller and the second consumer of a helper is never a surprise.
- Direct and transitive
- Dependents one hop out, and the ones three hops out.
- Changed contracts
- A changed signature lists every caller outside the PR.
- Across repositories
- In a workspace, the consumers in other repos too.
- Independent changes
- Flags a diff that is really two changes in one.
Signature changed
def charge(customer, amount):def charge(customer, amount, *, idempotency_key):Callers outside this pull request
4 of 9 showncreate_charge api/routes.py:58
direct · testedretry_failed worker/jobs.py:112
direct · no testclose_invoice billing/invoices.py:204
2 hops · testedreplay_events cli/replay.py:31
2 hops · no test
Check first
retry_failed calls the old signature and no test reaches it.
Tests to run
The few tests that guard this change. No coverage report needed.
The index already knows which tests reach which files. Ask about a change and get the short list, each with why it is in. Add a coverage report and the answer is measured, line by line.
- Inferred, then measured
- Labelled either way, never turned into a percentage.
- Tests to update
- The test files the change will probably need edited.
- Runnable
- Pipe the list straight into your test runner.
- Patch coverage
- Gate a PR on the coverage of the lines it adds.
3 of 1,204 tests guard this change
no coverage report · picked from the call graph- inferred
tests/test_hooks.pynamed for payments/hooks.py and calls handle_event
- inferred
tests/test_replay.pyimports cli/replay.py, which calls handle_event
- inferred
tests/integration/test_webhooks.pyreaches payments/hooks.py in two calls
tests/test_ledger.py · name pair, co-changes with the diffRun
repowise impacted-tests main...HEAD --format list | xargs pytest
Before the conflict
Who else is editing these files, and a gate for the risky ones.
Branch overlap lists every open branch that touches your files, so the conversation happens before the merge conflict. In CI, one flag fails a change that ranks above the percentile you choose and asks for a second reviewer.
- Branch overlap
- Same file, or a co-change partner, with ahead and behind.
- Fix history
- Whether the touched files have broken before.
- Review priority
- Ranked against this repository's own recent commits.
- Merge gate
- GitHub Actions and GitLab CI, with plain exit codes.
$ repowise overlap2 of 38 branches edit the files this change edits feat/refunds payments/hooks.py same file 3d ago fix/ledger-retry billing/ledger.py co-change, 9/11 1d ago $ repowise risk origin/main...HEAD --fail-above-percentile 95 --format githubReview priority: Typical · 62nd percentile of this repo's recent commitsThese files have broken before · 82nd percentile payments/hooks.py 40 lines 4.5 prior fixesgate passed (62 <= 95)On a real pull request
On the diff: what to check before you merge.
The PR bot carries the same analysis into the pull request. In Signals mode it comments only when there is something worth checking and links the full report: blast radius, every caller of a changed contract, and health before and after. With AI review it also writes each point on the line it concerns, with how it checked and a prompt for your agent.
In plain words
A review checklist the diff cannot show you.
A diff shows the lines that changed. Repowise walks out from them through the dependency graph and the git history to everything the change reaches, then says which parts a reviewer should check first. It reads the same way on a commit, a branch, a pull request or your uncommitted work.
How to read it
What the review tells you
- May break
- Production files that import or call what changed. The list to read before you approve.
- Moves with
- Files that changed together with these in most past commits and are missing from this one.
- Tests to run
- Measured when a coverage map backs it, inferred from the call graph when not, and labelled either way.
- Review priority
- Where the change ranks among this repository's own recent commits: below typical, typical or elevated.
How it works
The diff, the graph, the history.
- 01 / Read
Take the change as it is
A commit, a range, a pull request or uncommitted work, with merge commits read as their own content. - 02 / Reach
Walk the graph and the history
Callers and dependents from the index, co-change partners and prior bug fixes from git. - 03 / Direct
Say what to check
May break, moves with, tests to run, reviewers and overlapping branches, in one block.
Where it shows up
Shows up where the work already happens.
Pull requests
One comment on the pull request, edited in place on every push: what it reaches, what it left out, the tests to run. In Signals mode a green pull request gets silence.
Repowise PR bot on GitHub · CI gates on GitLab too
Coding agents
The agent checks its own diff before it opens the pull request, runs only the tests the change exercises, and is warned mid-edit when a function keeps breaking.
get_change_risk · get_risk(changed_files=[...])
VS Code
Analyze Change Risk in the source-control bar shows the reach of your uncommitted work before you commit it.
CLI and CI
Check a commit, a branch or uncommitted work from the terminal, and gate merges in CI.
repowise risk · repowise overlap · repowise impacted-tests
Questions
What people ask before they try it.
What does Repowise show about a change?
Everything it reaches: the production files that import or call what changed (may break), the files that usually change with these but are missing (missing co-changes), the tests to run, the people who own the code in its path, and any other open branch editing the same files. It works on a commit, a base..head range, a pull request or your uncommitted work.
How does it pick tests without a coverage report?
From the dependency graph the index already holds. It knows which tests import or call the files a change touches, so it can name the few that guard the change. Those answers are labelled inferred. Ingest a coverage report and the answer becomes measured, line by line.
Does it use an LLM?
No. The whole path is deterministic: the diff, the dependency graph and git history. The same change produces the same answer every time, with no token bill and no prompt-injection surface.
Is there a risk score?
There is a review priority: where the change ranks among this repository's own recent commits, as below typical, typical or elevated, with fix history showing whether the touched files have broken before. It orders pull requests for review; the reach, co-changes and tests say what to check.
How does it relate to the Repowise PR bot?
The bot carries the same analysis into the pull request. It posts one comment, edited in place on every push, and in Signals mode only when there is something worth checking, so a green pull request gets no comment. Every push also gets a Repowise review check with the reviewed commit and finding counts.
Can it gate merges in CI?
Yes. repowise risk --fail-above-percentile fails a change that ranks above the percentile you choose, and the GitHub Action and GitLab template run the same gate. A failure asks for a split or a second reviewer, not a code fix.
What is branch overlap?
A list of the other open branches that edit the files your change edits, with how far ahead and behind each one is. It is git first, so it works in a fresh clone, and the index adds co-change partners a branch is touching.
Is it free?
Yes for public and open-source repositories. The Repowise PR bot is a free GitHub App for public repos, and change risk ships in the open-source repowise package under AGPL-3.0. Private-repo PR comments require Repowise Pro.
Last reviewed: October 2026
Get started
Put the check on your next pull request.
Start free and see what your next change reaches. For a rollout across a team's private repositories, book a demo.
Or install the PR bot on a public repo