The Space Between Keystrokes
A Claude Code plugin marketplace for the workflows that fracture your flow
There’s a moment in every coding session where everything clicks. The problem is clear, the solution is forming, and your fingers are keeping pace with your thoughts. You’re not thinking about the tools. You’re thinking about the thing you’re building.
Then you need to commit.
So you context switch. You write a message, stage the files, push the branch. You open Linear to update the ticket status. You check if the CI passed. You open a PR. You write the description. Each step takes thirty seconds, maybe a minute. None of them are hard. But together they add up to something insidious: they fracture the thing that was working. The flow state. The space where building actually happens.
I noticed this pattern long ago, as I’m sure many of you have, and it bothered me in a way I struggled to articulate. The friction wasn’t in any single step. It was in the accumulation. Every small interruption was a tiny tax on attention, and by the end of a session I’d spent more mental energy on process than on the problem I was trying to solve.
The insight, once it arrived, was simple: these are patterns, not problems. And patterns can be automated.
What I Built
Skillset is a Claude Code plugin marketplace. That description is technically accurate but misses the spirit of the thing. It’s really a collection of lightweight, modular workflow automations that encode the patterns I was already following and remove the friction between intention and execution.
There are two plugins today.
The first is linear lifecycle, which manages Linear issues through the command line instead of through Linear’s MCP server. This matters more than it sounds. The MCP server consumes roughly 13,000 tokens of context just to load. That’s context your AI assistant could be using to understand your codebase, reason about architecture, or catch a subtle bug. The CLI approach costs roughly 1,000 tokens. Same capability, a fraction of the overhead. Constraints like these turn out to be excellent design tools.
The second is sdlc, which covers the full development lifecycle in five skills: plan, checkpoint, review, iterate, complete. Each one maps to a phase of work. Plan fetches your Linear issue and sets up a branch. Checkpoint saves progress. Review creates a pull request with dead code detection baked in. Iterate addresses PR feedback with automatic comment prioritization. Complete closes the loop and resets your environment for the next task.
The design philosophy is deliberate constraint. Each plugin is entirely self contained. No dependencies between them. Install only what you need. The skill definitions stay brief and focused, with detailed reference material loaded only when Claude actually needs it. Everything is optimized around the idea that context is a budget and you should spend it on the work that matters.
What It Feels Like
Here’s what a typical session looks like now...
I type /sdlc:plan ENG-142 and sit back. Claude fetches the issue from Linear, reads the description, explores the relevant parts of the codebase, and drafts an implementation plan. I review the plan, make adjustments, and approve it. Then I open my journal beside the laptop and write while Claude iterates on the implementation.
This is not a small thing. I have been journaling for years and the practice is near and dear to my heart. It used to compete with coding for my attention. Now they coexist because the mechanical overhead of development has been compressed into a few commands.
I’ve been using this workflow to build BetterPack with my friend Nick Titus who I hiked the JMT with in 2024. It’s a modern ultralight backpacking gear tracker, a replacement for LighterPack that we originally conceived on trail, but shelved because the overhead was overwhelming. Now, we’re launching at the end of March. The project is a labor of love, the kind of thing you build because you know that the existing tooling can be better and you know you can do better.
Building BetterPack with skillset has been a delight and has felt fundamentally different from building without it, emphasis on the fun part. The feedback loop is tighter. The sessions are longer and more productive. I spend my time thinking about pack weight algorithms and gear data models instead of branch naming conventions and PR templates. The tools have become invisible, which is exactly what good tools should do.
The Broader Point
This isn’t really about Claude Code. Or about skillset specifically. It’s more about the relationship between builders and their tools.
The best tools disappear. They encode the patterns you already follow and remove the distance between what you intend to do and what actually happens. A carpenter doesn’t think about the hammer. A writer doesn’t think about the keyboard. The tool becomes an extension of the practitioner, and the practitioner’s attention stays on the work.
Software development has accumulated an extraordinary amount of process over the years. Much of it is valuable. Version control, code review, issue tracking, continuous integration. These practices exist for good reasons. But the mechanical overhead of executing them pulls attention away from the creative work of actually building software. Every git add and gh pr create is a small departure from the problem space into the process space.
Skillset is small and deliberately so. Two plugins, a handful of skills. It solves exactly the friction I experience in my own workflow and nothing more. I’m not building a platform. I’m sharpening my own tools and sharing the whetstone.
Back to the Space Between
The session I described at the beginning, the one where everything clicks, happens more often now. Not because the problems got easier or I got faster at typing. But because the gaps between the creative work shrank. The space between keystrokes filled up with more building and less bookkeeping.
If any of this resonates, the repo is public. Install a plugin, try it for a session, see if the friction fades. And if you have workflow patterns of your own that deserve to be encoded, the marketplace is designed for exactly that.
I’ll be writing here about the things I’m building and the ideas behind them. This is the first one. There will be more.




“I type /sdlc:plan ENG-142 and sit back. Claude fetches the issue from Linear, reads the description, explores the relevant parts of the codebase, and drafts an implementation plan.”
Yo this is huge! Great experience.