Walk staging, ship the issues as markdown

This page is for engineers and QA owners who walk a staging build before it gets promoted to production. The staging site review is its own discipline, not exploratory testing, not a design review, just "click through the whole flow and write down what's wrong before this merges." It fits the broader pattern on the use cases for visual product feedback hub: many small findings across a flow, all of them visual, all of them needing to land on a developer's desk in a state someone can act on.

The problem

You walk the staging build before promotion. You find eight things. The header crops on mobile, the empty state shows the wrong copy, the form validation fires too eagerly, the loading spinner sticks after a 304, and four more. By the time you finish the pass, half the findings are screenshots in a Slack thread with one-line captions, and the other half are still in your head. The dev sits down two hours later and gets to four of them. The source URLs are gone because the screenshots don't carry them. The repro context drifts because "this looked broken" loses meaning by the next morning. The build merges with five of your eight findings still open and nobody can reconstruct what they were.

The CobaltCapture workflow

Open the staging URL in one tab. In another, hit Capture screen at cobaltcapture.com and pick the staging window. Drag a box around the first broken region, the cropped header, the misaligned button, whatever caught your eye. Hit Dictate and talk: "Submit button overflows at 380px on iOS Safari, only happens after the email field is focused, this should respect max-width on .btn-primary." Move to the next page in the flow, capture again, dictate again. Every item gets stamped with the source URL of the page you captured from, so the repro location is permanent.

When you're done with the pass, hit Publish. You get back a URL like cobaltcapture.com/r/<slug>. That single URL is the staging review. Drop it in the PR description so the reviewer sees the open issues inline. Drop it in the Slack thread so the team has one canonical reference instead of eight messages. Paste it into the prompt you send to your coding agent. The same artifact, three audiences, no translation step.

What the output looks like

The published review is a markdown document. Each finding is its own section with a heading, a cropped screenshot, the source URL of the page it occurred on, and your dictated commentary as the body. The format opens cleanly in a GitHub PR description, a Linear ticket, or an AI agent's context window:

# Staging review, 1.7.0 release candidate

## Submit button overflows on iOS Safari

Source: https://staging.example.com/checkout

![Submit button overflowing container](https://cobaltcapture.com/r/abc12345/img/1.png)

The submit button overflows its container at viewport widths under
380px on iOS Safari 17. Reproduces after the email field gets focus
(keyboard accessory pushes the layout). Should respect the existing
max-width: 100% on .btn-primary. Did not reproduce on Chrome Android
at the same widths.

## Empty state shows pre-launch copy

Source: https://staging.example.com/dashboard

![Empty dashboard with old onboarding copy](https://cobaltcapture.com/r/abc12345/img/2.png)

The dashboard empty state still references the old "join the waitlist"
flow. Should be the new "create your first project" CTA per the 1.7
onboarding spec. Strings are in i18n/en/dashboard.json under
empty_state.title and empty_state.cta.

## Validation fires before blur

Source: https://staging.example.com/signup

![Email field showing error mid-typing](https://cobaltcapture.com/r/abc12345/img/3.png)

Email validation triggers on every keystroke instead of waiting for
blur. The shake animation also runs on each invalid keystroke, which
is jarring. Debounce or move to blur. Regression from the validation
refactor in #2418.

Why this beats Slack + screenshots

The default flow is screenshot-and-Slack, and it has two failure modes the markdown alternative does not.

First, the screenshots lose their source. A screenshot of a broken header in a Slack thread is a picture of a broken header. It is not a record of which staging URL the header was broken on, which build, or which route. Three days later, when someone asks "which page was the header issue on?", the screenshot is still there and the answer is not. CobaltCapture stamps the source URL on every item.

Second, the prose drifts toward terse. In a Slack thread you type "submit button is broken" because typing a paragraph feels rude. In CobaltCapture you talk for twenty seconds and get a paragraph, which viewport, which browser, which interaction, what the expected behavior is. That extra signal is what makes the difference for a coding agent like Cursor reading your review and producing the fix on the first pass instead of asking three clarifying questions.

Who this is for

Engineering teams running staging review checkpoints before promotion to production. QA owners responsible for the pre-merge or pre-release pass. Release engineers walking RC builds. Anyone whose job is "click through the whole staging build, find what's wrong, hand it to the people who fix it." If your findings currently live in a Slack thread that nobody can find a week later, the markdown URL is the format that fixes it.