Blog

3 min read

ShotKit: Why I Built Yet Another Screenshot Tool

Screenshots are only useful if they move through your workflow without breaking it.

  • shotkit
  • macos
  • tooling
  • workflow
  • ai

There’s no shortage of screenshot tools. macOS has one built in, and there are dozens on the App Store. Building another one sounds pointless until you notice what most of them optimise for: capturing the pixels, not what happens next.

In a real workflow, screenshots are rarely the end product. They’re an intermediate artefact you need to route somewhere quickly while keeping your brain on the thing you were doing.

The Problem Isn’t Taking Screenshots

Taking a screenshot is easy. The real problem is everything that comes after:

  • Naming files
  • Organising them
  • Annotating quickly
  • Getting them into the right tool (GitHub, Obsidian, Slack, etc.)
  • Not breaking your flow while doing all of the above

Most tools solve one part of this well and ignore the rest. The result is friction — and friction kills momentum.

The specific failure mode I kept running into was tiny, but constant: the screenshot lands on the desktop, the filename is nonsense, I either forget what it was for or I spend a minute sorting it, and suddenly the thread I was following is gone. It’s not that I can’t do it, it’s that I can’t do it fifty times a day without it becoming annoying.

Where This Started: Murmr

While building Murmr, I kept hitting the same issue: I could capture ideas instantly with voice, but anything visual was clunky.

That gap became obvious. If Murmr was about capturing thought, something else needed to handle capturing context, and that’s where ShotKit came from.

What ShotKit Actually Solves

ShotKit isn’t about screenshots. It’s about fast capture and immediate usefulness.

  • Zero friction capture
  • Immediate action
  • Workflow-aware
  • No library management overhead

The design goal is simple: when I take a screenshot, I should be able to do the next step without thinking. That might be “attach this to a GitHub issue”, “drop this into an Obsidian note”, “share it in a thread”, or “annotate and send it”. If the tool makes me stop and manage a screenshot library, I’m already annoyed.

It also needs to be boringly predictable. Local-first storage, no account, no sync gimmicks, no “AI magic” applied to images unless it’s genuinely useful and fully under my control. This is a utility, not a product pitch.

In an AI Workflow, Screenshots Become Inputs

In an AI-heavy workflow, screenshots become inputs, not artefacts. They’re part of the context you feed into tools:

  • A UI state you want to reproduce
  • A layout bug you want to explain without paragraphs
  • A design decision you want to capture before you forget why it mattered

If that capture-to-context path is slow, everything slows down because you hesitate to record things. You start relying on memory again, and that’s where details get lost.

Where It’s Going

This isn’t polished. It’s something to live with and evolve, and I’m deliberately treating it as a tool I’ll keep adjusting until it earns its place.

Once it is ready I will release it to the world on Github. Still a ways off that though.