Here is a comment a designer left on a checkout page during review: "The button looks off and the total is wrong sometimes." Paste that into an LLM and ask it to fix the code, and you get a guess. Which button? Off how? Wrong compared to what? The model has nothing to anchor on, so it invents context and edits the wrong file.
Below is that same feedback, rebuilt into something an LLM can act on. Same bug, same reviewer. The difference is structure, and the structure comes from how the feedback was captured, not from clever prompting afterward.
The raw input, and why it fails
Start with what the reviewer actually saw. The checkout page shows a cart with two items. The order total reads $48.00. Add the two line items ($19.00 and $19.00) plus shipping ($6.00) and you get $44.00. The total is off by four dollars. Separately, the "Place order" button sits flush against the coupon field with no gap, and its label wraps onto two lines on a narrow screen.
Two real problems. The raw note collapsed both into one vague sentence and named neither element precisely. An LLM cannot fix "looks off." It can fix a specific element with a specific expected value.
The failure mode here is common enough that it has its own list of causes. See the mistakes that make screen feedback hard to act on if you want the full set.
The structured version, shown in full
Now the same review, captured as two separate items, each with a screenshot and a comment. This is the markdown an agent reads:
## Item 1
Screenshot: order-summary.png
Pin 1: order total field
The order total shows $48.00. Expected $44.00. Line items are $19.00 + $19.00 = $38.00, shipping is $6.00, so the total should be $44.00. Check the subtotal calculation; it looks like shipping is being added twice or a stale value is cached.
## Item 2
Screenshot: place-order-button.png
Pin 1: Place order button
Pin 2: coupon input above it
The Place order button touches the coupon field with no spacing. Add vertical margin above the button (roughly 16px to match the gap used elsewhere on the page). On a 375px viewport the label wraps to two lines; keep it on one line.
Two items, two screenshots, four numbered pins pointing at the exact elements, and each comment states what is wrong and what the expected result is. An LLM can read this and go straight to the total calculation and the button spacing. No guessing about which button.
How the structure gets created without extra work
You do not write that markdown by hand. Each block above is the output of a single capture step in the browser. In Cobalt Capture, you click Capture screen, crop to the order summary, and either type or dictate the comment. Then you capture the button, drop two pins, and add the second comment. When you publish, the review becomes a public link, and the same content is available as markdown at /r/<slug>/markdown.
That markdown is what an agent reads. The person on your team who is not touching code gets the public link and a PDF instead. One review, three formats, no reformatting. The reason to build structured feedback for LLMs this way is that the structure is a byproduct of capturing carefully, not a separate rewrite pass.
The pins matter more than they look. "The button" is ambiguous when a page has six buttons. Pin 1 pointing at a specific spot on the screenshot removes the ambiguity before the model ever reads a word. That is the core of what makes feedback something an agent can act on.
What to include in each comment
The pattern in both items is the same three parts: what you observed, what you expected, and where to look. Item 1 says the total is $48.00, states it should be $44.00, and points at the subtotal calculation. That expected value is the piece raw feedback almost always drops.
Numbers beat adjectives every time. "Add roughly 16px of margin" gives the model a target. "Add some space" makes it pick a value, and it will pick wrong half the time. Same with the viewport: "375px" is actionable; "on mobile" is a shrug.
If you are feeding this into a specific tool, the format holds across all of them. The same markdown works whether the receiver is Claude Code or Cursor, because it is plain text with headings and pin references, not a proprietary export.
Try it on your next review
Take the last vague note you sent a developer or an agent. Rewrite it as observed, expected, and where to look, with a pin on the exact element. Then capture it once and let the tool produce the markdown. Start a new review and run one real screen through it; the difference between "looks off" and the structured version above shows up in the first fix that lands correctly.