You have a staging URL open, a list of things that look wrong, and twenty minutes before the next call. You want to send something the developer (or the agent doing the work) can read top to bottom and fix without asking you to clarify. Here is the exact sequence, from cold tab to exported markdown file.
Step 1: Open a new review in a browser tab
Go to start a new review. Nothing installs. There is no extension to approve, no desktop app to update, no signup gate. The page loads and you are looking at an empty review with a Capture screen button. If you want the review tied to your account later, you can sign in with Google or a magic link, but you do not need to do that to start. Anonymous reviews are kept for 30 days, so you can publish first and claim later.
Outcome: an empty review, ready to receive screenshots and comments.
Step 2: Capture the first screen
Click Capture screen. The browser prompts you to share a window, a tab, or your whole screen. Pick the one with the thing you want to talk about. Cobalt Capture grabs the current frame and drops it into the review as an item. It is a still image, not a video. If the frame includes more than you need (a noisy sidebar, a second monitor), drag a rectangle to crop down to the part that matters. That crop is the only image edit; there is no drawing arrows or scribbling boxes on the still.
Outcome: one screenshot item in the review, cropped to the area you care about.
When to use a pin instead of a tighter crop
If the issue is one specific element on a screen that otherwise needs full context (a misaligned label inside a long form, say), keep the wider crop and drop a numbered pin on the exact spot. Pins are useful when you have two or three problems on one screenshot and want each comment tied to a location. For a single issue on a busy page, a pin plus a one-sentence comment beats a tight crop that loses the surrounding context.
Step 3: Add a comment by typing or by talking
Click into the comment field on the item. Type what you want to say, or click the microphone and dictate using the browser's built-in speech recognition. Dictation works in Chrome and Edge. Firefox users type. Write the way you would write a Slack message to the person who has to fix it: what you expected, what you saw, where you were. "Submit button on /signup stays disabled after the password field validates. Expected it to enable once both fields are green." That is enough.
Outcome: each screenshot has a short, specific comment attached. No buried context, no "see attached."
Step 4: Add free-floating notes that do not need a screenshot
Some things are not visual. "Whole flow assumes the user already has a workspace; first-time path is broken." Add those as free-floating comments with no screenshot. They show up in the markdown alongside the captured items, in order. Use them for summary statements at the top, or for anything that applies across the review rather than to a single screen. If you find yourself writing five free-floating notes in a row, you might be writing a doc instead of a review; that is fine, but consider whether a quick capture of the relevant screen would carry the point more cheaply.
Step 5: Repeat until the review is complete
Capture the next screen. Crop or pin. Comment. Keep going until you have walked the parts of the product you set out to cover. A useful review is usually four to twelve items. If you are at thirty items, you are doing two reviews; publish this one and start a second. Order matters in the export, so capture roughly in the order a reader should follow.
Step 6: Publish and grab the links
Click Publish. The review saves and gets a short public URL of the form /r/<slug>. Anyone with the link can open it in a browser, scroll the screenshots, and read the comments. The same review is available as plain markdown at /r/<slug>/markdown, and you can export a PDF or a Word document from the review page. One review, multiple shapes, depending on who is reading.
Outcome: a public link for humans, a markdown URL for anything that prefers text, and downloadable PDF or Word files for people who want an attachment.
Step 7: Send the right format to the right receiver
Send the public link to a teammate or client; they click and read. Paste the markdown URL (or the markdown itself) into Cursor, Claude Code, or any other coding agent that reads text. The screen capture to markdown output is structured so an agent can map each comment to the screenshot it belongs to. If you want more on why markdown beats video for this, see why Loom doesn't work with agents and how markdown screenshots work.
Step 8: Track replies and mark items resolved
Anyone with the link can post a comment on any individual item. As the owner, you mark each comment resolved when it is handled. The review's analytics page shows visit counts and visitor geography, so you know whether the developer actually opened the link before saying "got it." If you are running this loop on every build, look at the feedback loop for vibecoding for the version that keeps a tight cycle between reviewer and agent.
Next review: open a tab, capture, comment, publish. The whole loop is meant to take less time than writing the bug ticket would have.