PR review for UI changes the diff can't show

This page is for engineers and QA reviewing a pull request that touches the UI. The visual PR review is its own discipline, distinct from a code review of the same diff. It fits the broader pattern on the use cases for visual product feedback hub: many small findings across a flow, all of them visual, all of them needing to land back on the PR author in a state they can act on. The diff shows what changed in the code. It does not show how the change looks.

The problem

You pull the branch. You run it locally. The header animation is too jumpy on the dashboard, the empty state copy got truncated on tablet, and the new modal doesn't trap focus. You jump back to the PR and type "the spacing here looks wrong" into a review comment. The PR author reads that two hours later and has no idea which page, which viewport, which interaction. They ask a clarifying question. You reply with a screenshot dragged into the GitHub comment box, which works until you have five findings and the thread becomes unreadable. The repro context evaporates between your local machine and the author's. Half the issues get fixed. The rest merge. The author opens a follow-up PR a week later to clean up the misses, which is the same review cost paid twice.

The CobaltCapture workflow

Pull the branch and start your dev server. Open the first changed page in one tab. In another, hit Capture screen at cobaltcapture.com and pick the dev server window. Drag a box around the first finding, the jumpy header, the truncated copy, the broken focus trap. Hit Dictate and talk through it: "Focus doesn't return to the trigger when the modal closes via Escape, only when closed via the X button. Tested on Chrome and Firefox, same behavior." Move to the next changed page in the diff, capture again, dictate again. Every item is stamped with the source URL of the page it came from, so the author lands on the exact route you were on.

When you finish the walk, hit Publish. You get a URL like cobaltcapture.com/r/<slug>. Paste it into the PR description as a "Visual review" section, or drop it as a top-level review comment on the PR. The author's coding agent (Cursor, Claude Code, Windsurf) can ingest that URL the same way the author does. One link replaces the back-and-forth of fragmented inline comments and dragged-in screenshots.

What the output looks like

The published review is a markdown document. Each finding is its own section with a heading, a cropped screenshot, the source URL of the page, and your dictated commentary. The format pastes cleanly into a GitHub PR description, a Linear linked ticket, or directly into a coding agent's context:

# PR #2418 visual review, dashboard refactor

## Header animation jitters on tab focus

Source: http://localhost:3000/dashboard

![Header re-animating on every tab focus](https://cobaltcapture.com/r/abc12345/img/1.png)

The header re-runs its entrance animation every time the tab regains
focus, not just on first load. Repros in Chrome 124 and Firefox 125.
Looks like the IntersectionObserver got re-created in the effect that
moved into useLayoutEffect in this PR. Should run once on mount.

## Empty state copy truncates on tablet

Source: http://localhost:3000/projects

![Empty state with truncated CTA text](https://cobaltcapture.com/r/abc12345/img/2.png)

The "Create your first project" CTA truncates to "Create your first
proj..." at viewport widths between 768px and 900px. The button has a
fixed max-width of 220px that doesn't account for the new longer
string. Either bump max-width or shorten the copy.

## Modal doesn't return focus to trigger

Source: http://localhost:3000/settings/team

![Settings page after closing the invite modal](https://cobaltcapture.com/r/abc12345/img/3.png)

When the invite-teammate modal closes via Escape, focus drops to the
body instead of returning to the "Invite" button that opened it.
Closing via the X button restores focus correctly. The new focus-trap
hook likely needs to call restoreFocus on the keydown path too.

Why this beats PR-comment-only review

PR comments are text. They were designed for "this variable name should be plural," not "this animation is jumpy in a way that's hard to describe." When a reviewer types one line into a PR comment, the PR author cannot reproduce what the reviewer saw. They can guess. They can ask a clarifying question and wait. They can pull down the branch themselves and hunt, which defeats the purpose of having two people on the review in the first place.

The CobaltCapture URL is an artifact, not a comment. It carries the screenshot, the source route, and the spoken context as one durable document. The PR author opens the URL and sees exactly what you saw, on the route you saw it on, with the nuance you'd have lost in a one-line comment. So does their coding agent: paste the URL into Claude Code along with "fix these in order" and the agent has every screenshot, every route, every piece of dictated context. The review survives the handoff from human reviewer to author to agent without losing fidelity at any step. The PR thread stays focused on code-level discussion. The visual findings live in their own document, linked once, referenced as long as the PR is open.

Who this is for

Engineers reviewing UI-touching pull requests. QA leads doing a pre-merge visual pass on a feature branch. Frontend tech leads who care that the design system stays consistent across PRs and that regressions don't ship under the cover of a passing test suite. Anyone whose PR review responsibility includes "does this look right" and whose finding needs to land back on an author who's increasingly steering a coding agent through the fix. If your visual PR comments currently die in a thread of clarifying questions, the markdown URL is the format that ends the back-and-forth and gets the fix in the same PR instead of a follow-up.