An AI coding agent will do exactly what you tell it, and nothing you forgot to say. If you write "the header looks off," the agent guesses. If you write "the header logo is 12px too far left on viewports under 768px, and the nav items wrap to a second line," it has something to change. The gap between those two sentences is where most agent feedback fails.
The job is to convert what you see into instructions that are specific, located, and readable by the agent. Here is the procedure.
Show the agent what you are looking at
Agents read text, but they reason far better when the text describes a real frame. Start by capturing the screen you are reviewing. Open a new review in a browser tab, click Capture screen, and pick the window. The current frame draws to a canvas. Crop to the part that matters: the broken modal, the misaligned form row, the table that overflows.
One screenshot per problem. If the checkout page has three issues, that is three captured items, not one screenshot with three things wrong in it. Separate items keep each instruction self-contained, which is exactly how an agent wants to consume them.
Cobalt Capture does not draw arrows or boxes on the still. Instead, drop a numbered pin on the exact spot, then reference the number in your comment: "Pin 1 sits over the Submit button." That pairing of a located mark and a written instruction is what turns a picture into something actionable.
Write the instruction, not the symptom
For each item, type or dictate a comment. State three things: what you see, where it is, and what should happen instead.
The date picker (pin 1) opens below the input and gets clipped by the card's overflow:hidden. On the booking form at /reserve, it should open above the input when there is no room below.
Notice what that comment includes: the element, the location, the cause you suspect, the page route, and the expected behavior. The agent can act on every clause. Compare it to "date picker is broken," which forces the agent to reopen the page, reproduce the issue, and infer your intent.
Dictation helps here. In Chrome and Edge you can talk through what you see, which is faster than typing and tends to produce fuller descriptions because you explain the way you would to a colleague. Firefox does not support the browser speech feature, so you type there instead. Either way, edit the text down before publishing. An agent does not need your filler words.
If a problem has no screenshot (a missing empty state, a route that should exist but does not), add a free-floating comment. It still becomes an item the agent reads.
Hand it over in a format the agent can read
Publish the review. You get a short public URL at /r/<slug>, and the same content is available as plain-text markdown at /r/<slug>/markdown. That markdown is the file you give the agent. Paste the link or the text into Cursor, Claude Code, Aider, or whatever you run, and it reads each item, comment, and pin in order.
Markdown matters because it is the format these tools parse cleanly. A video does not work as input here, which is the core reason a Loom recording falls flat as agent input: the agent cannot extract a timestamp into a code change. Clean headings and located comments, it can. For the full mechanics of the handoff, the guide on giving feedback to an AI coding agent walks through each step with examples.
The structure of that markdown is itself a feature. Each item becomes a section, each comment a body, each pin a labeled reference. If you want to see what good structure looks like before you write, read what agent-readable feedback actually means.
Order items so the agent works top to bottom
Agents process your list in sequence. Put related changes together so the agent does not bounce between files. Group everything on the checkout page, then everything in the account settings, rather than alternating. If one change depends on another (rename the field before you update the validation message), state that dependency in the comment.
Keep scope honest per item. "Redesign the dashboard" is not a fixable instruction. "Move the revenue card above the activity feed on the dashboard" is. If you find yourself writing a paragraph that contains the word "and" four times, split it into separate items.
One review can also go to a human
The same published review serves people, not just the agent. A teammate or client opens the public link and reads it without an account. You can export the review as a PDF or a Word document for anyone who wants a file. People with the link can comment on individual items, and you mark each one resolved as it gets handled. So you write the feedback once and it works for both audiences, which is the point of treating agent feedback as a real artifact rather than a throwaway message.
If your work is mostly building with an agent and iterating, the feedback loop for vibecoding shows how this capture-and-hand-off cycle keeps a build moving.
The short version, as a checklist
- Capture one screen per problem, crop to the part that matters.
- Drop a numbered pin on the exact spot.
- Write what you see, where, and what should happen instead.
- Group related items and note dependencies.
- Publish, then hand the markdown link to the agent.
No install, no extension, no signup. Open a tab, capture, write, publish. The first review you hand over this way will come back as a clean diff instead of a clarifying question.