You paste a screenshot into Cursor, type "fix the header," and hit enter. Cursor edits three files, one of them the wrong one, and now you have a diff to untangle. The problem is rarely the model. It is the feedback. Cursor reads what you hand it and fills the gaps with guesses, so vague input produces confident, wrong edits.
Here are the mistakes that make that happen, and the fix for each.
Pasting a screenshot with no text
An image alone tells Cursor what the screen looks like, not what is wrong with it. It is tempting because dropping in a picture feels like it carries the whole story. To you it does. You know the button is 4px too low and the wrong shade of blue. Cursor sees a button.
Add the words. Say what is wrong, where, and what correct looks like: "The Save button sits below the Cancel button on the settings modal; they should be aligned on the same row, Save on the right." A screenshot plus a specific sentence is worth ten screenshots alone. If you are not sure how much detail Cursor needs, the guide on getting feedback into Cursor walks through what actually lands.
Cropping so tight Cursor loses the location
The opposite mistake. You crop down to just the broken element to keep things clean, and now Cursor has a red error box floating with no page around it. It cannot tell if that is the checkout page, the login form, or a settings panel.
Keep enough of the frame to place the problem. A pinned spot on a fuller screenshot beats a tight crop with no context. When you capture with Cobalt Capture for Cursor, drop a numbered pin on the exact element and leave the surrounding layout visible so Cursor can match it to a route or component.
Bundling five issues into one comment
You walk a page and see problems everywhere, so you write one long paragraph covering the header, the footer, a broken link, and a typo. It feels efficient. Cursor treats it as a single task, tries to satisfy all of it in one pass, and drops the parts it weighs as less important.
One issue per item. Each screenshot and its comment should describe one problem. Cursor can then work through them in order and you can see, comment by comment, which are done. This is the same discipline that keeps UI feedback readable for any agent, not just Cursor.
Describing symptoms instead of the actual error
"The page is broken" or "it does not work" gives Cursor nothing to grep for. It is tempting because that is genuinely how the bug feels to you. But Cursor searches your codebase for concrete strings: an error message, a component name, a route.
Include the real text. If the console says Cannot read properties of undefined (reading 'map'), put that exact string in the comment. If a field is labeled "Billing email" in the UI, use that label so Cursor can find it in the source. Specific strings turn a hunt into a lookup.
Handing Cursor a video or a Loom link
A recording feels thorough because it shows everything you did. But Cursor cannot watch it. There is no timeline it can scrub, no frame it can read. You are asking it to act on a format it cannot parse, so it either ignores the link or you end up transcribing the video yourself.
Send stills with text instead. Cobalt Capture is a still-frame tool by design, and the reasons it fits an agent better than a recording are laid out in why a Loom video does not work as agent input. Capture the frame that shows the problem, write what is wrong, and Cursor has something it can read on the first pass.
Pasting formatting Cursor has to fight through
You copy feedback out of a doc or a chat thread and paste it in with stray bullets, quote characters, and half-formatted lists. Cursor spends part of its attention parsing your formatting instead of the content. It is tempting because copy-paste is fast, but messy input costs you on the other end.
Give it clean markdown. Every published review has a plain-text markdown version at /r/<slug>/markdown, structured as headings and list items an agent reads without stumbling. Paste that link or the markdown itself. The mechanics are covered in markdown screenshots explained, and it is the difference between Cursor reading your intent and reconstructing it.
Skipping the priority order entirely
You send fifteen items and assume Cursor knows the login bug matters more than the footer spacing. It does not. Without an order, it works top to bottom or by whatever it judges easiest, and the thing you actually need shipped waits behind cosmetic fixes.
State the order plainly. "Fix items 1 and 2 first, they block checkout. The rest are polish." One line saves you from reviewing edits in the wrong sequence. When the same review also goes to a human, one review can serve both, as shown in one review, two links for client and developer.
The correction, in one pass
Capture the frame with enough context to locate it, pin the exact spot, write one specific problem per item with the real error text, order them, and hand Cursor the markdown link. That is a review Cursor can act on without guessing. Start a new review and hand your next round of feedback to Cursor in a form it can actually read.