You type "the button looks off, fix it" into Bolt, hit send, and watch it edit a button three sections away from the one you meant. The turn is spent. You correct it, it touches something else, and now you have two problems. The issue is almost never Bolt. It is the description. Here are five patterns that send it the wrong way and what to write instead.
Describing the element by how it looks instead of where it is
"The blue box" and "the card near the top" feel precise because you can see exactly what you mean. Bolt cannot. It is reading text, not looking at your screen, so an adjective that depends on the render is a coin flip. If there are two blue boxes, or the card you mean is second from the top on mobile, it picks wrong.
Give it something anchored to the page. Quote the visible text inside or next to the element: "the Save changes button in the account settings form." Name the section heading above it. If your feedback comes with a screenshot, drop a numbered pin on the exact spot and reference the pin. A pin plus the nearby label removes the guessing. There is a full walkthrough of pinning the exact spot a reviewer means on a screenshot if you want the mechanics.
Sending words with no picture of the current state
Text-only bug reports force Bolt to imagine the screen. "The spacing is wrong under the form" could mean a 4px gap that should be 24px, or a heading colliding with an input. Without the current state in front of it, the agent guesses at both the problem and the target, and half the time it fixes an imagined version of your bug.
Attach a captured still of what the screen actually looks like right now. Crop it to the broken region so nothing else competes for attention. A cropped screenshot with a one-line description of what is wrong and what it should be beats three paragraphs of prose. The recommended flow for handing a captured screen and fix request to Bolt is exactly this: capture, comment, paste the link or the markdown. There is also a short piece on how to send Bolt a screenshot and fix request in one link.
Stacking five bugs into one message
Batching feels efficient. You found six issues walking the page, so you list all six and send them together. Bolt tries to hold all of them, half-fixes the first, conflates the third with the fifth, and returns a diff that touches ten files. Now you cannot tell which change addressed which bug, and reviewing it takes longer than reporting them separately would have.
Give each bug its own item. One screenshot, one comment, one expected result. If you are collecting them in a review, that is what an item is for: each captured screenshot becomes a separate, self-contained report. Feed them to Bolt one at a time, or link the whole review and let it work down a clean, numbered list. Either way each fix is scoped and each diff is reviewable. The same discipline shows up in the mistakes people make handing UI feedback to Claude Code.
Stating the symptom but not the expected result
"The dropdown is broken" tells Bolt something is wrong and nothing about what right looks like. Broken how? Does it not open, open in the wrong place, close too fast, show the wrong options? The agent has to infer your intent, and its inference is often a reasonable fix for a different bug.
Write the symptom and the target in the same breath. "The country dropdown opens below the viewport on mobile, so the last five options are unreachable. It should open upward when there is not enough room below." Now Bolt knows the trigger, the failure, and the correct behavior. It can act instead of interpret. This is the core of what an agent-readable bug report actually contains: current state, expected state, and a pointer to the element.
Pasting a screen recording and expecting Bolt to read it
A video feels like the richest possible bug report. You narrate as you click, the failure plays out on screen, and it took you thirty seconds. But Bolt cannot watch a video. It reads text. A recording is opaque to it, so you end up transcribing the whole thing back into words anyway, which is the work you were trying to skip.
Capture a still instead and write the one line that matters. Still frames convert directly into the markdown Bolt reads, with the screenshot referenced inline and your comment right beside it. If you are weighing the two, the difference between screen capture and screen recording as agent input comes down to whether the agent can parse what you sent.
The version of the report Bolt can act on
Every correction above points the same way: a cropped still, a pin on the exact element, the current state, the expected result, one bug per item. Cobalt Capture produces that without an install or a signup. You capture the screen in a browser tab, type or dictate the comment, and publish. The receiver gets a public link, and Bolt gets clean markdown it can read at the review's markdown URL. Paste that in and the turn goes toward the fix instead of the guessing.
Start a review, capture the broken screen, and hand Bolt something it can act on in one link.