Your writing voice is already on the page. Everything you've published is a record of how you actually write — consistent enough that a tool can learn it from your posts, even if you couldn't spell it out yourself. ghost-blog-mcp is the Claude Code plugin I draft and edit these posts with. The first thing it did on this blog was read everything I'd published and build a style guide out of it, so its drafts start in my voice instead of a generic one — then I edit from there. You can point it at your own posts and do the same.
Getting a model to draft in that voice wasn't automatic. The drafts were wrong for a long time, and what eventually got them right wasn't a list of rules to follow — it was examples: the posts I pointed it to, and the edits I made by hand. The style guide is where all of that collects.
What it learns
The skills in the plugin generate a style guide of four sections, kept separate because they have different owners and update on different schedules.
| Section | Controlled by | Refreshed |
|---|---|---|
| Stated voice | You — authoritative | Never auto-overwritten |
| Observed patterns | The corpus | Re-derived every run |
| Anti-patterns | Stated voice + corpus | Re-derived every run |
| Provenance log | Every input folded in | Append-only |
Two of the four do most of the work, and both come straight from the posts. The observed patterns are measured, not prescribed. When it read this blog it came back specific: the posts here run around 1,100 words, they open on a problem or an observation more often than an anecdote, and they almost always close on a link to the source. I never wrote any of that down — it measured it, and cited the post behind each observation.
The stated voice is the part I control. It carries my audience and tone and, the piece a corpus can't infer, the writers I'd point to as the target. define-voice asks for those by name and pulls the examples in, by URL or file, so the guide is anchored to writing I chose, not only to my own back catalog.
Tells, and what reads as mine
The model reproduces my voice well, and it reproduces the tells that read as machine-generated just as readily. So the anti-patterns aren't kept as a bare list — each tell sits next to the sentence that reads like me, the version I'd have written instead.
| Reads as machine-generated | Reads like my posts |
|---|---|
| What it can't restore is the live state. | It can't restore the live state. |
| The real job isn't the draft — it's the revision. | The drafting is the straightforward part; the revision is the work. |
The first buries the subject behind a frame; the second leads with it. The second pair cuts a sentence whose only job was to say what the last one meant. The drafting skill checks every draft against these and fixes what it finds before I read it.
Keeping the rules you've earned
This didn't start as a style guide. The voice got matched one post at a time, long before any of it was written down — the corrections lived in the commit history, not in a document: "match existing tone and style," "convert to narrative prose," "remove filler language." The rules were real, but they only existed as edits I'd made and would have to make again.
Eventually those edits became a written guide, and the guide grew the same way the commits had: one correction at a time. It started as a short note on formatting and turned into a long list of things to avoid, most of them added the first time a draft did something I had to cut. Those rules aren't in the posts that came out clean — they live in the sentences I removed, and a guide generated cold from the corpus would miss them.
So the build seeds from the guide I already had and folds the corpus in on top, with one rule: everything I trusted has to survive into the new guide before anything new is added. I checked the generated one against my hand-written one and confirmed nothing had been dropped.
A living guide
The guide isn't a one-time export. As I publish, the corpus grows, and the next time it's built the observed patterns re-derive — so what it drafts tracks what I've actually been publishing, not a snapshot from setup day. Reading the corpus, it caught something I'd never written down: my older posts use markdown tables and Title Case headings, my newer ones use HTML tables and sentence case. It flagged the older habits as drift to drop — it had noticed a change in how I write that I'd made without ever stating it.
Starting without a corpus
None of this needs a back catalog. For a new blog, define-voice runs a short interview — who you're writing for, and the writers you'd point to — and pulls those examples in. That's enough to seed the stated voice and the avoid list the corpus would have produced; the observed patterns fill in on their own once you've published enough to learn from.
Using it
Installing the plugin and connecting your Ghost site is a one-time setup, covered on the ghost-blog-mcp page. After that, the work happens through the skills.
You can call them explicitly — /ghost:build-style-guide to learn your voice, /ghost:write-post to take a topic through draft, revision, and a push to a Ghost draft. They also trigger on plain description: "learn my voice from my posts" or "draft a post about X and walk me through it" reaches the same skills without the slash command.
The repo is github.com/schuettc/claude-code-plugins, and this post was drafted from the guide it built for this blog.