You prompt v0, it generates a pricing card, and 90 percent of it is right. The heading is fine, the layout is fine, but the CTA button sits too low and the border radius is wrong on the top card. So you type a follow-up like "fix the button spacing and the rounded corners," and v0 hands back a component that fixed those two things and quietly broke the alignment you liked. Now you are chasing regressions instead of shipping.
The problem is not v0. The problem is that a loose text instruction gives it no anchor. It cannot see which button you mean or how much lower it should sit. When the input is vague, v0 tends to regenerate broad chunks, and that is where working pieces get lost. Point at the exact spot and describe the exact change, and it edits narrowly.
Capture the generation as a still, not a description
Open a new review in a browser tab. No install, no extension, no signup. Click Capture screen and share the tab or window showing your v0 preview. The current frame is drawn to a canvas as a still image.
Drag a rectangle around the component that needs work, or keep the full frame if the issue spans the whole screen. Cropping is the only image edit, and that is on purpose: you want v0 looking at the actual rendered output, not at your redrawn version of it. A cropped still of the real generation carries every detail v0 already produced, so it has something concrete to compare against.
Pin the exact element and say what is wrong
Each captured screenshot becomes an item. Add a numbered pin on the button that sits too low, and a second pin on the card with the wrong corners. Pins turn "the button" into "the element at pin 1," which removes the guessing.
Then comment on the item. Type it, or dictate with the browser's built-in speech recognition in Chrome or Edge. Say what you see, where, and what it should become. Not "fix the spacing" but "pin 1: the Get Started button has about 40px of gap above it; reduce to match the 16px gap used on the other two cards. Pin 2: top card border radius is 4px; make it 12px like the cards below it."
That phrasing does two things. It names the current state and the target state, and it references the parts of the design you want kept. v0 reads that as an edit request scoped to two elements, not a signal to rebuild the card group. If you want the specific vocabulary that keeps an agent editing the right node, framing a screenshot so the agent edits the right element covers it in detail.
Publish and grab the markdown
Click Publish. The review is saved and gets a short public URL at /r/<slug>. The same review is available as plain-text markdown at /r/<slug>/markdown. That markdown is the format you feed back to v0.
Open the markdown version and copy it into your next v0 message. It arrives as structured text: the screenshot, the pin numbers, and your two scoped comments, all in a form v0 parses cleanly. Because the change request is written as "pin 1 does X, should do Y," v0 has a target to hit and a boundary around what to touch. The v0 handoff workflow is built around exactly this: give it a still plus pinned, specific comments and it iterates on the component instead of regenerating it.
Why the markdown and not a screenshot pasted into the chat? A raw image gives v0 pixels but no priorities. It has to infer what you care about. The markdown states it outright, in order, with pin references. That is the difference between a fix and a fresh guess. If markdown output is new to you, the terms behind markdown screenshots lays out the format.
Iterate on the next generation the same way
v0 sends back a new version. Some of it is right, some still needs a nudge. Capture it again. This is a loop, not a one-shot: each pass narrows the gap because each pass points at real rendered output and names a real target.
Keep the passes small. One capture, two or three pinned comments, publish, hand back the markdown. When you batch ten complaints into one message, v0 has to weigh them against each other and tends to compromise on layout. Two precise pins per round keeps the edits surgical. The same discipline applies across tools; the feedback loop that makes vibecoding ship walks through why tight cycles beat big ones.
When more than one person needs to weigh in
Anyone with the review link can post a comment on any item, and you can mark each comment resolved as you clear it. So if a designer flags the button spacing and a PM flags copy on the same generation, both land on the same review, both pinned, both in the markdown you hand to v0. You are not stitching Slack threads together. One link holds the visual, the pins, and every note.
Each review also has an owner-facing analytics page with visit counts, so you can see whether the people you sent it to actually opened it before you assume the feedback is stalled.
v0 is not the only place this fits. The same capture-pin-publish-handback pattern works for Bolt, Lovable, and any generator that takes a follow-up prompt. Start your first one at the new review page and hand v0 something it can act on narrowly.