My first public skill - and the part it can't hand you

In my last post I wrote that you could take my /ship-epic tomorrow. Copy my skills, my hooks, all of it.

Then I went looking for the link to give you, and there wasn’t one. The skill lived in one folder, on one machine. Mine. “You could take it tomorrow” was a nice line that happened to be false.

So I fixed it. It’s on GitHub now, the first skill of mine anyone but me can run. One command:

npx skills add nikolasbarwicki/skills

That drops ship-epic into your project’s .claude/skills/. Add -g and it goes global, into ~/.claude/skills/, available in every repo on the machine. That’s the whole install.

This is a short follow-up to the last post: what it took to make a private skill public, what that one command does and doesn’t do, and why I think you should put yours out there too.

Publishing was the boring part, and that’s the point

I’ve been building these for months. Small sets of instructions I got tired of retyping to an agent, all living on my own machine. ship-epic is the first one I made public. It’s not groundbreaking. It’s a workflow that works for me, written down.

But putting it on the internet forced three things a private prompt never needs to be:

• Installable. One command, instead of copy-pasted by hand.
• Versioned. One history, instead of five drifting copies across projects.
• Readable by people who aren’t me. That’s the one that bites.

A prompt nobody sees, you never have to defend. A prompt strangers can run, you do. And they did: they ran it, found rough edges, and sent back ideas I hadn’t had. That feedback is the whole reason to publish, and you don’t get it from a folder on your laptop.

I expect to publish more, and most will be smaller and duller than this. It’s the first time I’ve handed something from my own toolbox to anyone who wants it.

It works, and I know why

In the last post I called ship-epic my riskiest bet, the thing I was least sure about. That was honest then. It’s changed.

When the PRD and the issues are detailed and right, the core loop runs on its own. On days I can’t sit and drive it by hand, I start it, leave, and come back about ninety minutes later to a shipped epic. I’ve kicked it off and gone for a walk. That part still feels strange to write down.

That sounds like the full-autonomy pitch I spent the last post arguing against, so let me be precise, because the difference is the whole point.

The autonomy sits on top of a scope I locked upstream: the brainstorm, the grilling, the PRD, the issues. Thin upstream work, and the run wanders. Solid upstream work, and the agent has nothing left to decide. It builds.

Two things make leaving the room safe, and neither is the prompt:

• The spec aims the run. When an issue can’t pass, the agent doesn’t grind forever or shove broken code through. It stops, writes down why, skips what depended on it, and carries on. It fails gracefully, with a report.
• The feedback loop catches the rest. Formatting, linting, type-checking, and the tests all run before I see anything, wired into git hooks so the agent fixes its own mess. Each PR is gated on CI. It never merges on red.

Take the loop out and no amount of good PRD makes this a thing you’d leave alone.

I’m not pretending it solved the hard problem from last time. The real danger isn’t inside any one issue, it’s the coherence between the slices. The skill attacks that at the end of the run with architecture, review, and structure passes, and I still go back over that connective tissue myself. The walk buys me the execution, not the part I said was mine.

One more honest line: it runs unsandboxed, on my own machine, with rights to merge its own work. I called that a hole last time and it still is one. The models have gotten good enough that it hasn’t bitten me yet. Hasn’t yet is not won’t.

The coupling is a feature

ship-epic doesn’t stand alone. It calls four of Matt Pocock’s skills by name and sits inside his whole flow, the one that writes the PRD, cuts it into issues, and works out the dependency order. Install ship-epic alone and it won’t do much.

I almost wrote that up as a drawback. It isn’t. Pocock’s repo is one of the most used skill collections out there. People already know that flow and already trust it. I didn’t reinvent the part that turns an idea into well-formed issues, because that part is already good. My skill is a thin layer on top of work other people did well.

The one command moves the prompt, never the work

Now the honest part, because the one-line install makes the rest look easy.

npx skills add is easy. Getting a good result out of ship-epic is a different thing, and it has almost nothing to do with the install. It needs the companion skills, your issues in the shape it reads, and most of all a PRD and issues that are detailed and right. That’s where the thinking happens.

This is the same thing I said last time. The prompt is the cheap part. It was always the cheap part. The expensive part is the spec it runs on, and the taste for when that spec is good enough to walk away from. None of that fits in a markdown file, and none of it travels down an npx command. You build it the slow way, by running things and watching them break.

Install it and feed it three vague issues and it will not save you. That’s not the skill failing. That’s the skill doing exactly what it promises, on top of work that wasn’t there.

So publish yours

I don’t think everyone needs a skills repo. But more of us should publish the skills we already use, for one reason: publishing is almost free, because the part that copies was never the part that mattered.

Someone can take my prompt in one command. They can’t take the spec it runs on, or the taste for when to fire it. So there’s nothing to guard, the downside is close to zero, and the upside is the feedback you get the day it goes up.

It doesn’t have to be perfect. Mine isn’t, and I said where. A working-enough skill in the open helps more people than a perfect one on your laptop, and “waiting until it’s ready” is usually a nicer word for keeping it to yourself.

The only things I’d skip:

• Genuine one-offs. If you’ll run it once, it’s a chat message, not a skill.
• Pure-judgment work. If the honest version is all “it depends,” there’s nothing to share.

Building a repo to feel productive is a satisfying way to avoid the actual work. But the workflow you’ve run twenty times and could recite in your sleep? Put it out there. The prompt is free to copy. The taste for when to fire it was always the only part that was yours.