Use case · developers
Every pull request already builds a preview. Review that — pin what's wrong on the deploy itself, and your agent fixes it in the branch before anyone merges. No checkout, no local run.
Review the build, not the diff.
Every pull request already deploys one. It's a real running build on a real URL — which makes it the cheapest review surface you have, and the one nobody has to set up.
The URL travels with the note, so the feedback is tied to that build rather than to “the version I looked at yesterday”.
Feedback is scoped per page, not per site. The review of the checkout screen doesn't turn into a pile of notes about the whole app.
It reads the pin over MCP, makes the change on the same branch and replies with the commit. The visual review closes before the merge instead of after it.
A designer, a product manager or a teammate on another platform can review a build without a local environment. What they send back is not an opinion on a screenshot but a note attached to an element of that exact deploy.
Claude Code · via MCP: “Fixed the wrapping of the plan cards at 768px on this branch — grid-template-columns was hard-coded to 3. Commit b52d90.”
A checkout flow captured on a demo deploy by the CLI — the same thing an agent records for a preview URL, so the reviewer sees the build rather than a description of it.
Recorded with handoff walk against a public preview URL.
Preview deploy feedback is review that happens on the build a pull request produces, rather than on the diff that produced it. The reviewer opens a URL, points at what looks wrong, and the note goes back to the branch it came from.
Code review is good at catching what code does and poor at catching what it looks like. Reading a diff will not tell you that the cards wrap badly at tablet width or that the empty state now says nothing at all — those are properties of the built page, and they only appear once something builds it. Which is why previews exist, and why so much of what they show goes unreviewed: looking is easy, but reporting what you saw is not.
Attaching notes to the deploy closes that gap. The URL, the element and the viewport travel with each note, so the feedback belongs to one build rather than to a moment in time — and the agent that reads it over MCP is already working on the branch that produced it.
With both, and with any other host — Handoff needs a URL, not an integration. A preview from your own CI works the same way.
You review it in your own browser, so whatever access you already have is enough.
No. Feedback is scoped per page, and each preview has its own URL — so a review of one build stays with that build.
Yes. It reads the pin over MCP, changes the code where you're already working and replies with what it did.
To leave notes, yes — plus a free account on your team, so the notes land on your board rather than their own. To follow a review that's already there, a shared link is enough.