Claude Code is patient. It will read whatever you paste, make a confident plan, and start editing files. That is exactly the problem when your feedback is fuzzy: the agent does not stop and ask, it guesses. The mistakes below are the ones that most often turn a ten-minute fix into a forty-minute round trip of reverts and re-prompts.
Pasting a Loom link and expecting the agent to watch it
It is tempting because recording a video is the fastest thing a human can do. You talk through the bug, drop the URL into the chat, and move on. Claude Code cannot watch the video. It sees a string that looks like a URL and either ignores it or invents what the video probably showed. Neither outcome is good.
The correction is to send still frames with written context attached to each one. Capture the broken state, write the sentence you would have said out loud, and hand the agent text it can actually read. There is more on why this fails specifically in why Loom doesn't work with agents, but the short version is: if your feedback is not text or an image the model can parse, treat it as missing.
Describing the bug without naming the route or the component
"The header looks wrong on the pricing page after you log in" feels specific when you write it. To the agent it is three guesses stacked on top of each other: which header component, which pricing route, which auth state. Claude Code will pick one and start grepping. If it picks wrong, you get a confident diff against the wrong file.
Fix this by naming the route (/pricing), the viewport (1440 wide, logged in as a Pro user), and the visible element (the sticky SiteHeader, not the in-page section heading). One screenshot with a numbered pin on the offending pixel and a sentence saying "this nav item wraps to a second line when the user's email is longer than 28 characters" gives the agent a single file to open.
Sending one giant screenshot with ten issues on it
You took a full-page capture, you can see five spacing problems and a broken icon, so you paste it once and list the issues underneath. The temptation is obvious: one image, one upload, done. Claude Code now has to map each sentence in your list back to a region of the image, and it will conflate them. Issue three gets fixed using the coordinates of issue five.
Split the capture. Each distinct problem becomes its own item with its own cropped screenshot and its own comment. This is the model the Claude Code workflow is built around: a review where each item is a small, self-contained instruction. If you want the full pattern for structuring those items, structured feedback for LLMs walks through the shape.
Leaving out what the correct behavior should look like
Bug reports written for humans often stop at "this is broken." A teammate fills in the intent from memory. Claude Code has no memory of your product. Told only that the modal "looks off," it will recenter it, restyle it, or rewrite the close button, any of which it can defend as a reasonable interpretation.
State the expected result in the same sentence as the observed one. "The Save button is disabled after I fill every required field. Expected: button enables as soon as the last required field has a non-empty value." Two clauses, no ambiguity. The anatomy of an agent-readable bug report has more examples of this shape, but the rule is just: observed, then expected, every time.
Pasting screenshots into chat instead of sending a markdown review
Dragging a PNG into the Claude Code chat works for one issue. By the third screenshot the conversation is a wall of images with comments scattered between them, and the agent loses track of which note belongs to which picture. You also lose the record: nothing is saved outside that chat session.
Send a single markdown document with the screenshots inlined and the comments anchored to each one. Capture the review in the browser, publish it, and paste the /r/<slug>/markdown URL or the markdown body into Claude Code. The agent reads it top to bottom in order. The same review is a public link you can share with a designer, a PDF you can attach to a ticket, and a Word doc for the client. For the mechanics of producing that document, see the guide on getting feedback into Claude Code or the broader explainer on markdown screenshots.
What to do next time you spot a UI bug
Open a tab, start a new review, capture the broken state, crop to the part that matters, drop a pin, and write the observed-versus-expected sentence while it is fresh. Publish, copy the markdown URL, hand it to the agent. No install, no extension, no signup. The receiver, human or model, gets something they can act on instead of something they have to interpret.