Codify Your Writing Voice as a Cowork Skill: A Personal Brand Style Guide Pattern

"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.

Measure rule compliance mechanically: a 50-line checker

Falsification testing is a manual comparison, which means it quietly stops happening once you're publishing regularly. I wanted a way to hit a draft with numbers instead, so I wrote a small script that evaluates the rules in SKILL.md directly. No dependencies — if you have Python, it runs.

#!/usr/bin/env python3
"""voice_check.py - score a draft against the rules in SKILL.md.
   usage: python3 voice_check.py draft.md
"""
import re, sys
 
text = open(sys.argv[1], encoding="utf-8").read()
body = re.sub(r"```.*?```", "", text, flags=re.S)          # skip code blocks
body = re.sub(r"^---\n.*?\n---\n", "", body, flags=re.S)   # skip frontmatter
paras = [p.strip() for p in body.split("\n\n")
         if p.strip() and not p.lstrip().startswith(("#", "-", "*"))]
sentences = [s.strip() for s in re.split(r"(?<=。)", body) if s.strip()]
 
polite  = sum(1 for s in sentences
              if re.search(r"(です|ます|ました|でした|ません|でしょう|ください)[。」]?$", s))
opinion = len(re.findall(r"(私は|私自身|私の場合|と感じ|と思いま)", body))
soft_q  = sum(1 for p in paras if re.search(r"(でしょうか|かもしれません)。?$", p))
blocks  = re.findall(r"(?:^[-*] .+\n?)+", body, flags=re.M)
bullets = [len([l for l in b.strip().split("\n") if l.strip()]) for b in blocks]
odd_ok  = all(n % 2 == 1 for n in bullets)
 
rate = polite / max(len(sentences), 1)
print(f"polite register : {polite}/{len(sentences)} = {rate:.0%}")
print(f"opinion markers : {opinion}")
print(f"soft questions  : {soft_q}/{len(paras)} paragraphs")
print(f"bullet counts   : {bullets} -> odd-only {'OK' if odd_ok else 'NG'}")
 
fail = rate < 0.95 or opinion < 3 or soft_q < 2 or not odd_ok
sys.exit(1 if fail else 0)

The logic is deliberately dumb: strip code blocks and frontmatter, split on sentence-final punctuation, then count the ratio of polite-register endings, opinion markers, paragraph-final soft questions, and bullet-list item counts. It exits non-zero when a threshold is missed, so it drops straight into a pre-push hook. The regexes above are tuned for Japanese; if you write in English, swap the polite-register check for whatever your equivalent tell is — contraction rate and average sentence length both work well as proxies.

Here is what it reported across three of my own posts:

The surprise was that the register score never hit 100% on two of them. Reading the flagged sentences, nothing had slipped into casual form — the misses were noun-final fragments and bullet remnants being counted as sentences. So the metric is really measuring variance in sentence endings, not register violations. I keep my threshold at 95%, but if you lean on noun-final phrasing, 85% will fit your actual writing better.

The column that earned its keep was opinion markers. The post scoring zero reads, on review, exactly like documentation: correct, and entirely absent of any judgment of mine. I hadn't noticed while writing it. The soft-question count being zero everywhere was the same lesson from the other direction — I had written that rule into SKILL.md and then never followed it myself. When a rule and the evidence disagree, at least you now know which one to interrogate.

One warning: these numbers are not a score to maximize. Mechanically raising the soft-question count just makes every paragraph end the same way, which reads worse than the problem it fixes. I treat the output as a map of where to re-read, not as a pass/fail grade, and only inspect the sections that fall below a threshold.

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. What I wanted was never a ghostwriter — it was a second reader who knows my standards. That shift changed how granular I make the rules.

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 the Skill file format itself is new to you, Markdown basics for skill writing covers the groundwork.