You have a screen that is 80 percent there. The header spacing is wrong, a button label is stale, the empty state shows the wrong copy on mobile. You could describe all of that in a paragraph, but the agent will guess at half of it and fix the wrong half. The handoff that works is the one where the agent sees what you see and reads notes pinned to specific spots.
Here is the order of operations that gets a half-built screen from your eyes into an agent's context window without losing detail in translation.
Step 1: Get the screen into the state you want to comment on
Open the actual running build, not a Figma file. If the bug only shows up with three items in the cart, put three items in the cart. If it only shows up when the user is logged in as an admin, log in as an admin. The agent will reproduce against the same state, so the screenshot needs to match the conditions you want fixed.
Outcome: the browser window shows the exact state that needs work.
Step 2: Open a review tab and capture the frame
In a new tab, go to start a new review. Click Capture screen. The browser asks which window or screen to share, you pick the tab with your half-built screen, and the current frame is drawn onto a canvas. No install, no extension, no signup. If you want only the header area, drag a rectangle to crop. If the whole viewport matters, keep the full frame.
Outcome: a still of the broken screen is now an item in your review.
Step 3: Drop numbered pins on the spots that matter
An agent reading a paragraph that says "the spacing is off" has no idea which spacing. Add a numbered pin to the gap between the logo and the nav. Add another to the button whose label is wrong. Add a third to the empty-state illustration that should not appear when results exist. Three pins on one screenshot is fine. Five is fine. If you find yourself adding twelve, that is two screens of work, not one.
Outcome: every problem has a coordinate the agent can refer to.
Step 4: Write or dictate the comment behind each pin
For each pin, say what is wrong and what it should be. "Pin 1: 24px gap, should be 16px to match the spec." "Pin 2: button reads 'Submit', should read 'Create account'." "Pin 3: empty state shows even when results array has items; hide it when results.length greater than zero." In Chrome or Edge you can dictate with the built-in speech recognition; in Firefox you type. Either way, name the file, component, or route if you know it. The agent will find it faster.
Outcome: each pin has a concrete instruction, not a vague complaint.
Step 5: Add floating context the agent needs but the screenshot cannot show
Some context is not a pixel. The branch name. The route. The fact that this only repros on viewport widths below 768. Add these as free-floating comments with no screenshot attached. Keep them factual. The agent will read them as setup, not as bugs.
Outcome: the agent knows what it needs to know before touching code.
Step 6: Publish the review
Click Publish. The review gets a short URL of the form /r/<slug>, and the same content is available as plain markdown at /r/<slug>/markdown. The markdown version is what the agent will actually read; it includes every screenshot, every pin number, every comment, in a structure built for an LLM. If you want more detail on what that looks like, see what is agent-readable feedback.
Outcome: one URL holds the visual review for humans and the markdown feed for the agent.
Step 7: Hand the markdown URL to the agent
In Cursor, Claude Code, Cline, Aider, or whatever you use, paste the /markdown URL and tell the agent to fetch it and treat it as the work list. A prompt like "Read this review and address each pinned item. Confirm the file you plan to change before editing." works well. For tool-specific notes see getting feedback into Cursor or the Claude Code guide. The full human-to-agent handoff page lists the rest.
Outcome: the agent has the same screenshots, the same pin numbers, and the same instructions you do.
Step 8: Review what the agent did against the original pins
When the agent reports back, open the published review in one tab and the new build in another. Walk pin by pin. If pin 2 is fixed and pin 3 is not, post a comment on item 3 in the review and tell the agent to re-fetch. The owner-facing analytics page shows whether the agent (or anyone else) actually opened the markdown URL, which is useful when a fix comes back suspiciously fast.
Outcome: you verify the fix against the same artifact the agent worked from, not against memory.
When this workflow is overkill
One-pin reviews are fine and often the right size. A single screenshot with one pin and one sentence beats a sprawling document for a single bug. The procedure above scales up to a screen with several issues; for a single broken button, skip the floating context and publish in under a minute. For larger pre-launch passes, the staging review walkthrough covers the longer version, and turning a screenshot into a prompt covers the one-shot case.
Open a fresh review the next time a half-built screen is sitting in front of you. The handoff takes about as long as writing the bug description would have, and the agent gets pixels instead of paragraphs.