A diff tells you what changed in the source. It does not tell you whether the button still aligns with the input next to it at 375px wide, whether the focus ring is visible on the new dark background, or whether the empty state looks like a bug. For UI work, the diff is the wrong artifact to judge the change on. The built page is.
The fix is small: spin up the PR's preview build, walk through it on screen, capture what you see, and attach that capture to the PR before you approve or request changes. Here is a procedure that works whether the author is a teammate or an AI coding agent.
Open the PR's preview build, not your local main
If your CI publishes a deploy preview per PR (Vercel, Netlify, Render, Cloudflare Pages, GitHub Actions with a static host), open that URL. Do not review on your local checkout of main and do not trust the screenshot the author pasted into the PR body. You want to see the same build the merge will produce.
If there is no preview deploy, check out the branch and run it. Note the commit SHA you tested against. You will reference it in the review so a later reader knows which build your screenshots came from.
Before you start capturing, set up the conditions the change cares about. If the PR touches a logged-in dashboard, log in. If it touches an empty state, find or create an empty account. If it touches a list, get the list to the length the design assumes, then capture it again at zero items and at the overflow point. A diff cannot tell you whether 47 items wraps correctly. The screen can.
Walk the change on screen and capture the states that matter
Open a new browser tab to start a new review. Click Capture screen, share the tab with the preview build, and crop to the area you want to discuss. Each capture becomes an item you can comment on, by typing or by dictating with your browser.
For a UI PR, the states worth capturing are predictable. Work through them in order so you do not miss any:
- The default rendering of the changed component or page.
- Hover, focus, and active states on anything interactive.
- The form with valid input, then with the validation error the PR introduces or changes.
- The loading state, if there is one. Throttle the network in devtools to catch it.
- The empty state and the overflow state.
- The smallest width your product supports, usually 375px, and one breakpoint above it.
- Dark mode, if the product has one.
- The keyboard tab order through the new interactive elements.
Drop a numbered pin where your comment points. "Pin 1: the helper text sits 4px closer to the input than the spec, pin 2: the error message replaces the helper text but the field height jumps, pin 3: focus ring is clipped by the card border." That is feedback the author can fix without a back-and-forth.
If something is fine, do not capture it. The point of the review is the deltas from acceptable, not a tour. Free-floating comments without a screenshot are also fine for things like "please add a Storybook entry for the new variant" that have no single screen to point at.
Attach the review to the PR so the author can act on it
Click Publish. You get a short public URL of the form /r/<slug>, plus a PDF, a Word doc, and a markdown version at /r/<slug>/markdown. Paste the public link into the PR as a review comment, with one line of context: "Visual review against commit abc1234, preview URL https://pr-482.example.dev. Six items, three blocking."
The author opens the link, sees every screenshot with your pinned comments, and replies on each item. When they push a fix, they mark that item resolved. You re-capture only the items you flagged as blocking and reply on those. The PR conversation stays about the code; the visual conversation lives next to it, in one place, with the screenshots that prove the point. That is the whole loop the pull request review workflow is built around.
If the PR was written by an AI coding agent, paste the markdown URL into the agent instead of the public link. Cobalt Capture's markdown output is what a coding agent reads cleanly, and it is the same content the human sees. There is more on that flow in the guide to feeding feedback to an agent and in markdown bug reports.
What to put in each comment so it is actually fixable
A useful UI review comment names the element, names the expected behavior, and names the observed behavior. "The submit button is broken" is not fixable. "Submit button at 375px: label wraps to two lines because the button keeps its desktop max-width. Expected: button shrinks to container or label truncates with ellipsis" is.
Dictate these if you can. Talking through what you see while you point at it produces more specific feedback than typing does, because you describe the screen as you look at it rather than summarizing from memory. The browser does the transcription; you clean up afterward.
Mark each item with a severity the author can sort on. Blocking, non-blocking, nit. A reviewer who tags severity gets faster turnarounds because the author knows which three of your nine comments must be addressed before merge.
What this changes about your review queue
Once the team is used to attaching a review link to UI PRs, the diff stops being the place where visual decisions get made. The diff is where code decisions get made. Spacing, contrast, focus, mobile layout, and copy live in the review link, with screenshots, against a specific preview build. That separation is the win. It is also how a staging review or a design review on the built product works; PR review is the same pattern at a smaller scope.
Next PR you pick up that touches UI, do not approve from the diff. Open the preview, capture the states, and attach the link.