Filing a bug report someone can actually reproduce

The person who finds a bug and the person who fixes it are almost never the same person, and often not the same day. Everything the finder saw — the exact URL, the console output, the three clicks that got there, the fact that it only breaks on the second render — has to survive the trip through Linear or Jira or a GitHub issue. Most of it does not.

The usual failure is not laziness. It is that capturing the evidence properly costs the reporter more than filing a vague ticket does, and the cost lands on someone else a week later. A screenshot of the broken element is worth roughly ten sentences of description. A five-second clip of the click sequence is worth the entire "steps to reproduce" section. Both take under a minute if the tooling is out of the way, and about eight minutes if it is not.

None of this requires a paid app. macOS gives you ⌘⇧4 for a region grab and ⌘⇧5 for a screen recording, and for a one-off bug that is genuinely enough. The problem is what happens on the tenth one.

The default flow: ⌘⇧4, the file lands on the Desktop as "Screenshot 2026-07-20 at 14.32.07.png", you switch to Linear, open the issue, drag the file in, and then that file sits on your Desktop forever. A month on you have 180 of them, all named the same way, none of which you can match to a ticket. If you need a moving repro, ⌘⇧5 gives you a .mov that GitHub will not accept inline and Linear will make people click through to.

Then there is the stack trace. It is on screen, in a terminal or a browser console, and you want it as text in the issue. So you either retype it, or you scroll and copy it in three chunks because half of it is off-screen, or you attach a picture of it and nobody can search for the error string later.

Each of these is small. Together they are the reason bug reports get filed thin.

This is the sequence for a bug you can see but cannot easily describe. It assumes you have already set an auto-filing rule pointing your editor or browser at the project folder, so nothing lands on the Desktop.

If you are going to fix the bug yourself in the next ten minutes, the ticket is overhead. SnapShelf exists mainly for this case. Right-click any capture and choose Send to Claude Code: SnapShelf enumerates your terminal tabs, cross-references running processes to find the one actually running claude, and pastes the file path into that prompt. It covers Terminal and iTerm2 only — not Warp, Ghostty, or the VS Code terminal — and it cannot see a session running inside tmux. The other two hand-offs are much thinner than that: Codex copies the file path to your clipboard and opens nothing, and Jira copies the image and opens whatever URL you configured in Settings.

The practical effect is that the screenshot never touches Finder, never touches your clipboard buffer for anything else, and never enters your working memory as a thing you have to go find. You stay in the terminal. SnapShelf always copies the capture to your clipboard first regardless, so if the session lookup misses you paste it manually and nothing is lost.

This is the difference between "screenshot the visual regression, describe it to the model in prose" and "screenshot it, hand over the path, ask it to fix the component". The second one is shorter and the model is looking at the actual pixels.

It does not make a bad repro good. If you cannot make the bug happen on demand, no capture tool helps — you need logging, not screenshots. SnapShelf captures what is on your screen; it has no idea what your application state was.

There is no share link. SnapShelf is local-only today, so getting a capture into Linear means dragging the file in or pasting from the clipboard, not sending a URL. If your workflow depends on instant share links, CleanShot X has them and SnapShelf does not, yet.

And it does not really integrate with your issue tracker. The Jira hand-off copies the image and opens a URL you set yourself in Settings — it does not create an issue and it does not attach anything, and that URL ships empty, so the first use is a configuration prompt. There is no "create Linear issue from this capture" button. You still open the tracker and write the ticket — SnapShelf just makes sure the evidence in it is worth reading.