You spot a layout bug on a page Aider just built. The submit button overlaps the footer at narrow widths, and the error text renders below the input instead of beside it. You could describe all that in the terminal from memory, or you could capture the screen and hand Aider a link it can read. The second path takes about two minutes and leaves nothing to memory. Here is the full sequence.
Step 1: Open a review tab
Go to start a new review in a browser tab. Nothing installs. There is no extension to add and no account to create before you begin. The page loads with a Capture screen button and an empty list of items. That is the whole starting state.
Chrome or Edge is the better choice here if you plan to talk through the bug instead of typing, because dictation uses the browser's built-in speech recognition and Firefox does not support it. If you are in Firefox, everything else works; you just type your comments.
Step 2: Capture the broken frame
Click Capture screen. The browser prompts you to share a window or the whole screen. Pick the window showing the bug. The current frame draws to a canvas, and you get a still image to work with. Cobalt Capture is not a screen recorder, so you are capturing a single frame, not a clip. For a bug like the overlapping button, a still is exactly what Aider needs anyway. A video would only make the agent guess at which second matters.
If the full frame has noise around the edges, drag a rectangle to crop to the part that shows the overlap. Cropping is the only image edit, and that is on purpose. You are not drawing arrows or boxes on the screenshot; you point at things with pins and words instead.
Step 3: Pin the exact spot and write the comment
Each captured screenshot becomes an item. Drop a numbered pin on the button that overlaps the footer, then add a second pin on the misplaced error text. Now write the comment: type it, or dictate it out loud if you are in Chrome or Edge. Say what you see, what browser width triggers it, and what the correct behavior is. Something like: "At viewport widths under 480px the submit button sits on top of the footer. Error text should appear to the right of the input, not below it."
Specific comments are what make the difference between a report Aider fixes on the first pass and one it half-fixes. If you want a longer look at what to include, the anatomy of an agent-readable bug report covers the fields that matter. You can add more items for other bugs on the same page, or drop a free-floating comment with no screenshot for something general like "none of the form errors are announced to screen readers."
Step 4: Publish and grab the markdown URL
Click Publish. The review saves and gets a short public URL of the form /r/<slug>. Anyone with that link can read it in a browser, which is useful when a teammate wants to eyeball the bug before it goes to the agent. But the link Aider wants is the plain-text version at /r/<slug>/markdown. That is the same review rendered as clean markdown: your screenshot references, pin numbers, and comments in a structure a coding agent parses without choking on visual noise.
You published with no account, and that is fine. An anonymous review is kept for 30 days. If you want to keep it permanently, sign in with Google or an emailed magic link afterward and the review is claimed to your account. Signing in is free, and so is the whole tool.
Step 5: Paste the link into your Aider session
Switch back to your terminal where Aider is running. Add the markdown URL to the chat the same way you would add any reference, and tell Aider to read it and fix the issues. The agent pulls a structured description with pinned locations instead of a vague sentence you typed from memory. The Aider workflow page covers the agent-specific context, including how the markdown export lines up with what Aider expects as input.
Because the markdown lives at a stable URL, you never copy image files around or paste a wall of text into the terminal. You hand over one link. If Aider fixes the button but misses the error text, you capture the corrected page, add a comment, publish a new review, and paste the next link. That is the feedback loop that keeps a build moving without you jumping between a screenshot tool, a doc, and the terminal.
What the same review gives everyone else
The markdown is for Aider, but the review is not agent-only. A product manager who is never online with you reads the public link. A client gets a PDF or Word export that looks polished. Anyone with the link can post a comment on a specific item, and you can mark each one resolved as the fixes land. The same review served two ways, human-readable and agent-readable, means you capture once and never rewrite the bug for a second audience.
Next time a page comes back wrong, do not narrate it into the terminal. Open a tab, capture the frame, pin the spot, and paste the markdown link. Aider reads a report, not a guess.