Cline reads text. When you paste a vague sentence like "the header looks off on mobile," it burns a turn asking where, or worse, edits the wrong element. A tight markdown bug report changes that. Give it a cropped image, a numbered pin, the current behavior, and the target behavior, and it can open the file, make the edit, and move on in a single pass.
Below is a skeleton you can copy and reuse. Each field exists because Cline needs it to act without guessing. Cut a field only when you know the answer is obvious from the code.
The template
Paste this into a review item comment, or fill it wherever you keep your markdown. Keep one bug per block so each one is a self-contained unit of work.
## Bug: [one-line summary]
**Where:** [route or page, e.g. /checkout, and the component if you know it]
**Pin 1:** [what this pin points at]
**Observed:** [what the screenshot shows happening now]
**Expected:** [what it should do instead]
**Steps to reproduce:** [only if it is not visible in the still]
**Viewport:** [e.g. 375px wide, Chrome, logged in]
That is the whole thing. A Cline session reads it top to bottom and has the location, the visual evidence, and the delta between now and correct. For a fuller breakdown of why each line matters, see what a Cline-ready bug report looks like on the page.
Why each part is there
Summary line. Cline uses this to name the task and to sanity-check its own change. Write the fix outcome, not the vibe. "Submit button overlaps the terms checkbox at 375px" beats "button is weird."
Where. A route plus a component name is the fastest way to point Cline at the right file. If you do not know the component, the route alone still narrows the search. Skip this only when the summary already names the file.
The cropped still. This is the part most reports get wrong. A full-page screenshot forces the agent to hunt for the problem. A tight crop around the broken region removes that ambiguity. Cropping the captured frame is the one image edit you make, and it does more work than any arrow ever would. More on why in why a cropped still beats an annotated live page.
Pin numbers. When a single crop contains two problems, a numbered pin ties each observed-versus-expected pair to an exact spot. Cline reads "Pin 1" and "Pin 2" as an ordered list of edits. Without them, it either merges the two or picks one. See how numbered pins make a reader work through steps in order.
Observed and expected. These two lines carry the actual instruction. Observed describes the current state so Cline can confirm it is looking at the right thing. Expected is the target. If you only write one, write expected, because that is what it builds toward. The fields an LLM needs to fix in one pass come down to this pair plus the location.
Steps to reproduce. Drop this line entirely when the still shows the bug in a resting state. Keep it for anything triggered by an interaction: a hover, a submit, a specific input. Cline cannot see a hover state in a still, so spell it out.
Viewport. Layout bugs are viewport-dependent. "Overlaps at 375px" and "overlaps at 1440px" are different fixes. State the width, the browser, and the auth state so Cline reproduces the same conditions.
Turning the template into markdown Cline can read
The fastest way to produce this is to capture the screen, crop the frame, drop a pin, and dictate the observed and expected lines instead of typing them. In Cobalt Capture that runs in a browser tab with no install and no signup. When you publish, the same review is available as clean markdown a coding agent can read at /r/<slug>/markdown. You paste that URL or its contents into Cline, and the cropped image, the pin, and your notes arrive already in the shape above.
You can also connect Cline directly so it pulls the review without copy-paste. The Cline workflow page covers that setup, and the MCP connection guide walks through the wiring for any agent.
Sizing it for one turn
One turn means Cline finishes the fix before it runs out of context or has to ask a question. Two things keep you inside that budget. First, one bug per block. A block with five unrelated problems becomes a five-file change that spills across turns. Second, trim the still. A crop of the broken region loads a smaller, clearer image than a full page, and it removes elements the agent might touch by mistake. For what to keep and what to cut, read what to crop in and out of a screenshot for an agent.
Fill the template once, publish, and hand Cline the markdown. If it comes back with a question, the missing answer tells you exactly which field to add next time. Capture the first bug now and see how little context a good report actually needs.