I wanted an assistant that could draft emails in my voice — close enough that I’d send them with a light edit instead of rewriting from scratch. So I did the obvious thing. I wrote down my style as rules.
Keep it short. Lead with the ask. No corporate hedging. Warm but direct. Don’t over-explain.
The drafts that came back obeyed every rule and sounded nothing like me. They were short, direct, warm, and unmistakably written by a machine following a checklist. The rules were all true and the result was lifeless. A style described is not a style transferred.
Why rules don’t carry voice
A voice is a thousand small, correlated choices: which word you reach for, where you put the line break, how you open, how you sign off, when you’re blunt and when you soften. You can’t enumerate those. Any list you write is a lossy, low-resolution sketch — and worse, the model treats each rule as an independent constraint to satisfy rather than as one facet of a coherent whole. It hits the rules and misses the music.
The information about your voice already exists in perfect resolution. It’s in the things you’ve actually written. The mistake is trying to compress that into prose instructions when you could just show the model the real thing.
Examples as the spine
So I rebuilt it inside out. The skill became a thin fingerprint — a few lines of orientation — wrapped around a bank of real examples. Actual messages I’d sent, curated and stripped of anything private, organized by the kind of situation they handle. The examples are the spine. Everything else is connective tissue.
The difference was immediate. Shown fifteen real examples, the model doesn’t follow rules — it pattern-matches against how I actually write, including all the correlations no rule captures. The voice comes through because the voice is in the data, not in a description of the data.
A few things mattered in the build:
- Curate, don’t dump. A bank of genuinely representative examples beats a larger pile of mediocre ones. I had a model classify candidates and keep only the ones that actually carried the voice.
- Cover the situations, not just the average. Voice changes with context — a quick yes reads differently than a hard no. The bank needs examples across the real range of cases, or the model only learns the median.
- Anonymize at the source. Real examples carry real names and details. Those get scrubbed before anything goes into the bank, so the spine is voice without payload.
The shape of it
Concretely, the skill is a Claude Code skill — a SKILL.md that loads when the model decides the task matches. The structure inverts the usual one:
JonEmail/
├── SKILL.md # ~40 lines: a thin fingerprint + "the examples carry the voice"
└── examples/ # the spine — real sent messages, anonymized, by situation
├── quick-yes.md
├── hard-no.md
├── intro.md
└── …The fingerprint is deliberately short — a paragraph of orientation, not a rulebook. The weight lives in examples/. Building the bank was its own small pipeline: pull a corpus of real sent mail, have a model classify each candidate as carries the voice or doesn’t, scrub names and specifics, and keep only the genuine ones — I ended up with a few dozen across a dozen-plus categories. The pattern sits on top of Daniel Miessler’s PAI, whose skill system is built exactly for this kind of self-activating, example-driven unit.
Verify it the honest way
The trap with anything subjective is grading it subjectively. “That sounds like me” is not a measurement. So the test was a blind A/B: my real writing against the model’s drafts, unlabeled, and the question was simply whether they could be told apart. If you can’t reliably pick the machine’s draft out of a lineup, the voice transferred. If you can, it didn’t, and no amount of “feels close” changes that.
The general principle goes well beyond email. When you want a model to be a certain way — a voice, a format, a judgment call — your instinct is to describe the way. Resist it. Find the examples that already embody it and put those in front of the model instead. Show, don’t tell, turns out to be an engineering instruction, not just a writing one.
Built on: Claude Code skills · Daniel Miessler’s PAI, whose skill system this pattern lives inside. The example-bank-over-rulebook idea is just few-shot prompting taken seriously — old, underused, and worth far more than a style guide.