You found three layout problems on a staging build. You want them in GitHub with the screenshots showing inline, a clear title, and a needs-triage label so nobody has to guess whether it is ready to work on. Here is the order of operations that gets you there without switching between five tools or pasting image files by hand.
Step 1: Open a review tab and capture the first screen
Go to start a new review in any browser tab. No install, no extension, no signup. Click Capture screen, and the browser asks which window or screen to share. Pick the staging tab. The current frame draws to a canvas.
Drag a rectangle around the broken area, or keep the full frame. The outcome: one still image, cropped to what matters, saved as an item in your review. Cropping is the only edit here, so frame it tight enough that a developer can tell the button from the surrounding chrome.
Step 2: Say what is wrong, per screenshot
With the item selected, type a comment or dictate it using the browser's built-in speech recognition (Chrome and Edge support this; on Firefox you type). Say the specific thing: "The Save button overlaps the footer at 1280px wide." Add a numbered pin on the exact spot so there is no ambiguity about which element you mean.
Repeat capture-and-comment for each problem. Three bugs, three items, each with its own screenshot and note. The outcome after this step: a self-contained list of issues, every one anchored to an image. If dictation gives you longer, clearer notes than typing, dictation often wins for a long bug report.
Step 3: Publish and get the public link
Click Publish. The review saves and gets a short public URL of the form /r/<slug>. Anyone with that link can read the whole thing: screenshots, pins, comments. No login required to view it.
You published without an account? The review is kept for 30 days. Sign in with Google or a magic link within that window to claim the anonymous review permanently. For a recurring GitHub workflow, sign in first so the review is yours from the start.
Step 4: Open the GitHub issue with screenshots inline
This is the step that saves the most time. Instead of downloading each image and dragging it into a GitHub comment box, you push the captured review into an issue in one move. The GitHub integration takes the published review and creates an issue with the screenshots rendered inline in the body, the comments as the description, and a link back to the full review for context.
The outcome: a GitHub issue that reads like a real bug report, not a bare sentence with a link nobody clicks. The person triaging sees the actual screen, the pinned spot, and the note, without leaving GitHub. If you have not set this up yet, walk through how to get a visual bug report into a GitHub issue for free.
Step 5: Label it needs-triage and let GitHub do the rest
Add your needs-triage label (or whatever your team uses) as the issue is created or right after. Cobalt Capture is not a bug tracker and does not manage workflow states, so the triage, assignment, and status live in GitHub where your team already works. The review is the evidence; GitHub is the queue.
From here, the maintainer reads the issue, confirms it is real, and moves it into the sprint. Because the screenshots are inline, triage is a glance, not an investigation. That is the whole point: the reviewer's ten seconds of context become the developer's ten seconds of clarity.
What happens to comments after the issue is open
The published review keeps working on its own. Anyone with the link can post a comment on any individual item, and you can mark each comment resolved as it gets fixed. So the review link becomes a running record next to the GitHub issue: the issue tracks the work, the review tracks the discussion on the exact screen. See who can see and act on items in the guide on resolving review comments without a bug tracker.
You also get an owner-facing analytics page for each review, showing visit counts and visitor geography. Handy when you want to know the maintainer actually opened the link before the issue sat untouched for a week.
When this beats pasting a screenshot by hand
If you file one bug a month, dragging a PNG into a GitHub comment is fine. The workflow above pays off when you are filing several at once, when the reviewer is a designer or PM who should not be wrestling with GitHub image uploads, or when you want the pinned spot and the note to travel with the image instead of getting lost in a chat thread.
QA teams filing a batch after a build should look at the QA bug report flow, and if you are handing UI issues to a coding agent as well as a human, the same review is available as clean markdown at /r/<slug>/markdown for the agent to read. Start your next batch on the Cobalt Capture home page and file the first issue before the build changes under you.