You finished a round of QA on the staging build. The client wants a tidy summary they can read on their phone. Your developer wants the same notes in a form they can paste straight into an editor or feed to a coding agent. You do not want to write the feedback twice.
One captured review can serve both. The public link at /r/<slug> reads like a polished document; the same review at /r/<slug>/markdown is plain markdown a developer or agent can act on. Here is the exact sequence.
Step 1: Open a tab and start the review
Go to Cobalt Capture and click Start a new review. No install, no extension, no signup. The browser tab is the whole tool. If you want the review to live past 30 days, sign in first with Google or a magic link; otherwise carry on as a guest and claim it later.
Outcome: an empty review is open in the tab, ready to accept screenshots and comments.
Step 2: Capture the first screen
Click Capture screen. The browser asks which window or screen to share. Pick the staging tab. The current frame is drawn to a canvas. Drag a rectangle around the part you want to keep, or skip the crop to use the full frame.
Outcome: a still image becomes the first item in the review. No video, no recording, just the frame you chose. If you want the longer rationale for that, the screen capture vs screen recording guide covers it.
Step 3: Add a comment the client and developer both understand
Click into the comment field on the item. Type, or hit the dictate button and talk through what is wrong. Speech recognition uses the browser's built-in Web Speech API in Chrome and Edge; in Firefox you type.
Write each comment so it works for both audiences. "The Save button on the billing form does nothing when the card field is empty; expected a red helper under the field" gives the client confidence you saw the problem and gives the developer the reproduction and the expected behavior in one sentence. Vague notes like "this is broken" cost you on both sides; the common mistakes are worth a quick read if your team writes those a lot.
Outcome: the item has a screenshot and a clear, actionable comment.
Step 4: Pin the exact spot
If the issue is one button among many, drop a numbered pin on it. Pins point at a coordinate on the still without drawing arrows or marker scribbles all over the image. They render in the public link and they appear in the markdown export as numbered references.
Outcome: the developer can map each numbered pin to a specific element. The client sees the same numbers next to the same comments.
Step 5: Add the rest of the items
Repeat capture, comment, pin for each issue. Add free-floating comments (no screenshot) for things that are not visual: "the contact form submission email is going to spam," or "please confirm the analytics tag fires on signup." Order matters; items appear top to bottom in both outputs, so put the blockers first.
Outcome: a complete review of, say, eight to fifteen items, mixed screenshots and notes.
Step 6: Publish
Click Publish. The review gets a short URL of the form /r/<slug>. Anyone with the link can read it; no login on their end.
Outcome: one canonical review, two output formats from the same source.
Step 7: Send the client the public link
Paste /r/<slug> into your email or Slack to the client. They open it on whatever device they have. They see the screenshots, the pins, and your comments laid out like a report. If they have something to say back, they post a comment on the specific item, and you mark it resolved when it is fixed. This is how a client feedback loop runs without making the client sign up for anything.
If the client needs a file rather than a link (procurement, legal, archives), export the same review as PDF or Word from the review page and attach it.
Outcome: the client has the review in the form they prefer.
Step 8: Send the developer the markdown URL
Append /markdown to the same slug and send that to the developer: /r/<slug>/markdown. It is plain markdown, with each item as a section, the comment as prose, and the screenshots as image links. A human reads it fine in a code editor preview. An AI coding agent reads it without choking on video or annotated PNGs. If your developer uses Cursor or Claude Code, they paste the markdown URL into the chat and the agent picks up every item in order. The longer pattern is in how to give feedback to an AI coding agent.
Outcome: the developer has the same eight to fifteen items, but in a format their tools can parse.
Step 9: Track replies and resolutions in one place
When the client comments on item three and the developer pushes a fix for item three, mark it resolved on the review. The client sees it crossed off when they refresh; the developer sees the same state in the markdown next time they pull it. The owner-facing analytics page tells you whether the client actually opened the link, and from where.
Outcome: one review, one source of truth, two audiences served. Write the feedback once. If you want to see what a finished review looks like before you start, the staging site review page walks through a worked example.