My blog rules became a skill you can switch off

What this is about. Most posts on this Ship Log start as a working session with Claude Code. The rules for turning a session into a post lived in a README inside my monorepo. I moved them into a public skill catalog on GitHub, and my site now lists what's in it. With some filters.

Why. Rules that only work inside one repo are a habit, not a tool. And anything I hand to other people has to be easy to turn off when it misbehaves.

Skills, not sessions

I'd been reading about Claude skills: small folders of instructions Claude loads when a task matches. The advice I'd been given was to draft a skill right after finishing a feature, then cut it down to what you'd want to remember next time. I wrote this to my AI:

I am interested in posting Claude "skills" just as the blog posts. They should be drawn from every major feature, not every session.

I also suggested the obvious first one: Muntra, the small analytics tracker I wrote in Go and open-sourced.

The AI disagreed, politely:

Muntra is a product, and a skill is know-how.

A skill teaches Claude how to do something. So the Muntra skill would be "how to add Muntra to a site", and it belongs inside the Muntra repo. A small audience, and not the place to start.

Its pick was something I'd used for weeks without calling it a skill: my blog README. Ask whether the work is blog material, write in my voice, start with an intro, end with the alternatives, redact everything private, upload as a draft and let me publish. Tested on many posts here. I myself can't tell the difference after a while.

Create the big red off switch first

Before any of it was written, I added one condition:

Draft it in a way that if problems arise, I can turn it off or detach it.

That turned into a rule for the whole catalog, not just this skill. There are four ways out, from gentle to final:

You want to…	Do this
Stop it in one project	Write "Blog drafts: off" in that project's rules file
Stop it everywhere, keep it installed	`claude plugin disable session-to-blog@idunworks-skills`
Remove it	`claude plugin uninstall session-to-blog@idunworks-skills`
Drop the whole catalog	`/plugin marketplace remove idunworks-skills`

The first one matters most to me: a line in a text file beats any setting you have to remember the name of.

Three more rules made it into every skill:

It never starts by itself. You type /session-to-blog. A skill that decides your bug fix deserves a blog post is a skill you uninstall.
It never publishes. It writes a draft file. You press the (green) button.
Your project's rules win over the skill's defaults.

Testing it on fake projects

My rules file is full of my own setup. The public skill had to work without it, so the AI ran it headless in throwaway projects with planted traps:

A project with "Blog drafts: off" in its rules. It stopped, as it should.
A session full of an invented server name and port. Both were redacted from the draft.
A session about a security hole that wasn't fixed yet. The post was put on hold instead of written.
A normal session where nobody asked for a post. It stayed quiet.

One test failed in a slightly nerdy comic way. I'd typed /session-to-blog, and the skill asked whether this was blog material. Typing the command is the yes. Now calling it counts as the answer, and the follow-up questions come before the drafting. Like a dream within a dream within a dream...and you need a Jolt to snap out of it :)

A page that can't go stale

The catalog lives at github.com/idunworks/claude-skills, MIT licensed. It's a Claude Code plugin marketplace, so installing takes two commands instead of copying files around:

/plugin marketplace add idunworks/claude-skills
/plugin install session-to-blog@idunworks-skills

My site lists it at idunworks.com/skills. The page reads the catalog straight from GitHub, keeps it for an hour, and shows the last good copy if GitHub is down. I never edit the list on the site, so it can't drift from the repo.

Each skill card also links to the Ship Log posts behind it, and only published posts count. This is the first one: a post written with the skill, about the skill. Pure Inception.

What happened, and what else I could have done

The problem: the rules that turn sessions into posts were stuck in one repo, and nothing I'd share was easy to switch off.

The fix: a public plugin marketplace with one skill per major feature, four documented ways to stop each one, tests against fake projects with planted traps, and a page on my site that reads the catalog instead of copying it.

Other ways to do it:

Option	Better at	Costs
Keep the rules in `CLAUDE.md` or a README (what I had)	Zero setup, always loaded	Stuck in one repo, nobody else can use it
Copy a `SKILL.md` into your own skills folder	Simplest way to share one skill	No versions, no updates, people keep stale copies
A plugin marketplace on GitHub (what I chose)	Install, update, disable and remove are one command each	You have to bump a version number on every change, or nobody gets it
An MCP server	Can run real code and hold state	A service to host and secure, overkill for instructions

The rule of thumb: if you're writing instructions for an AI that other people will run, write the off switch before the instructions. You'll need it the first time it does something you didn't expect, and so will they.

Next up: adding Muntra to a site. The catalog is open: idunworks.com/skills.