A Linear issue titled "button looks wrong" with no screenshot forces a round of questions before anyone writes code. The developer opens the ticket, has no idea which button, on which screen, at what width, and pings you back. A day passes. Here is how to file the issue so that never happens: capture the finding once, write the repro while you are looking at it, and hand Linear a body that stands on its own.
Step 1: Capture the exact frame where the bug shows
Open the failing screen in a browser tab. In another tab, go to start a new review and click Capture screen. The browser prompts you to share the window; pick the tab with the bug and the current frame is drawn to a canvas. No install, no extension, no signup. If the layout only breaks at a narrow width, resize the window first so the broken state is what gets captured.
Drag a rectangle to crop down to the part that matters, or keep the full frame. Cropping is the only image edit, and that is on purpose: a tight crop of the broken pricing card reads faster than a full-page screenshot with the header and footer competing for attention. The outcome of this step is a single still that shows the problem and nothing else.
Step 2: Point at the spot and write the repro
The screenshot becomes an item. Drop a numbered pin on the exact element, the misaligned Save button, the overflowing table cell, the label that wraps. If several things are wrong in one view, add several pins in the order you want the developer to read them. Numbered pins set the reading order so the fix happens in a sequence that makes sense.
Now add the comment. Type it, or dictate it with the browser's built-in speech recognition in Chrome or Edge. Say what you did, what you expected, and what happened. "Set the browser to 375px wide, opened /checkout, the Continue button overlaps the total. Expected it to sit below the total." That is a repro a developer can follow without asking you anything. Firefox does not support dictation, so type there instead.
Add more items if the same review covers more than one bug. Each captured still with its own comment is a separate finding. You can also add a free-floating comment with no screenshot for a note that does not point at anything specific.
Step 3: Publish and get a link
Click Publish. The review is saved and gets a short public URL of the form /r/<slug>. Anyone with that link can read it, no account needed. You can publish with no account at all; an anonymous review is kept for 30 days, and signing in later claims it permanently. The outcome is a stable, shareable record of the finding that lives outside Linear.
Step 4: Create the Linear issue and paste the link in the body
In Linear, create an issue. Title it with the specific symptom and location: "Checkout: Continue button overlaps total at 375px." In the description, paste the review link. Now the developer opens the issue, clicks through, and sees the cropped screenshot, the pin, and your repro in your own words. The whole approach is laid out on the Linear workflow page, including where to put the link so it survives triage.
Set the priority and status in Linear as you normally would. Cobalt Capture does not track workflow states or assignees; it is not a bug tracker. Linear owns triage, assignment, and cycle planning. The review link carries the evidence and the repro. Keeping those two jobs separate means each tool does what it is good at.
Step 5: Handle the back-and-forth without leaving the link
Anyone with the review link can post a comment on any individual item, and you as the owner can mark each comment resolved. So if the developer replies "can't reproduce on my machine," they can ask right on the finding instead of opening a new Linear thread that loses the screenshot context. You resolve comments as they get handled, and the review stays the single source for that bug.
The owner-facing analytics page shows visit counts and visitor geography, so you can tell whether the developer actually opened the link before the issue sits untouched for two days.
When the fix goes to an AI coding agent instead
Same review, different reader. The identical review is available as plain-text markdown at /r/<slug>/markdown, and it exports as PDF and Word too. If your team feeds tickets to Cursor or another agent, the markdown is the format it reads cleanly: the screenshot reference, the pinned element, and the repro steps as structured text. One capture serves the human developer through the link and the agent through the markdown. If you are unsure which output fits which reader, the guide on how markdown screenshots work spells it out.
Next time you spot a bug, do not switch to Linear first. Capture the frame while it is on screen, pin the spot, dictate the repro, publish, and paste the link. The issue writes most of itself, and the developer starts fixing instead of asking what you meant.