Writing a Blogging Skill

Nine minutes after I described the topic, Claude handed back a finished blog post — title, headings, a closing line that sounded like me. I hadn't written a word of it, and if I'd said yes, nobody reading it later would have been able to tell.

That's the same failure mode a previous post on this site had already fallen into once: a draft attributed to me with no real back-and-forth. So instead of accepting the shape, I focused on the one question that actually mattered: how do you stop a skill from producing something that reads like me but was never argued with. Everything else fell out of that. If drift was the risk, drafting had to happen in pieces, with a real stop between each one, not one pass end to end. That meant the input side needed the same rigor — pasted notes, local files, reference URLs the post actually had to answer to, not a blank prompt asking for a topic. And it meant the post's shape couldn't be one template for everything. A scaffold built for a build log would strangle a story about training for a marathon. So one template became three categories instead.

Later, to sharpen the habits themselves, I fed the skill three posts by a writer I don't know, from a blog I'd never read, and asked a specific question: not "make this sound better," but what is this piece doing that ours isn't. That's why this post reads differently than the one it replaced.

The mistakes get caught mid-process, not after

Look for the point in this process where the whole post gets drafted and handed to me to approve once. It isn't there.

Three checkpoints replace it, and each one showed up doing real work, not as a formality.

• A thesis gate, before any drafting starts. The skill offered three template shapes before it offered a single sentence of prose — Context→Mechanism→Implications, Hook→Story→Reflection, Claim→Evidence→Takeaway — and none of them mattered until I could state, in one line, what this post actually argues: reliability comes from where a process forces a stop, not from how detailed its instructions are. Every paragraph since has had to earn its place against that sentence, including this one.
• A stop after every beat, not after the draft. This exact section is the proof. It took four rejected passes to get here. A first version was too thin to feel like an argument. A second read as three bolted-together answers. A third swelled into one dense paragraph nobody would finish reading. Each failure was visible and fixable only because it existed as something I could read and reject before the next one got written. A finished draft handed over whole doesn't offer that: there's no earlier version of it to compare against, because there is no earlier version at all.
• A stop available mid-build, not just between beats. Partway through writing the skill itself, three posts by a writer I'd never read got pulled into the process — one about an AI agent's offboarding checklist quietly missing a revoked database, one breaking down Microsoft's dozen products all wearing the name "Copilot," one explaining what an AI "second brain" actually does under the hood. Different topics, same author. Reading them wasn't research done up front. It was a deliberate interruption partway through building this skill: go find out what someone else's hooks and headings were doing that ours weren't, then come back and rewrite the habits before finishing the very post they were meant to improve.

Each of these three came from deciding, in advance, exactly where the process is not allowed to move forward without a person actually looking — and then holding that line even when the easier thing, at every one of those three points, would have been to just keep going.

Detail makes a draft better. A stop makes it real.

This generalizes past blog posts, because the checkpoints are a property of the process itself, not of blog posts specifically.

That's the part worth being precise about. A category can be wrong. A beat name can change. The voice sample can go stale the day my own writing changes. All three are cheap to fix, because fixing them doesn't touch the thing that actually matters: where the process refuses to continue without me looking. Get the checkpoints right once, and the content quality becomes a series of small, recoverable mistakes instead of one large, undetectable one.

More rules about tone, more examples of good hooks, a longer craft-habits list — all of that would have made a solo draft a better solo draft. It would not have turned a solo draft into a co-drafted one, because a draft that never gets interrupted never has to survive being read by someone other than the thing that wrote it.

That's why I'm confident this keeps working past this one post, and past this one skill. The question worth asking of any process that produces something on your behalf isn't "how detailed are its instructions" — it's "where does it refuse to move without me." Everything else is a detail you can fix later.