I built a thing for Claude Code. It's a "skill" called /snapshot. It saves the current state of one of my project pages as a frozen, linkable version at a stable URL — useful for when I want to write an article like this one and reference past versions of a project I've been iterating on. ("Version 1 was this, version 2 redesigned that, version 3 is what's live now.")
I'm not going to spend much of this article on what the skill does. The skill has its own README on GitHub for that. What I want to write about is what it was like to build a thing — a real, public, open-source thing — when I am, and have always been, not a programmer.
The first surprise was that the building wasn't really building. A Claude Code skill is just a Markdown file. You write English instructions describing what should happen when the skill is triggered, you put it in a folder Claude Code knows to look at, and that's the entire technical artifact. There's no compiling, no dependencies, no build step, no package.json, no nothing. The "code" is a paragraph of English describing what the skill should do, and Claude reads it and does that.
This sounds like I'm cheating. I asked Claude to confirm I wasn't cheating. Claude confirmed I wasn't cheating.
The second surprise was that the actual hard work was the design conversation, not the writing. Before any file got created, Claude and I went back and forth for about an hour on questions like: should this be a slash command or a skill (these are different things, it turns out)? Where should snapshots live in the file structure? What URL convention works on any site, not just mine? Do we need a config file or can we ship without one?
I did not come up with most of those questions. Claude did. My job, when I had one, was usually to push back when an answer felt over-engineered, or to add a constraint Claude didn't have ("this also has to work as an example that someone else could install and use, since I'm publishing it"). It felt much more like working with a thoughtful colleague than typing into an autocomplete.
The third surprise was that publishing it was anticlimactic, in the best way. I made a new GitHub repo (my first public one ever). I dragged four files onto an upload page. I clicked a button. The skill is now installable by anyone in three lines. Total time from "I'd like to make this public" to "it's public" was about ten minutes.
What I keep coming back to is that the bottleneck for non-programmers building software has shifted. It's no longer "do you know how to write the code." It's "do you know what you want, can you describe it precisely, can you tell when an answer is wrong." Those are skills I actually have. The advertising and strategy work I've been doing for years turns out to be most of what's needed to design small software, now that the typing-the-code part is handled.
I'm going to keep writing about projects I build this way. /snapshot exists partly so future articles can show their work — version 1, version 2, version 3, with Claude's notes on what changed in each — instead of just describing what the final thing looks like. If you want to see the skill itself, it's here on GitHub. If you want to install it in your own Claude Code setup, the README walks you through it.