You found a bug on the checkout page. The submit button stays disabled after you fill every field. You want Cline to fix it, and you want a human teammate to see the same report. Here is exactly what you capture, what the published review looks like, and what Cline reads out of it.
The capture, step by step
Open the checkout page in a browser tab. Click Capture screen, pick the tab, and the current frame draws onto a canvas. Drag a rectangle around the form so the crop shows the four filled fields and the greyed-out button, nothing else. That crop becomes item 1.
Drop a numbered pin on the submit button and one on the email field, because the button only breaks after email loses focus. Then add the comment. You can type it or dictate it with the browser's built-in speech recognition. Here is the comment you write:
All four fields are valid but Submit stays disabled. Pin 1 is the button. Pin 2 is the email field. The button re-enables only if I click back into email and out again. Expected: enabled as soon as all fields pass validation. Chrome 122, macOS.
Add a second item, a free-floating comment with no screenshot: "Also happens on the billing step, same pattern." Click Publish. The review saves and gets a short URL like /r/checkout-submit-bug. No install, no signup. If you want to keep it past 30 days, sign in later and it is yours permanently.
What the published review shows a person
Open the link and you see the cropped screenshot with two numbered pins sitting on the exact spots you meant. Below it, your comment in full. Then the second item as a plain note. A teammate reads it top to bottom in about fifteen seconds and knows precisely which element misbehaves and how to reproduce it. They can post a reply on either item, and you can mark each one resolved once the fix lands. Same review, also downloadable as a PDF or Word doc if someone wants it in a ticket or an email.
The pins do the heavy lifting here. Instead of writing "the button near the bottom," you have a pin pointing at the exact spot and a number in the comment that ties to it.
What Cline reads out of the same review
Add /markdown to the URL and the same review renders as plain text. That is the format Cline consumes. It looks like this:
# Review: checkout-submit-bug
## Item 1 (screenshot)
Pins: 1 = Submit button, 2 = Email field
All four fields are valid but Submit stays disabled. Pin 1 is the button. Pin 2 is the email field. The button re-enables only if I click back into email and out again. Expected: enabled as soon as all fields pass validation. Chrome 122, macOS.
## Item 2 (comment)
Also happens on the billing step, same pattern.
Notice what Cline gets: a heading structure it can parse, the screenshot referenced by file, the pin legend spelled out, the expected behavior, and the environment. No video to transcribe, no chat scrollback to reconstruct. You paste that markdown into Cline, or point it at the URL, and the report is already structured the way an agent wants it. Compare that to handing an agent a screen recording, which it cannot read at all.
Why the pin legend matters to the fix
The line Pins: 1 = Submit button, 2 = Email field is the part that turns a vague complaint into a targeted change. Cline now knows the bug lives in the interaction between the email field's blur event and the button's disabled state, not in the whole form. That is the difference between a fix that touches one handler and a rewrite of the validation logic. If you want to see the pattern generalized, the anatomy of an agent-readable bug report breaks down each element.
One review, two audiences, no rework
You did the capture once. The person-facing link and the markdown are the same review rendered two ways, so there is no separate step to "prepare something for the agent." That is the whole point of treating feedback as an artifact rather than a message: write it once, and both the developer and the tool read from the same source.
If your reviewer is on Firefox, dictation is off, so they type the comment instead; everything else works the same. And if you want the fuller mechanics of getting output in front of a tool, the guide on how to give feedback to an AI coding agent covers the paste-versus-link choice.
Reproduce the example yourself: start a new review, capture your own stuck button, and open the /markdown version to see what Cline would read.