Start at the smallest file
Reviewers read top-down and tire bottom-up, so authors put the trivial files first and the load-bearing ones last. Invert it. The one-line fix in a config file often explains the 400-line refactor behind it — read the small file first and the big one shrinks.
Then read the test diff before the source diff. Tests tell you what the author believes the code promises, and a test that changed shape is a contract renegotiation you are being asked to sign.
Three questions per hunk
What did this line do before? Why is the new version more true? What breaks that used to work? If you cannot answer the third, the author has not either — ask.
Deleted code deserves more attention than added code. Additions are intentions; deletions are behaviour changes. A delete without a test touching it is where the bugs live.
Comment on the decision, not the style
A linter owns style. Your value as a reviewer is the decisions: naming that hides a concept, a retry without a bound, a budget quietly raised. Those are the comments that survive the merge.
The studio log on this site records what shipped with the measurement that justified it. That is what a good review comment looks like: a claim attached to its evidence.