I stopped writing bug reports. Now I complain at my screen.

I build a product solo. That also makes me the QA team.

Finding bugs was never the slow part. The slow part came after. I would reproduce a bug, and then spend the next hour turning it into a ticket: watch the recording again, write down the steps, scroll for the frame where it breaks, copy the error text, and try to match "it froze right here" with the right lines in the logs.

At some point I noticed a stupid thing. While reproducing a bug, I talk. I say things like "why is this button doing nothing" and "wait, the price is wrong again". Everything a good bug report needs was already in that moment. I just had no way to keep it.

So I built one.

The workflow now

I press record, click through the app, and complain out loud. Then I open Claude Code and run one command:

/talkthrough:bug recordings/checkout-bug.mp4

Behind it is talkthrough-mcp, a free open source MCP server (MIT) that runs on my machine. What happens:

1. The recording gets indexed locally: a transcript with timestamps, key frames, OCR text from the screen, and the real time of day for each moment when the file metadata allows it.
2. Claude does not read the whole video. It queries that index: search the words, pull the exact moment, look at the actual frame.
3. It writes one GitHub issue draft: what happened, what I expected, steps to reproduce, severity. Every claim has proof attached: my words from the recording, the timestamp, the error text from the screen, and the frame reference.

Here is a full 78-second run, not edited. A narrated recording goes in, a ready-to-file bug-report.md comes out:

The draft is the end of the pipeline on purpose. /talkthrough:bug never creates or edits an issue on its own. I read the draft, sometimes fix a detail, then file it with gh or paste it into the tracker. An agent that silently writes into your bug tracker is a bigger problem than one extra step.

Why everything runs locally

talkthrough never uploads the recording. Whisper runs on CPU, OCR and frame extraction are local, and there is no talkthrough account, no cloud backend, no telemetry, no extra API key. Claude sees only the text and images that the MCP tools return, inside your normal Claude Code session.

This matters more than it sounds. Recordings are full of things you do not want to send to a random service: customer data on the screen, internal URLs, half-finished features. And meetings are even worse. Which brings me to the part I did not plan.

The use case my colleagues found

I shared the tool with colleagues at my day job. They mostly ignored the bug part and pointed it at recordings of real work meetings.

Since v0.2 talkthrough has local speaker diarization (sherpa-onnx: no torch, no accounts, no GPU). A recorded meeting becomes a transcript where speakers are labeled S1, S2 and so on, and every remark carries the real time of day. So you can ask "what did we decide about the migration" and get an answer with a quote, a speaker and a timestamp, without rewatching anything.

One real number from their feedback: a 65-minute Teams call with about 16 people took around 15 minutes to process on a busy work laptop, diarization included. Not instant. Still much better than an hour of rewatching.

Their reports also shaped the tool more than my own plans did. For example, the warning you get when the detected speaker count looks implausible came straight from a real meeting where clustering went wrong. When your only test data is your own voice, real users are a gift.

If you want to check the numbers

I do not like demo magic, so the repo has a fully reproducible example: examples/bug-from-silent-recording. It is a Playwright-recorded clip with no audio track at all (silent recordings work too, through frames and OCR), plus the unedited agent output. The job id is the sha256 prefix of the file, so you can verify every number on your machine: same file, same id, same keyframes.

Honest limits

• Local files only. No YouTube, no URL ingest (planned).
• The first run downloads the models, so it is slow once.
• The analysis uses the transcript plus key frames, so it can miss motion between frames. You can still pull an exact full-resolution frame for any timestamp.
• Diarization quality depends on the audio. Very short remarks sometimes get the wrong speaker; passing num_speakers when you know the headcount helps a lot.

Try it

In Claude Code:

/plugin marketplace add korovin-aa97/talkthrough-mcp
/plugin install talkthrough@talkthrough

It is a plain stdio MCP server, so it is not tied to Claude: configs for Cursor, Codex CLI and ten more clients are in the repo. Everything is here: https://github.com/korovin-aa97/talkthrough-mcp

One design question I keep going back and forth on: should /talkthrough:bug stay draft-only, or should it also be able to create the GitHub, Linear or Jira issue after an explicit confirmation? I would honestly like to know what you would want.