Review the change,not the diff.
Read against the graph, so review covers what the change reaches and what is reaching for it.
What a diff cannot tell you.
A diff shows the lines. The graph shows what they are wired to.
What it reaches
Not the changed lines, the changed functions: who calls them, who calls those, and the configs and tests that name them.
What else is reaching
Two branches editing the same thing from different directions is the merge nobody sees coming. Both are read against one graph.
Where each claim came from
Every hop carries its tag. A caller found by the parser and a link inferred by a model are not the same evidence.
It just runs.
Open one and the review is waiting. Nothing to run and nothing to remember: the graph is already built and already current, so a pull request is read the moment it opens.
What the change reaches, which open branches it overlaps, and the order the queue should be merged in. Free covers a few reviews a month; Pro and Teams lift the cap.
It comments on reach, not on style. Plenty of tools will tell you about your variable names; none can tell you the function you just edited is three hops from the billing path.
The same reading, on demand.
What is open, which to read first, and where two branches collide.
$ graphify prs
#482 refactor: extract PaymentGateway touches 12 nodes · 3 shared with #479
#479 fix: retry logic in RedisClient touches 4 nodes
$ graphify prs --triage
#482 HIGH overlaps #479 on RedisClient · review first
#479 LOW isolated change
$ graphify prs --conflicts
#482 <-> #479 both modify RedisClient.retry · merge riskThe open-source tool answers the same questions against a graph on your own disk. No account, and nothing leaves the machine.