Grep tells you where a name appears; it can't tell you the transitive reach of a
change, or that an edit just closed a dependency loop three hops away. The call graph can —
deterministically, so the same report goes in the PR every time. review reads
the git diff, maps the changed lines onto functions, and hands the reviewer a focused map.
One command turns a diff into a map
Point it at the base branch. It reports the changed functions,
the blast radius (transitive callers), the call sites to review, any risk flags, and a
Mermaid diagram of just the changed neighborhood — every reference a clickable
file:line.
On a service where a refactor added an audit hook, the report reads:
The reviewer instantly knows the change touches persist (a function four
callers depend on) and that it introduced a circular dependency — the
thing easiest to miss by eye, surfaced automatically. In the real report each function
name is a link straight to the line on GitHub.
Make it automatic on every PR
You don't want to remember to run it. One opt-in setup writes a GitHub Actions workflow that posts the report as a PR comment — nothing else added.
From the next PR on, reviewers open to a focused map instead of a wall of files. Add
--fail-above N if your team wants to gate on an oversized blast radius —
otherwise review stays a pure report and never blocks a merge.
What you got. Every PR now opens with the answer to "what do I actually need to look at here?" — the changed functions, a measured blast radius, the exact call sites, and automatic detection of newly introduced cycles, each one a click from the source. Large-repo review stops being archaeology.
The report is deterministic (same input → byte-identical output) and every
reference is a real file:line — links resolve to GitHub when a remote is
detected, plain text otherwise. See also the
blast-radius & cycle-gate walkthrough.