"AI drafts always drift away from how I actually write." If you keep a personal blog or a long-running newsletter, you've probably felt this friction. I run four sites with heavy AI assistance, and for the first few months I had the same complaint: useful, but the prose didn't sound like me.
The shift came when I stopped putting tone instructions in every prompt and started encoding them as a Cowork Skill instead. Once "voice" lives in a SKILL.md that fires only when I'm drafting personal content, the output gets noticeably closer to my own writing. This article walks through how to build that Skill in three steps: observe your voice, declare it as rules, and falsify those rules against your own past work.
Why a Skill, not a prompt or a memory file
Cowork gives you three places to put writing instructions, and each has a different best fit.
- Direct prompts suit one-off tasks. They aren't reproducible and won't survive past the next conversation.
- Memory files like CLAUDE.md apply to the whole project. Great for "always push from /tmp" or "use Japanese and English in pairs," but too aggressive for voice — they bleed into code reviews and operational chats where you don't want a stylistic filter.
- Skills activate only when their trigger keywords appear. That selectivity is exactly what voice work needs: I want my drafting tone to load when I say "blog post" or "note," and stay quiet when I'm debugging.
I keep operational rules in memory and route every writing-related directive through Skills. The separation means I no longer have to remember which conversation needs which tone — Cowork picks the right context based on the trigger.
Step 1: Reduce your voice to three to five concrete traits
The observation phase is where most attempts at personal style guides quietly fail. Vague guidance like "write warmly" or "be authentic" gives an AI nothing to act on. Open five of your own published pieces, read them back to back, and note the patterns that repeat. When I did this for myself, the list looked like this:
- Always uses the polite Japanese form (
desu/masu); a single break in register feels off - Frequently writes "I think" or "in my case" to mark opinions as opinions
- Often closes paragraphs with a soft question to invite the reader in
- Bullet lists almost always have three or five items, never four or six
- Every code block is preceded by a one-sentence statement of what the code is for
These are testable. "Warm and friendly" isn't. The exercise is tedious, but skipping it produces a Skill that doesn't change the output, so plan to spend at least an hour reading your own back catalog before writing a single rule.
Step 2: Author the SKILL.md skeleton
A Cowork Skill is just a directory with a SKILL.md inside. Drop it at something like .claude/skills/personal-voice/SKILL.md and declare the triggers in the frontmatter. A minimal version looks like this:
---
name: personal-voice
description: "Personal voice style guide for blog and newsletter drafting. Triggers: blog, newsletter, draft, personal post"
---
# Personal Brand Voice Guide
This skill governs first-person posts on my personal sites. Stylistic
fidelity outranks technical density: if a sentence is correct but
sounds generic, rewrite it.
## Rules I always follow
1. Use the polite register throughout. One slip means re-read the whole draft.
2. Mark opinions explicitly: "I think...", "In my case...", "what surprised me was...".
3. End most paragraphs with a soft question that invites the reader.
4. Bullet lists should have three or five items, not four or six.
5. Every code block must be preceded by a single sentence that names what
the code is for.
## Things to never do
- "How was that?" / "Thanks for reading until the end" boilerplate
- Generic openers like "In this article we will explain..."
- Listing product features without a point of view
- Restating the article's H2s as a closing summary
## Self-check
Re-read the draft against the five rules above. If a rule is violated even
once, fix that section before returning the output.Three details matter most: keep the trigger keywords narrow, quantify rules where you can ("three or five," not "few"), and write a "never do" section. Negative examples are surprisingly powerful — they let you preempt the safe-but-bland templates an AI will otherwise reach for.
Step 3: Falsify the Skill against your own past writing
This is the step most people skip and the one that decides whether the Skill works. Once it exists, take a topic you've already written about, re-draft it through the Skill, and compare line by line.
# Without the skill — baseline drift
claude "Write a 1,500-word post about my reset routine when a project stalls."
# With the skill — include trigger words so it fires
claude "Personal blog post for my own site: write a 1,500-word piece on my reset routine when a project stalls."Run a three-point check on the output. Polite register intact, no slips into casual form. Three or more first-person opinion markers. Multiple paragraphs that close with a soft question. If any of those are missing, your rules are still too abstract — go back and replace adjectives with examples until the next regeneration passes.
A trick that lifted my hit rate: paste real samples
At the bottom of SKILL.md I keep a section called ## Voice samples with two or three paragraphs lifted directly from posts I'm happy with. Models learn voice better from examples than from rules, and pairing both gets you further than either alone. I pull samples from dolice.design and from notes I'm proud of. The act of selecting them is itself useful: you start to notice which paragraphs feel "yours" and which were written on autopilot.
Codifying voice for an AI ends up being a forcing function for codifying voice for yourself. The rules I wrote for the Skill became checkpoints I now apply when I write by hand, too.
Evolving the Skill quarterly, not constantly
Voice drifts on you slowly. The Skill that captures how you wrote in March will start to feel slightly off by August, partly because you're a different writer and partly because the topics you cover have moved. I review my voice Skill once a quarter rather than constantly, and the cadence has worked out well.
The review is short: I read the three most recent posts I'm satisfied with, and the three I'm least satisfied with. Where the satisfied posts diverge from the rules, I update the rules. Where the unsatisfied posts followed the rules but still felt off, I look for a missing constraint — usually something about pacing or the way I open a section. A quarterly diff like this beats trying to maintain a "perfect" SKILL.md from day one, because you're updating against real evidence instead of imagined improvements.
One pattern I'd warn against: don't keep adding rules forever. After about ten rules, the file becomes a set of contradictions and the AI starts producing oddly stiff prose that's trying to satisfy all of them at once. If a new constraint conflicts with an existing one, decide which matters more and remove the loser. A tight rule set you trust beats an exhaustive list you don't.
A failure mode: trigger keywords that are too broad
The single most common reason a voice Skill misfires is over-broad triggers. If your description says only "writing" or "article," the Skill will activate inside code reviews and documentation cleanup, and stylistic rules will overwrite the precision you actually need there. Stick to keywords that clearly mean personal output — "blog," "newsletter," "personal post," "note" — and let everything else run unfiltered.
What to do next
Open three of your own posts, read them back to back, and write down five repeating habits. That single hour of observation is the bottleneck that decides whether your Skill ever feels useful. Drop those rules into a minimal SKILL.md, narrow your triggers to a single context, and run one falsification test before the day ends. Production-grade refinements come later — but you'll have a draft that finally sounds like you within a few hours.
If you're new to Skill structure itself, see Markdown basics for skill writing. For a wider tour of how Skills compose with automation, Cowork automation skills is the companion piece.