You crop a screenshot of a broken button, write "fix the padding here," and the agent adjusts the padding on the wrong button. That happens because the crop gave it three buttons and no way to tell which one you meant. The frame you draw is the instruction. Get it wrong and the agent guesses.
Three rules decide whether the agent lands on the right element. Each one has a clear failure mode you can recognize after the fact.
Include one unique anchor the agent can name
An agent reading a cropped still cannot see your cursor or your intent. It matches your comment against what is visible. If the crop shows a label like "Billing address" or a heading like "Order summary," the agent has a landmark it can find in the code. If the crop is a bare input box with no surrounding text, there is nothing to match. The agent scans for the first input that looks similar and edits that one.
Include at least one piece of unchanging text near the element: a field label, a section heading, a button caption. That text is the address. When you write "the email field under Contact details," the agent has both the label and the relative position.
The failure mode is a crop so tight it removes every word. You get a rectangle of pixels with no name attached. The agent picks a plausible target, changes it, and now you have two bugs instead of one. Widen the crop by 40 pixels until a label is inside the frame.
Cut everything the change does not touch
The opposite mistake is worse in practice. You capture the whole page because it was faster, then type "the spacing is off." The agent now has a header, a nav, a sidebar, a form, and a footer, and one vague sentence. It has no way to know which spacing you mean. It might reformat the nav.
Crop to the element plus its immediate neighbors. Neighbors matter because layout bugs are relational: a button overlaps the input above it, a card sits too close to the one beside it. The agent needs to see both things that are colliding. It does not need the footer three sections down.
A good test: could a stranger who has never seen the page point at the thing you mean using only what is in the frame? If yes, the crop is right. If they would have to ask "which one," the crop is too wide or missing a label. Cropping the captured still is the only image edit Cobalt Capture offers, and that constraint pushes you toward this discipline. You cannot draw an arrow to paper over a bad frame, so you frame it correctly the first time. There is more on why a cropped still beats an annotated live page if you want the longer case.
Pin the exact spot when the crop still has ambiguity
Some screens are dense enough that even a tight, labeled crop leaves two candidates. A settings panel with eight toggles. A data table where the fifth row is the problem. Text alone will not carry it, and cropping to a single row loses the column headers the agent needs.
Add a numbered pin to the screenshot at the exact coordinate, then reference the number in your comment: "Pin 1 marks the toggle that stays on after you disable it." The pin removes the last bit of guesswork. The agent reads "pin 1" as a specific location, not a region. There is a full walkthrough on pinning the exact spot a reviewer means.
The failure mode without a pin is subtle. The agent picks the most prominent element in the crop, which is often not the broken one. Prominent and broken are different properties. A pin overrides prominence with intent.
How the crop reaches the agent intact
Framing only helps if the frame survives the handoff. A screenshot dropped into a chat window loses its comment, its pin numbers, and its ordering the moment you scroll away. The format that carries all of it is the reason this matters: Cobalt Capture publishes each review as clean markdown at /r/<slug>/markdown, with the cropped image, your comment, and the pin references in one block. That is the exact input for turning a screenshot into a prompt the agent can act on without a second round of questions.
Because the crop, the label, and the pin are all in the markdown, the agent reads them as one instruction instead of three loose pieces. No install, no extension, no signup. You open a tab, capture the screen, crop, comment, and publish. The receiver gets a public link and the markdown at the same URL. For the mechanics end to end, the screenshot-to-prompt procedure lays out each step.
A quick check before you publish
Run three questions against every cropped item:
- Is there a label or heading inside the frame the agent can name?
- Have I cut everything the change does not touch, while keeping the neighbors it collides with?
- If two elements still look alike, did I drop a pin on the right one?
Miss the first and the agent has no address. Miss the second and it has too many. Miss the third and it edits the loud element instead of the broken one. All three together produce a frame the agent reads once and fixes correctly.
If you write bug reports this way regularly, the same rules apply to a full agent-readable bug report, where the cropped still is the load-bearing part. Start a new review and crop your next screenshot to a single named element.