You know the flow you want. You can see it in your head, and you could point at it on the screen in about ninety seconds. But turning that into a written ticket takes forty-five minutes, produces three paragraphs of prose that still leave the engineer guessing which button you meant, and by the time it's assigned, half the nuance is gone.

That gap has always been annoying. In 2026 it's expensive, because the thing on the other end of the handoff is increasingly an AI coding agent — Cursor, Claude Code, or an agent your team wired up in-house — and those agents are only as good as the context you give them. A vague ticket gets a vague implementation. A precise, pointer-anchored spec gets changes that land on the right elements.

This post is about a different handoff. Instead of writing the ticket, you record a short walkthrough where you literally point at the UI and say what should change. Then you append .md to the recording's URL, and that walkthrough becomes a machine-readable spec your coding agent can implement against. Here's why that works, and exactly how to do it.

TL;DR

  • PMs increasingly hand features to AI coding agents, not just engineers — and agents implement what you describe, so vague descriptions produce vague code.
  • A recorded walkthrough carries context a written ticket can't: what you pointed at, in what order, with your reasoning spoken out loud.
  • With Clipy, append .md to any recording URL (https://clipy.online/video/<id>.md) and you get a plain-text spec: a summary, a "Requested changes" list, click-anchored key-moment frames, and a transcript.
  • Click coordinates (which button, where) are captured on the Mac app and the Chrome extension's recordings. The web recorder gives you summary plus transcript, no coordinates. Be honest about which one you used.
  • Paste the .md link (or the text) into your agent's prompt. The agent reads it, and if it has repo access, it can implement the mechanical parts against the right files and elements. It does not ship the feature autonomously, and Clipy has no Jira or Linear integration — you're still the driver.
  • Everything's free: no watermark, no viewer signup, and there's a read-only MCP server if you want the agent to pull recordings itself.

The real cost of the written ticket

Think about what a feature ticket is actually trying to do. It's compressing a spatial, temporal, opinionated thing — "when the user does this, in this part of the screen, the app should behave like that instead" — into linear text. That compression is lossy, and the lossiest parts are exactly the ones that matter for implementation:

  • Which element. "The save button" is fine until there are three save-like buttons on the page. Prose can't point.
  • Where it should go. "Move it up near the title" means a dozen different pixel positions to a dozen different readers.
  • Why. The reasoning behind a change — "users keep missing this because it's below the fold" — rarely survives the trip into a ticket, and it's the reasoning that tells the implementer what "done right" means.

Engineers have coped with this forever by asking follow-up questions, and that loop was tolerable when a human was on the other side. But an AI coding agent doesn't ping you on Slack to clarify. It fills the gaps with assumptions, writes code against those assumptions, and hands you a diff that's technically responsive to the ticket and completely wrong about intent. Now you're reviewing a confidently incorrect PR, which is arguably worse than a blank one.

The written ticket isn't broken because writing is hard. It's broken because you're using the wrong medium to describe a visual, interactive change to a reader — human or machine — who needs to know exactly what you were looking at.

Why a recorded walkthrough beats a written ticket for AI-assisted teams

A screen recording where you talk over what you're doing carries the three things a ticket loses. You point the cursor at the actual element, so "which one" is unambiguous. You demonstrate the flow in order, so the sequence is captured, not reconstructed. And you narrate your reasoning as you go, because that's just how people talk when they're showing someone a thing.

The obvious objection: "a video isn't a spec, it's a video — the engineer still has to watch it, take notes, and translate it into work." That's true of a plain screen recording, and it's the reason "just send a Loom" never fully replaced the ticket. A raw video is a wall you have to scrub through. It's not searchable, not linkable to a line of code, and definitely not something you can drop into a coding agent's prompt.

The thing that changes the equation is making the recording readable. Clipy processes every recording into a structured, text-first artifact you reach by appending .md to the watch URL. So https://clipy.online/video/abc123 becomes https://clipy.online/video/abc123.md, and instead of a player you get a Markdown document built for a machine to parse. That document is the spec. The engineer doesn't re-watch the video; the agent reads the .md. That's the whole trick, and it's why a recorded walkthrough finally beats a written ticket instead of just supplementing it.

Clipy is a free screen recorder built around this idea — the recordings are meant to be read by AI agents, not just watched by people. The full picture of what agents receive lives at clipy.online/for-agents.

What the .md actually contains

When you append .md, here's what comes back, in order:

  • A note-for-agents preamble. A short header telling any AI reader what this document is and how to use it, so an agent that stumbles onto it knows it's context, not prose to summarize.
  • The title and a summary. A plain-language description of what the recording covers, generated from the transcript and the visuals.
  • A "Requested changes" list. This is the part that matters most for a PM handoff. Clipy pulls out the asks you voiced during the walkthrough — "this button should move here," "this flow should validate before submitting" — into a discrete list. That list is your acceptance criteria, extracted from you talking instead of you typing.
  • Key moments. Timestamped points in the recording, each with a frame image. For recordings that captured clicks, each key moment carries the click coordinates as fractions of the frame, a full-resolution crop around the pointer, and a source label (fused, click, or hover) plus a confidence score. The frames tied to a coordinate get a red-and-white marker burned into the image at the exact spot you clicked. So the agent doesn't just know "the user clicked something around here" — it gets a picture with a target painted on it.
  • The transcript. The full text of what you said, so nothing you narrated is lost.

That structure is deliberately friendly to a coding agent. The summary orients it, the Requested-changes list gives it the work, the key-moment frames with coordinates anchor each request to a specific spot in the UI, and the transcript is there when it needs the exact words. It reads like a spec because it's shaped like one.

A note on honesty: which recorders capture clicks

The click-anchored part is the differentiator, so it's worth being precise about when you get it. Click coordinates and the pointer crops are captured by the Clipy Mac app and the Chrome extension when it records a browser tab. Those are the two paths that know where your cursor is relative to what's on screen.

The browser-based web recorder gives you the summary and the transcript — a genuinely useful spec — but no click coordinates. That's not a limitation you should paper over. If you want your key moments anchored to specific buttons for the agent, record with the Mac app or the extension's tab-capture mode. If you're on the web recorder, lean harder on narrating precisely ("the blue Save button in the top-right of the editor") because your words are doing the anchoring the coordinates would otherwise do.

How a PM records a feature handoff, step by step

The mechanics are short on purpose. The goal is a two-to-three-minute recording, not a polished demo.

  1. Open the actual screen you're describing. The live app, a staging build, a Figma prototype, whatever surface the change lives on. You want to point at real UI, not a mockup in your head.
  2. Pick a recorder that captures clicks if you can. Use the Clipy Mac app or the Chrome extension in tab mode so your clicks get coordinate-anchored. Web recorder is fine as a fallback — just know you'll be relying on your narration for precision.
  3. Talk the way you'd talk to an engineer sitting next to you. Move the cursor to the element, say what it is, say what should change and why. "This is the current submit button. It should move up next to the title, and it should be disabled until the form is valid, because people keep submitting empty." Point, then explain. Every time you say "this" while pointing, you're giving the recording a coordinate to anchor.
  4. Demonstrate the flow in the order it happens. If the change spans two screens, walk both in sequence. The key-moment extraction follows your path, so a coherent order produces a coherent spec.
  5. State your asks explicitly. The Requested-changes list is built from what you voice, so phrase the important ones as clear requests: "So the change I want is X." Vague musings are harder to extract than a plainly stated ask.
  6. Stop, and grab the URL. You get a watch link. Append .md to it — that's your spec URL. There's no watermark, and whoever opens it (or whatever agent reads it) doesn't need to sign up; the .md follows the same access rules as the watch page.

That's it. No writing. The forty-five-minute ticket becomes a ninety-second recording plus a ten-second URL edit.

What the coding agent receives, and a copy-paste prompt

Now the handoff. You have two ways to get the spec into your agent.

The simple way: paste the .md link or its contents. Open https://clipy.online/video/<id>.md, copy the text (or just give the agent the URL if it can fetch pages), and drop it into your prompt. Here's a prompt shape that works with Cursor, Claude Code, or any repo-connected agent:

Here is a product spec recorded as a screen walkthrough. It contains a summary, a "Requested changes" list, and timestamped key-moment frames with click coordinates showing exactly which UI elements I pointed at. Read the whole thing, then implement the Requested changes against this repo. For each change, find the component that renders the element shown in the key-moment frame, make the change, and tell me which file and element you touched so I can verify it matches what I pointed at. If anything in the spec is ambiguous, ask before editing. Spec: https://clipy.online/video/<id>.md

The connected way: the MCP server. If you'd rather have the agent pull recordings itself instead of you pasting links, Clipy ships a read-only MCP server. Run npx -y @clipy/mcp, drop in an API key from your settings (clipy.online/settings/api-keys), and the agent gets a get_agent_context tool that returns the same structured context — summary, requested changes, key moments, transcript, with frames inline — for your own recordings. It's scoped to recordings you own and it's read-only, so the agent can read your walkthroughs but can't touch anything else. Setup details are at clipy.online/docs/mcp.

Here's the honest boundary. When the agent reads that spec and it has access to your repo, it can implement the mechanical parts — move the element, add the validation, wire the handler — and land the changes on the right files because the key-moment frames told it which elements you meant. What it does not do is autonomously ship the feature end to end while you go to lunch. You still review the diff, catch the judgment calls the agent got wrong, and decide when it's done. And Clipy is a recorder, not a project-management tool: there's no Jira or Linear integration that files or updates a ticket for you. The value is squarely in the handoff — turning your ninety-second walkthrough into context precise enough that the agent's first attempt is close, instead of a confident guess.

Where this fits in a real workflow

You don't have to replace every ticket with a recording. The recorded-walkthrough handoff earns its keep on exactly the tickets that are hardest to write and easiest to misread: UI changes, flow changes, "move this, gate that, reorder these" work, and anything where the ask is inherently about what's on screen. For a one-line backend config change, type the ticket. For "here's how I want this whole onboarding flow to feel," record it.

It also composes with the rest of an AI-assisted team's habits. If your engineers are already feeding recordings to their coding tools for bug repros and design handoffs, a PM feature spec is the same shape of artifact — which is the point. We've written up the adjacent versions of this: giving Claude, Cursor, and ChatGPT context from a screen recording, a design handoff that keeps what you pointed at, and AI-first bug reports where you record once. Same core move — record, append .md, hand the machine-readable version to the agent — pointed at a different job.

The through-line is that spatial, interactive intent should be captured spatially and interactively, then made readable, rather than flattened into prose and re-inflated by whoever reads it. For a team handing work to AI coding agents, that's not a nice-to-have. It's the difference between an agent that implements what you meant and one that implements what it guessed.

FAQ

Does the AI coding agent actually build and ship the feature by itself?
No. The agent receives a precise spec and, with repo access, can implement the mechanical parts against the right files and elements. You still review the diff, make the judgment calls, and decide when it's done. Clipy provides the context; it doesn't autonomously ship features.

Does Clipy integrate with Jira or Linear?
No. There's no ticketing integration. Clipy turns your recording into a readable spec (the .md URL and the MCP context); getting that into your issue tracker or your agent's prompt is a copy-paste, not an automated sync. Being clear about this so you don't plan around a feature that doesn't exist.

Which recorder do I need for the click coordinates?
The Mac app or the Chrome extension recording a browser tab. Those capture where you clicked, so the key-moment frames get coordinate-anchored with a marker burned into the image. The browser web recorder gives you a summary and transcript but no click coordinates — still a useful spec, just anchored by your narration instead of by pointer data.

What's the difference between the .md URL and the MCP server?
Same underlying content, two delivery methods. The .md URL is a page you open and paste — zero setup, good for a one-off handoff. The MCP server (npx -y @clipy/mcp plus an API key) lets an agent pull that context itself via a get_agent_context tool, scoped read-only to your own recordings — better if the agent is fetching recordings routinely.

Do the engineers or the agent need a Clipy account to read the recording?
The .md follows the same access rules as the watch page, so if a viewer can open the video, they can open the .md. Viewers don't need to sign up to watch, and there's no watermark. The MCP path does need an API key, since it's reading recordings you own on your behalf.

Is this free?
Yes. The screen recorder, the .md spec export, and the MCP server are all free — no watermark, no viewer signup. You can start recording from clipy.online/screen-recorder and read more about what agents receive at clipy.online/for-agents.

How long should the handoff recording be?
Two to three minutes is the sweet spot for a single feature. Long enough to point at each element and state your asks, short enough that the summary and Requested-changes list stay tight. If a change spans several unrelated screens, consider one recording per logical chunk rather than a fifteen-minute marathon.