It’s been little over a year since the last thing I published here, which is the kind of fact that’s a little embarrassing to admit out loud but also, conveniently, exactly the problem this post is about. Work and labs pile up faster than write-ups do. By the time I’d get around to actually drafting something, the motivation to recreate my own voice on the page had usually evaporated along with most of the details. So instead of writing up another lab this time, I built a tool to help write the lab write-ups, and then, because I apparently can’t resist a bit of recursion, used it to write this post about itself. How meta.
Why bother building a tool for this
The annoying part of writing these posts has never really been the technical content. It’s translating “I did a thing” notes into something that actually sounds like me, with the asides and the hedging and the occasional honest admission that I have no idea what I’m doing. Generic AI writing tools are bad at this in a specific way: they produce something technically correct and completely flat, the prose equivalent of a press release. I didn’t want a tool that could write a blog post. I wanted one that could write my blog post, which meant the actual work wasn’t prompting Claude to “sound casual,” it was figuring out what my voice actually consists of as a set of concrete, checkable patterns.
Capturing the voice instead of describing it
The wrong way to do this is to write a paragraph like “the tone should be casual and personal” and hope that’s specific enough. It isn’t. So instead of describing the voice in the abstract, I had Claude read through five of my published posts and pull out the actual recurring mechanics: the way every post opens with a personal reason for doing the lab rather than a definition of the technology, the specific habit of hedging about my own expertise (“I don’t have any practical experience here, but…”), the strikethrough self-corrections, the honest, sometimes blunt verdicts in the conclusions instead of generic enthusiasm. Those patterns got written down as a reference document with real excerpts attached, not just rules, since a rule like “use self-deprecating humor” is a lot less useful than the actual sentence that demonstrates it.
The actual steps taken to build it in Claude
The mechanics, for anyone curious about the process rather than just the result:
- Started from Anthropic’s skill-creator skill, which is itself a skill for building and iterating on other skills.
- Got asked, and answered, three clarifying questions up front: how to handle screenshots that obviously wouldn’t exist yet (solution was to use placeholder image tags with descriptive alt text, to fill in later), what tone the LinkedIn companion post should use (more polished than the blog itself, since that’s a different audience), and whether I had real notes to test against (which I kinda just made up, to be honest).
- Got the resulting skill built as a SKILL.md workflow file plus two reference documents: the voice and style guide described above, and a separate guide for the LinkedIn post format and hashtag conventions.
- Ran it for against the previously mentioned sample of just few lines. The skill asked back for the two things notes never include: why I’d actually done the “lab”, and whether I had a verdict on it, rather than inventing either.
- Reviewed the output, found it was riddled with em dashes I hadn’t asked for and didn’t want, and instead of just fixing that one draft, had the rule baked directly into the skill itself, plus scrubbed the em dashes out of the skill’s own instructions so it wouldn’t keep modeling a pattern it was now supposed to avoid.
- Packaged the finished thing into a portable
.skillfile.
Idea stolen from SOP skill work
I have had Claude help build a completely different skill as well: one for turning rough notes into internal IT Standard Operating Procedures. Putting the two side by side is a pretty clean illustration of how differently “turn messy notes into a polished document” can play out depending on what the document is actually for.
The SOP skill is built around a fixed company template. Every heading, every table layout, the order of every section, none of that ever changes between documents, on purpose: someone troubleshooting an incident at 2am should be able to open any SOP in the company and already know exactly where the rollback steps live, without re-learning the document’s shape each time. Anything left unresolved gets one of exactly three placeholder tokens, and a script scans the finished document for those tokens before it’s allowed to ship, rather than trusting anyone to proofread for gaps by eye. Personality is explicitly not the goal. Two SOPs written by two different people about two different procedures are supposed to read like they came from the same hand, because consistency is the entire value of the format.
The blog skill is built around the opposite goal. There’s no fixed template beyond a loose front-matter convention, the section structure follows whatever order the actual lab happened in, and the entire point is that the output sounds like one specific, slightly opinionated person rather than like an institution. Where the SOP skill optimizes for sameness, this one optimizes for distinctiveness.
What both skills share, despite pulling in opposite directions, is a refusal to paper over gaps with invented specifics. The SOP skill won’t guess at a console name or a rollback command it wasn’t given, because a wrong one in an incident document could make a real outage worse. This skill won’t invent a personal motivation or a verdict I never gave it, because a fabricated one just reads hollow and I’d have to rewrite it anyway. Different stakes entirely, same underlying rule: when the notes don’t say, ask, or flag it, don’t fill the silence with something that sounds plausible.
Conclusion
This post is, by design, the actual test of whether any of this worked, which makes it a strange thing to write a confident verdict about while I’m still the one judging it. What I can say plainly: it’s one data point from one “AWS lab”, plus this one meta post, which is a thin sample to declare victory on. The honest next step is the boring one, namely actually using it on the next pile of lab notes I’ve been putting off, and seeing if it holds up on something that isn’t this self-referential.
While I obviously both read through the post before publishing it, and I do make adjustments and additions, there is a definite time-saving benefit in this whole ordeal. That said I do feel that Claude likes to ramble on a bit more than I do (at least in public writing), so the skill is surely going to evolve as time goes on. Which now reminds me of another skill that I recently moved from a Custom GPT to Claude, adding some built-in self-improvement features to it, but that is a story for another time.