A developer opens your bug report, sees one screenshot with four things circled, and has no idea which one to fix first. That is the moment a report stops being useful. Numbered pins solve it: they turn a busy screen into a sequence, so the person reading knows the exact order to work through what you found.
Pins in Cobalt Capture are numbered dots you drop on a captured still. Each one points at a specific spot. The number is not decoration. It is the reading order. Used well, a single screenshot becomes a short checklist a developer can run down from 1 to 4 without asking you a single question. Below are the practices that make that happen, and what breaks when you skip them.
Number pins in the order the developer should act, not the order you noticed things
You will spot problems in whatever order your eye travels the page. Do not preserve that order. Renumber for the person doing the work.
The usual rule is reproduction order. Pin 1 on the field the user fills first, pin 2 on the button they click, pin 3 on the error that appears, pin 4 on the console message that confirms it. A developer reading 1 through 4 walks the same path the bug takes. They do not have to reconstruct the sequence from your prose.
The failure mode is a screenshot where pin 1 sits on a footer typo and pin 3 sits on the broken submit button. The developer fixes the typo, thinks they are making progress, and only later realizes the real bug was buried under a higher number. Order by severity or by reproduction steps, never by the accident of where you looked first.
One comment per pin, and write the comment to match the number
Every pin gets its own comment tied to its number. Pin 2 says what is wrong at pin 2 and nothing else. Do not write one paragraph that covers all four spots and leaves the developer matching sentences to dots.
This is where dictation earns its place. Point at the spot, drop the pin, and say what you see. In Chrome or Edge you can talk through all four pins faster than you can type one. If your reviewer is on Firefox, they type instead, since the browser's speech input is not available there. Either way, the discipline is the same: the comment for pin 3 describes pin 3.
When comments do not match pins, the developer reads "the spacing is off and the label is wrong and it crashes on submit" while staring at three dots, guessing which sentence belongs to which. That guessing is exactly the cost a bug report is supposed to remove. Keeping it one-to-one is a core part of the QA bug reports workflow, and it is what makes the report readable at a glance.
Use pins for spots on one screen, separate items for separate screens
Pins live on a single still. If your bug spans three screens, do not try to cram all of it onto one screenshot with eight pins scrambling across it. Capture each screen as its own item, then pin within each.
So a login bug might be item 1 (the sign-in form, two pins) and item 2 (the error page it lands on, one pin). Each item reads cleanly on its own. The developer moves through items in order, and within each item follows the pins in order. That nesting keeps a multi-step bug organized without a project tool.
The failure mode here is one overloaded screenshot stitched from mental notes about three different pages, with pins pointing at things that are not even visible in the frame. The developer cannot see what pin 5 refers to because it happened on a screen you did not capture. If it is a different screen, it is a different item. Pinning the exact spot only works when the spot is actually in the picture, which is the same reason a cropped still beats an annotated live page.
Keep the pin count low and crop out what you are not pinning
Four pins on a full-page screenshot is fine. Ten pins on a dense dashboard is a wall the developer will bounce off. If you find yourself past six, split the screen into two items or crop to the region that matters.
Cropping is the only image edit Cobalt Capture offers, and that constraint is a feature. Crop the still to the panel with the bug before you pin it. Now pin 1 and pin 2 sit in a tight frame with no navigation, no sidebar, no unrelated widgets competing for attention. The developer's eye goes straight to what you flagged. There is more on that trade-off in the notes on what to crop in and out.
Too many pins on too wide a frame produces a report nobody triages. It looks thorough and reads as noise. Fewer pins on a tighter crop gets fixed faster.
Publish, then send the link so the order travels with it
Once your pins and comments are set, publish. The review gets a short public URL, and anyone with the link can read the numbered sequence exactly as you laid it out. No install, no signup, no account needed to open it. The developer reads 1, 2, 3, 4 in the browser and can comment on any pin to ask a question, which you can mark resolved when it is fixed.
The same review is available as clean markdown and as a PDF or Word export, so the ordered checklist reaches a person or a coding agent in whatever form fits. The numbers carry through every format. If your team wants a repeatable structure to drop pins into, start from a bug report template your team can reuse and open a new review the next time something breaks.