Show your coding agent the bug. Watch it ship the fix.

A screen recording with a circle around the broken button is a better spec than three paragraphs. Here is how Vidmatic turns that recording into an issue, a live workstream, and a narrated demo of the fix.

By Vidmatic · · 5 min read

Text tickets lose the thing you saw. You notice a button that jumps when you hover it, a total that is off by one row, a modal that traps focus. By the time that becomes a ticket, it is three paragraphs of description and a guess at the steps to reproduce. The coding agent that picks it up has to rebuild the picture from words.

A screen recording does not have that problem. Ninety seconds of video with a circle around the broken button, and your voice saying "this should stay put", carries more of the spec than any paragraph. This post walks through how Vidmatic turns exactly that kind of recording into a GitHub issue your coding agent writes against your own codebase, a live view of the work while it happens, and a narrated demo of the fix when it ships.

Why video plus markup is the best spec you can give a coding agent

A Vidmatic recording is more than pixels. When your agent reads it, it gets:

  • A timed transcript of what you said, down to the millisecond.
  • Your on-screen marks, each aligned to the moment you drew it. A circle or an arrow means "this element". A cross means "remove this". A check mark or the word "Done" closes an ask. Handwriting is the ask itself.
  • Zoomed images of every region you circled, so the agent looks at the real element instead of guessing from a description.

When your words and your drawing disagree, the drawing wins. That rule matters: people misspeak while they point, and the mark is usually the precise part.

Step 1: record the bug and mark it up

Record your screen with Vidmatic and talk through what is wrong while you show it. Circle the element that misbehaves. Cross out the thing that should not be there. Write the ask by hand if that is faster than saying it. You do not need to structure anything; the structure comes from the marks and the timing.

Step 2: give it to your agent

Every recording has a Give this to your agent panel: on the recording page, in your Library, and right after you finish recording. It says "Paste this one line into your coding agent. It connects through the Vidmatic MCP", and its Copy prompt button copies a single command:

/mcp__vidmatic__workstream_from_video <recording id>

The copied text also carries one sentence of governance: your repository's own conventions win. If your repo has a CLAUDE.md or AGENTS.md, your agent follows it for how it works, including branching, tests and review. Vidmatic only describes what to record and what to report.

If your agent has no slash commands, it can call get_skill('workstream_from_video') and follow the same steps. Connecting takes one claude mcp add command, which you can copy from Settings, Developer in the app.

Step 3: your agent turns the video into one grounded GitHub issue

This is the part Vidmatic cannot do on its own, and it is the reason the loop runs through your agent. Your agent waits for the transcript, reads the recording, and zooms into each circled region. Then it looks at your codebase, on your machine, and writes a table of requirements:

R#When and markThe ask, in your wordsAnchors
R10:14, circle"this should stay put when I hover"1 to 3 file:line anchors in your repo

Each ask keeps your own wording, the timestamp and mark that proves it, and one to three file:line anchors where the fix most likely lives. Your agent files exactly one GitHub issue from that table, with a detailed spec. The server refuses a second issue for the same recording, so one video never turns into a pile of duplicates.

Step 4: watch the work in progress on Agent Workstreams

Once the issue exists, the burn shows up on Agent Workstreams in the app. The list gives every workstream a status lamp (Working, Quiet, Blocked, Paused, Not started or Completed), a three-step strip from Kickoff to Work in progress to Shipped, and a chip that plays either the source recording or the shipped demo.

Open one and you get the live hub: an org chart that grows from left to right as your session reports. Each stage of the work gets its own card: plan, critic, build, review and ship. When your agent fans work out to sub-agents, such as critics or reviewers, each one appears as its own card under its stage, labelled with the exact model it ran on. Timers run while a stage is open and freeze when it ends. A drawer holds three views of the same run: Tree, Report and Timeline. Every card carries its own record, with a summary, a description, details and artifacts, and videos in a record play inline.

Your coding session is the one driving. The hub only mirrors what the session reports, so it never takes over how your agent works.

Step 5: when it is blocked, unblock it

Agents get stuck. When that happens the stage shows as Blocked, and the card says what the session needs, in its own terminal. If the agent simply stops reporting, the recording's Agent tab tells you so, for example "Your agent stopped 3 min ago. Paste the prompt again". Pasting the same one line resumes the loop. There is no second setup and no lost context about which recording started it.

Step 6: done means a demo, not a checkbox

The last stage is ship, and it ends with a deliverable: a narrated demo video of the fix, recorded by your agent in your running app and narrated by Vidmatic. It lands in your Inbox, and the workstream's chip switches from the source recording to the demo. You watch the fix instead of reading a summary of it, and when you want to show it to your team or a customer, a public link is one click away.

The full loop, end to end

  1. Recording: you show the bug and mark it up.
  2. Agent: one pasted line connects your coding agent through the Vidmatic MCP.
  3. Issue: your agent writes the requirements table against your code and files one GitHub issue.
  4. Workstream: you watch plan, critic, build, review and ship happen live.
  5. Demo: the fix comes back as a narrated video in your Inbox.

Why this matters

  • Fewer round-trips. The agent starts from what you saw, not from a paraphrase of it.
  • Reviewable evidence. Every requirement points at a timestamp in your recording, and the result is a video you can watch.
  • A paper trail. From "what I saw" to "what shipped", every step is linked: the recording, the issue, the workstream and the demo.

If this sounds like how you want to work with your coding agent, read how teams use it for tickets from video and bug reports from video, see how the narrated demo videos are made, or check pricing and try it on your next bug.

Frequently asked questions

Does Vidmatic read my code?
No. Your coding agent reads your code, on your machine. Vidmatic gives the agent the recording: the timed transcript, your marks, and zoomed images of what you circled. The file:line anchors in the issue come from your agent looking at your own repository.
Which coding agents work with this?
Any agent that can connect to an MCP server can call the Vidmatic tools. In Claude Code the steps are slash commands, so the hand-off is one pasted line. Agents without slash commands can call get_skill('workstream_from_video') and follow the same steps.
What happens if my agent gets stuck?
The stage it was working on shows as Blocked on the workstream, with a line saying what the session needs. The recording's Agent tab also tells you when the agent stopped reporting. Answer it in your terminal, or paste the same prompt again to resume.
Is the finished demo public?
The demo lands in your Inbox first. You decide whether to share it. A public link is there when you want to show the fix to your team or a customer.
Do I need ffmpeg or any other video tools on my machine?
No. Vidmatic's servers do the transcoding and render the narration. Your agent only needs the Vidmatic MCP connection.
Can a teammate hand me their recording?
Yes. If a recording was shared with you, the Give this to your agent panel includes the access token in the prompt, and the workstream that results is yours.

Try it on your next bug

Record the problem, hand it to your coding agent, and get a narrated demo of the fix.