Record the bug once. Skip the write-up.
The desktop app writes the steps from your own clicks, attaches the environment they happened in, and hands you a markdown file that is ready to paste.
The pointer walks a recorded track. The markdown lands one line behind it.
Press Play and the two run together. At twenty five the list stops and counts what it left out. Copy puts the exact text on the screen onto your clipboard, so you can paste it into whatever you file bugs in and read it there.
The steps and the environment block are the two parts the app fills in on its own, so they are the two this demo builds. A saved file also carries its front matter, your note and your marks. Nothing here reads anything from your computer.
What was recorded
Mouse positions, clicks and window focus changes. No keystrokes and no window titles go into the track, which is what makes it safe to hand to somebody else.
What the export writes
## Steps to reproduce 1. 2. 3. **Expected:** **Actual:** ## Environment ``` OS: Windows 10 Pro App: SnapBuddy 0.9.0 Displays: 1920x1080, 2560x1440 Locale: en-GB Timezone: Europe/London ```
Steps, timestamps and the environment block. Expected and Actual are left empty, because those two are the only parts of a bug report you have to write yourself.
Front matter a script parses, a report you read
One markdown file per card, and five parts of it were built by somebody who had filed a bug before.
- Front matter, not prose
- The file opens with a YAML block: id, kind, triage status, the capture time in UTC, the image file name, how many marks are on it, and the app and OS strings. Values are quoted, so a colon inside an OS name cannot break the block for whatever parses it. You read the report underneath.
- The environment line
- OS, app version, displays, locale and timezone, in a fenced block at the foot of every saved file, and in every copied prompt. It is put together on your machine, it goes into your files and your clipboard, and nothing about it is sent anywhere.
- Steps already numbered
- The steps come out of the recording with a timestamp on each one, counted from the moment you hit record. Under them sit an empty Expected and an empty Actual, which are the two things only you can fill in.
- Marks described in words
- Every annotation is listed: what it is, where it sits as a percentage of the frame, and the label you typed on it. On a recording the effects are overlays riding on top of the file, and the export says so in bold and leaves their coordinates out rather than pointing at what somebody tried to cover.
- A fence that survives your note
- QA notes get pasted straight out of a terminal, backticks and all. The fence around a block is measured against what it wraps, so a note full of code stays inside its own block instead of swallowing the facts, the steps and the environment after it.
Your clicks go into the track. Your keystrokes do not.
Recording writes an interaction track beside the video: mouse positions, clicks and window focus changes. No keystrokes and no window titles go into it, by design. The steps in the report are read back out of that track, with positions given as percentages of the frame and times counted from the start, so a colleague on a different screen size is reading about the same place you clicked.
The list stops at twenty five interactions and says so, in these words: ...and N more interactions, not listed.
A list that stopped quietly would read as the whole story.
The recording side of this, the pre-record picker, the pill and the take that survives a crash, is on the recording page.
Triage is your verdict, not the pipeline’s
Every card carries a triage badge you click: open, then fail, then pass, and round to open again. It is the same control on the desktop board and in the web library, and the board filters on it, so the answer to what still needs looking at is one press away.
It is deliberately a different field from the one the pipeline writes. One column doing both jobs would have made a transcode that died and a bug that reproduces the same word, and those are opposite news.
Copy prompt, then Copy image, because Windows holds one format at a time
On the desktop board, Copy prompt puts the same report on your clipboard in the shape a model reads best: a sentence naming what it is looking at, the note and the status, the marks, the numbered steps and the fenced environment block. The front matter is left off that one, because a YAML block in a chat window is something a model has to step over rather than metadata anything is going to parse.
The picture rides on the button beside it, and the report closes by telling the assistant the screenshot is arriving next.
No plugin to install, on either side
The export is markdown, so it pastes into the tracker you already use with no plugin to install and no account to connect on either side. Console and network logs are not part of it.
Filing a report straight into your tracker from the app will land in a later release.
AI · coming soon
Your marks will
write the
first draft.
Press once on a capture and a draft will come back with the title written for you, and expected and actual started from the marks you drew and the labels you typed on them.
- 1Will read the marks you drew and the labels you typed on them
- 2Will leave the numbered steps exactly as the recorder wrote them
- 3Will hand you a draft to edit before anybody else sees it
Today
Your repro steps already ship. The desktop app numbers them off the interaction track it writes beside a recording, and no model is anywhere near them. Everything above is what will join them.