TL;DR

  • The QA tax is not finding the bug. It is retyping the reproduction into Jira or Linear after you already watched it happen.
  • Record the failing flow once with Clipy. The recording's AI summary, its extracted "Fix checklist," and its click-anchored key moments are the reproduction.
  • Append .md to any watch URL and the recording becomes a plain-text repro that the assigned engineer reads instead of re-watching, and that engineering's AI coding agent reads directly too.
  • On the Mac desktop app and the Chrome extension's recordings, key-moment frames are pinned to the exact click coordinate that failed. That is the difference between "a button was broken" and "this button, at this pixel, on this step."
  • This is the QA-to-engineering handoff angle. If you want the version where a developer records their own bug, read the developer's side of this workflow.
  • Free, no watermark, no viewer signup. Agents connect through the read-only Clipy MCP server.

The real QA tax is transcription, not testing

Here is a day most QA engineers recognize. You are grinding through a regression pass on staging, you hit a broken flow, and you reproduce it three times to be sure. The hard part is done. Then the second job starts: you open Jira, you create a ticket, and you begin retyping what you just watched. "Log in as a standard user. Go to Settings. Click the Billing tab. Change the plan to Annual. Click Save. Observe the spinner never resolves." You screenshot the frozen state, you note the browser and the build, you attach the console log, and you assign it to the engineer who owns that area.

None of that typing found the bug. It is pure transcription. You are converting something you saw into English so that someone else can convert that English back into something they can see. And the translation is lossy in both directions. You forget the exact order you clicked. You describe "the Save button" when there are two. You write "it hangs" when what you mean is a specific request that never returns. The engineer reads your paragraph, forms a slightly wrong mental model, and asks a clarifying question that costs a day of round-trip.

That round-trip is the tax. It is not that QA is slow at finding defects. It is that the handoff format, a human-written paragraph of steps, is the worst possible medium for something you already captured perfectly the moment it happened. You watched the exact reproduction. Then you threw the recording of it away and rewrote it from memory.

The fix is not "write better repro steps." The fix is to stop writing them at all, and hand engineering the recording as the repro.

The recording is the reproduction, not a video someone re-watches

The instinct against "just attach a video" is correct, and it is worth being honest about why. A raw screen recording is a bad bug artifact. It is a two-minute file the engineer has to open, scrub through, and re-transcribe into their own head, which is exactly the transcription tax again, just moved one desk over. Nobody wants to sit and watch a QA clip at 1x hunting for the moment the button failed. So teams go back to typing paragraphs, and the tax stays.

Clipy breaks that trade-off by turning the recording into something you read instead of watch. Every recording gets a watch page at a URL like https://clipy.online/video/<id>. Append .md to that URL, https://clipy.online/video/<id>.md, and you get a plain Markdown twin of the recording. That twin is not a transcript dump. It contains, in order:

  • A short preamble noting that this document is meant to be read by an AI agent.
  • The recording title.
  • An AI-generated summary of what happened in the recording.
  • For a bug or feedback recording, a "Requested changes" / "Fix checklist" list, the actual repro steps and the change being asked for, extracted from what you did and said.
  • Key moments: a timestamped list where each moment has a caption, a frame image, and, where available, the on-screen coordinate of what was clicked.
  • The full timestamped transcript of anything you narrated.

Put those pieces together and you have a reproduction that reads like the ticket you would have written by hand, except you did not write it and it does not drift from what actually happened. The summary is the "what." The Fix checklist is the numbered steps. The key moments are the screenshots with the exact control marked. The transcript is your running commentary if you narrated as you went. Engineering opens one link and has all of it.

Why click-anchored key moments matter for a repro

The part that turns a decent bug report into an unambiguous one is the key moments, specifically the ones anchored to a click coordinate. A key moment is a captured instant with a caption, a still frame, and, on supported recorders, the x/y pixel of the interaction. When a moment has coordinates, Clipy burns a red-and-white marker into the frame at that exact spot. So "the Save button was broken" becomes a frame that literally has a target painted on the pixel you clicked, with a caption describing the step.

For a QA repro this is the whole ballgame. Half the clarifying questions engineering asks are "which button?" and "where exactly?" A page with two Save controls, a modal that opens over another modal, a dropdown item three rows down, these are the cases where a written step is ambiguous and a marked frame is not. The engineer does not have to guess which element you mean. It is pinned.

Two honest caveats, because a repro built on a false claim is worse than none. Click coordinates are captured on the Mac desktop app and on the Chrome extension's recordings. If you record with the plain in-browser web recorder, you still get the summary, the Fix checklist, the key-moment frames, and the transcript, but no click coordinates, because that surface does not have access to the pointer stream. For a reproduction where pinning the exact failed control matters, do the capture in the desktop app or the extension. It is worth the small setup once.

Each key moment also records where its coordinate came from, so nothing is invented. The source field is click when it is a real pointer event, hover when it is inferred from where the cursor rested, or fused when signals were combined, each with a confidence value. If Clipy is not sure where something happened, it says so rather than dropping a marker on a guess.

How a QA files a bug with a recording, step by step

Here is the full flow, replacing the "reproduce, then retype" loop with "reproduce once, hand over the link."

  1. Reproduce the failure while recording. Start a Clipy recording in the Mac app or the Chrome extension, then run the flow that breaks. Do it the way you would demonstrate it to a colleague standing behind you. Narrate if it helps ("I'm on build 4821, staging, changing the plan to Annual now"); the narration lands in the transcript.
  2. Stop and let Clipy process. On stop, the recording uploads and is transcribed and summarized automatically. You do not do anything for this step.
  3. Skim the generated summary and Fix checklist. Open the watch page and read the AI summary and the extracted "Fix checklist." This is your quality gate: confirm the steps are captured correctly and the observed-vs-expected is clear. If you want to add the expected behavior in your own words, do it here; you are editing a nearly-finished report, not writing one from scratch.
  4. Grab the .md link for engineering. Take the watch URL and append .md. That is the reproduction. Paste it into the Jira/Linear ticket alongside the normal fields (build, environment, severity). You can paste the human watch link too so anyone can watch the clip, but the .md link is the one the engineer and their agent will actually read.
  5. Assign it to the engineer who owns the area. Same as always. The difference is what they receive: not your paragraph, but the recording's own structured repro.

The step that disappears is "spend ten minutes reconstructing the exact click order in prose." You reproduced it once. The recording did the writing.

Regression repros and flaky failures, the two hardest cases

Two categories of bug are where written repro steps fail QA the hardest, and where recording-as-repro earns its place fastest.

Regressions. A regression is "this used to work." The engineer's first question is always "are you sure, and what exactly did you do?" A recording answers both without a conversation. It shows the current build failing the flow, with the marked frame at the step that broke and the build number in your narration. When you re-run the regression pass after the fix ships, you record the same flow again; now you have a before and an after as two links, not two paragraphs you have to keep straight. For a regression suite, the recording is also self-documenting: six months later, "what was the repro for CLIP-1421" is a link that still shows exactly what failed, not a stale prose description of a UI that has since changed.

Flaky and hard-to-describe failures. The worst tickets are the ones where the failure is timing-dependent, order-dependent, or just weird, the kind you can barely put into words. "Sometimes if I click Save twice quickly the second confirmation dialog appears behind the first one" is a sentence that will get bounced back to you as "cannot reproduce." A recording of the one time it did happen, with the two dialogs captured as key-moment frames, ends that argument. You do not have to describe the indescribable. You caught it once, and the catch is the evidence. When it is truly intermittent, recording your whole test run and trimming to the moment it breaks means you never have to reproduce a flake twice just to document it.

What engineering (and its AI agent) actually receives

When the assigned engineer opens the .md link, this is roughly the shape of what they read. This is a QA repro for a billing-save hang, on staging:

NOTE FOR AGENTS: This document describes a screen recording.
It is structured so an AI coding agent can read the reproduction directly.

# Billing "Save" hangs when switching to Annual (staging, build 4821)

## Summary
A QA tester reproduces a hang on the Billing settings page. Logged in as
a standard user on staging, they open Settings, switch to the Billing tab,
change the plan from Monthly to Annual, and click Save. The Save button
enters a loading state and never resolves; no success toast, no error.
The underlying PATCH request to /api/billing/plan is issued but no
response is observed within the recording.

## Fix checklist
- [ ] Reproduce: Settings > Billing > change plan Monthly->Annual > Save
- [ ] Save button enters loading state and never resolves
- [ ] Expected: plan updates and a success confirmation appears
- [ ] Environment: staging, build 4821, Chrome, standard (non-admin) user

## Key moments
- t=00:11 "Billing tab open, plan shows Monthly"
  frame: https://clipy.online/.../frame-0011.png  (x=642, y=318, source=click)
- t=00:19 "Plan changed to Annual in the dropdown"
  frame: https://clipy.online/.../frame-0019.png  (x=640, y=402, source=click)
- t=00:24 "Clicked Save; button shows spinner"
  frame: https://clipy.online/.../frame-0024.png  (x=712, y=468, source=click)
- t=00:41 "Spinner still active 17s later; no toast"
  frame: https://clipy.online/.../frame-0041.png

## Transcript
[00:03] Okay, I'm on staging, build 4821, standard user account.
[00:09] Opening Settings, going to the Billing tab.
[00:17] Switching the plan from Monthly to Annual here.
[00:23] And clicking Save... and it just spins.
[00:38] Still spinning, nothing came back.

The engineer reads that top to bottom in under a minute and knows the environment, the exact steps, the pixel of the Save control (x=712, y=468), and the observed-versus-expected. No re-watching, no "which Save button," no clarifying round-trip.

Now the part that is new. Because the .md is structured plain text, engineering's AI coding agent can read it too. A developer using Claude Code, Cursor, or a similar assistant can point the agent at the recording and have it pull the summary, the Fix checklist, and the coordinate-anchored steps into context, then reason about the bug against the actual codebase. The agent reads the same repro the human did. To be precise about the claim: the agent reads the reproduction as context; whether it goes on to open the file and propose a fix depends entirely on the engineer's setup and prompt. Clipy hands over the repro; it does not auto-fix anything. But "the agent already has the exact steps and the failed control" is a materially better starting point than "paste your bug paragraph into the chat and hope."

Connecting the recording to an agent with the MCP server

Two ways engineering feeds a Clipy repro to an AI agent. The simplest is the .md URL: it is public-read under the same access rules as the watch page, so any agent that can fetch a URL can read it, and you can paste it straight into a chat.

The other way, for engineers who want their agent to pull their own recordings on demand, is the Clipy MCP server. It runs with:

npx -y @clipy/mcp

You authenticate with an API key from clipy.online/settings/api-keys. The server is read-only and scoped to your own recordings. It exposes a tool, get_agent_context, that returns the same structured repro, summary, Fix checklist, key moments with coordinates, and transcript, that the .md twin contains, but as a native tool call the agent can invoke inside its own loop. Setup lives in the MCP docs, and the broader agent story is on the for-agents page. If you are the developer receiving these repros, the for-developers page covers the fix-side workflow.

The point for a QA team is that you do not have to think about any of this. You record the failure and hand over a link. Whether the engineer reads it with their eyes, feeds it to their agent as a URL, or pulls it through MCP is their choice. Your output is one clean reproduction, in a format that serves both.

Where recording-as-repro fits in a QA process

This is not a call to record every ticket. Some bugs are a one-line "typo in the footer" and a recording would be overkill. Reach for a recording when the value is highest:

  • Multi-step flows where the order of clicks matters and prose gets ambiguous.
  • Regressions, where proving "it used to work, here's it failing now" saves an argument.
  • Flaky or timing-dependent failures you caught once and do not want to reproduce three more times just to document.
  • Any handoff to an engineer in a different timezone, where a clarifying round-trip costs a full day.
  • Any bug you plan to hand to an AI coding agent, where structured context beats a pasted paragraph.

Keep your ticket fields, build, environment, severity, owner. The recording replaces the one field that was always the slowest and the most lossy: the steps-to-reproduce paragraph. That is the trade. You still file a proper ticket. You just stop hand-transcribing the part you already captured.

Frequently asked questions

Does this replace our bug tracker? No. You still file in Jira, Linear, or wherever your team lives. Clipy replaces the steps-to-reproduce paragraph with a link to the recording's .md repro. Build number, environment, severity, and assignee stay exactly as they are.

What if I record with the plain web recorder instead of the desktop app or extension? You still get the AI summary, the Fix checklist, the key-moment frames, and the full transcript. You do not get click coordinates, because the in-browser web recorder cannot access the pointer stream. For repros where pinning the exact failed control matters, record with the Mac desktop app or the Chrome extension.

Can our developers' AI agents actually read the reproduction? Yes. The .md twin is plain structured text, and the MCP server's get_agent_context tool returns the same content as a native tool call. The agent reads the summary, steps, and coordinate-anchored key moments as context. Whether it then edits code and proposes a fix depends on the developer's setup and prompt; Clipy provides the repro, not an auto-fix.

Is the recording private? What do reviewers and agents see? The .md twin follows the same access rules as the watch page, so it is only as visible as you make the recording. The MCP server is read-only and scoped to your own recordings, keyed to your API key. Nobody sees a repro you have not shared.

How is this different from just attaching a video to the ticket? A raw video makes the engineer re-watch and re-transcribe, which is the same transcription tax moved one desk over. Clipy's .md is something they read in under a minute, summary, numbered steps, marked frames, transcript, without scrubbing a timeline. And it is machine-readable, so an AI agent can consume it too.

Is it really free, with no watermark or viewer signup? Yes. Recording is free, there is no watermark on the output, and whoever opens the link, an engineer or their agent, does not need to sign up to view the recording or read its .md.

The takeaway

QA's job is to hand engineering a clean, unambiguous reproduction. The bottleneck was never finding the bug; it was retyping the bug you already watched into a paragraph that drifts from reality and triggers clarifying questions. Record the failing flow once, and the recording's summary, Fix checklist, and click-anchored key moments become the reproduction itself. Append .md and hand that same repro to the assigned engineer and to engineering's AI coding agent, both read it directly, no re-watching, no re-typing.

Start with the free screen recorder, and read how the repro carries an escalation to engineering, how a recording gives Claude, Cursor, or ChatGPT context, and the AI-first bug report where you record once. And if you are on the other side of the handoff, filing your own bugs as a developer, here is the developer's side of this workflow.