You paste a screenshot into your agent and write "the button looks wrong." The agent asks which button, on which page, and what "wrong" means. Three round trips later it still edits the wrong element. That back-and-forth is the cost of feedback that skips the fields an LLM needs to act.
An agent does not see your screen, your history, or the conversation you had in your head before you typed. It reads text and, if you give it one, an image. Everything it needs to make a correct edit has to be on the page in front of it. Miss a field and it either asks or guesses, and guessing is worse.
The five fields that let an agent fix it the first time
A report an LLM can act on in one pass carries five things. Leave one out and you invite a question or a wrong fix.
- Source URL or route. Where the problem lives.
/checkout/paymenttells the agent which file or component to open. A screenshot alone does not. - The element, named precisely. "The primary CTA in the header," not "that button." A numbered pin on a screenshot removes the ambiguity entirely.
- Steps to reproduce. The path that triggers the state. "Log in, add two items, click Checkout, the total shows $0.00." Without repro, the agent cannot confirm it fixed anything.
- Expected versus actual. What you saw and what you wanted instead. "Total should sum line items; it renders $0.00." This is the field people skip most, and it is the one that defines the fix.
- Scope or constraint. "Only change the total calculation, leave the layout alone." This stops an agent from rewriting half the page to solve one bug.
The structure an LLM can act on is not a template you fill for its own sake. Each field maps to a decision the agent has to make, and each blank forces a guess.
Why expected versus actual does the heavy lifting
"The date picker is broken" describes a symptom you can see and the agent cannot. "Selecting March 31 sets the field to March 30" tells the agent exactly what to test and exactly when it is done. The first sentence starts a conversation. The second one starts a fix.
Write actual as what the screen currently does, in concrete terms. Write expected as the behavior you want, specific enough that the agent can verify it. If you cannot state the expected result, the report is not ready. That gap is a sign you are describing a feeling, not a defect, and the agent will feel that gap too. The anatomy of an agent-readable bug report comes down to closing it.
Capturing all five fields without typing a wall of text
You could type each field into a text box every time. Most people do not, which is why so much feedback arrives as "looks off, please fix." A faster path is to capture the screen and attach the detail to what you captured.
In Cobalt Capture, you open a browser tab, click Capture screen, and crop to the region that matters. No install, no extension, no signup. Then you drop a numbered pin on the exact element, which handles the "named precisely" field, and add a comment by typing or by dictating. Dictation is faster for repro steps and expected versus actual, because you can narrate the path the way you walked it. Start one from the new review screen and you have the capture, the pin, and the note in about a minute.
The URL travels with the capture. When you name the route in your comment, the agent knows where to look. Numbered pins that order the steps also double as repro markers: pin 1 is where you started, pin 3 is where it broke.
The output the agent actually reads
People and agents need different formats from the same report. A reviewer or client wants the public link or a PDF. An agent wants clean text. Every published review is available as plain-text markdown at /r/<slug>/markdown, and that is the format you hand an LLM.
The markdown keeps your fields as structure the model can parse: the pinned element, the comment, the route. That is the difference between feedback an agent can read and a screenshot it has to squint at. If you paste a raw image with no text, the agent is back to guessing which button you meant.
Once the report is published, anyone with the link can comment on an item, and you can mark each one resolved as the agent lands the fix. That gives you a running record of what shipped without a separate tracker. For a full example from capture to prompt, see one worked example of structured feedback.
A quick check before you send
Before you hand a report to an agent, read it as if you had never seen the screen. Can you tell which page? Which element? How to reproduce it? What should happen instead? What not to touch? If any answer is missing, add it now. The thirty seconds you spend closing the gap is cheaper than the three questions the agent would ask, and far cheaper than the wrong fix you would have to undo.
Start with the route and the pin, state expected versus actual in plain terms, and let the markdown carry it. The agent fixes it in one pass because there is nothing left to ask.