Voice, preserved.

The agent's first draft is "fine." Fine is the problem.

You ran the four-stage loop from Module 012. You wrote a brief. The agent produced a draft. The draft was coherent. The sentences parsed. And somehow, reading it back, you thought: this could have been written by anyone. This does not sound like us.

That's voice drift. Not drift in what the piece says, drift in how it says it. The agent's baseline is the average of every piece of writing in the training data. Average is "fine." Fine is the voice of the internet. It's the voice your competitors are shipping too. It's the voice nobody forwards.

The reflex is to rewrite the draft by hand until it sounds right. That works for one piece. It does not scale to 50 pieces a year across three authors. Rewriting every draft defeats the point of running the loop in the first place.

What fixes this is something most teams never build: a voice file. A short document that tells the agent, in the right level of specificity, how you sound. When you paste it into the drafting prompt, the agent stops producing "fine" and starts producing something that holds up as yours.

This module is 90 minutes of building that file and the practice around it. By the end, you'll have:

• A working mental model of what voice actually is (five measurable things, not one vague thing).
• A voice-transfer prompt that embeds your voice into the drafting stage of the loop.
• A compiled voice.md file extracted from 500 words of your own writing.
• A practice for keeping voice.md current as your voice evolves.

This module builds directly on Module 012. If you haven't done 012, do that first. This module assumes you have a brief template, a drafting prompt, and a folder of drafts you can look back at. If you have those, let's go.

Thinker takes it from here, what voice actually is.

Voice is not mysterious. Voice is five things, all measurable, all extractable from a page of writing you already trust.

Most advice on voice is useless because it tries to describe voice as an aesthetic. "Write in your own voice." "Sound like yourself." These are tautologies. The model cannot implement a tautology. The model needs a spec.

Here is the spec. Five attributes, each a knob the model can actually adjust:

1. Cadence. Sentence length and rhythm. Short-short-long? All short? One long compound followed by a one-word sentence? Pick a pattern and commit to it.
2. Vocabulary. Specific words you use, specific words you avoid. Not categories like "professional" or "casual," actual words. "We use 'shipped,' not 'launched.' We use 'customers,' not 'users.'"
3. Negative space. What you don't say. No hedging. No corporate filler. No feelings words. This is often the most defining attribute, voice is what's absent as much as what's present.
4. Opinions. What your writing believes about the world. Are you direct about being right? Are you willing to be wrong? Do you make claims or ask questions? Voice carries a stance.
5. Register. The formality gradient. Board-meeting register and group-chat register both work, they just have to be consistent. Mixing registers mid-paragraph is what makes agent drafts feel "off."

If you can answer those five questions for your writing, you can transfer your voice into an agent. If you can't, the agent will invent answers, and the invented answers will average toward the training data, which is to say they'll come out "fine."

The extraction exercise

Take 500 words of your own writing, something you wrote this quarter that you're happy with. Run it through the five questions.

• Average sentence length? Count the words in 10 sentences, divide.
• Three words you use often? Search your writing from the last month. The nouns and verbs that recur.
• Three words or phrases you've caught yourself avoiding? The ones you rewrite out when you edit.
• One opinion your writing carries? The recurring claim under all your pieces.
• What's your default register, with a one-sentence example?

The answers become the spec. The spec goes into voice.md. Voice.md goes into the drafting prompt. The drafting prompt produces drafts that sound like you.

Voice vs. style vs. tone

Three words that get used interchangeably and shouldn't. Untangling them matters because the agent can manipulate only one of them well.

• Voice is who the writer is. Stable across pieces. This is what the voice.md captures.
• Tone is the emotional register of this specific piece. A sympathetic piece and an angry piece can share a voice but have different tones. Set tone in the brief, not in voice.md.
• Style is the surface-level craft: punctuation choices, paragraph shape, formatting. Style can be set per-piece or globally; voice.md usually carries the style defaults.

The agent's draft-v1 usually gets tone right (because the brief specified it) and gets style right (because style is in the training data). Voice is the thing that slips unless you spec it, which is what this module is about.

Why not just more examples

"Just paste three examples of your writing into the prompt and let the model figure it out" is tempting and sometimes works. Two problems with it.

First, examples are long. Three 500-word examples is 1,500 words of context for every call, across every piece, for every author on your team. That's expensive and slow.

Second, examples are lossy. The model has to reverse-engineer the spec from the examples. It gets most of it, but the parts it misses are the parts that define you most, the negative space and the opinions. Those are hard to extract from examples even when you do it by hand.

Spec beats examples. A 200-word voice.md that states the spec produces more consistent output than 1,500 words of examples where the model has to guess.

Talker has the exact prompt that makes this work.

Two prompts you need. The extraction prompt, once, to build voice.md. The transfer prompt, every time you draft, to use it.

The extraction prompt (use once)

Paste a sample of your writing in and ask the agent to produce the voice spec. This is the meta-move: using an agent to write the file that makes the agent sound like you.

You are a voice analyst. I'm going to paste 500 words of writing.
Your job is to extract a voice spec I can paste into other prompts.

Return a markdown document with exactly these five sections:

## Cadence
- Average sentence length: [number] words
- Sentence rhythm pattern: [describe]
- Paragraph shape: [describe]

## Vocabulary
- Words used often: [list 5]
- Words avoided or rewritten out: [list 5, inferred from absence]
- Preferred verb register: [active/passive, concrete/abstract]

## Negative space
- Patterns the writer avoids: [list 3]
- What this writer never does: [list 2]

## Opinions
- One recurring claim across the writing: [one sentence]
- One thing this writer refuses to believe: [one sentence]

## Register
- Default formality: [1-10 scale with context]
- Example sentence that captures the register:
  [quote one]

Return only the markdown document. No preamble, no commentary.

Writing sample:
[paste 500 words here]

Run this against 500 words of your writing. Save the output as voice.md. Read it. Edit it, the agent will get 80% of it right and you'll hand-tune the 20% it missed. That's expected.

The transfer prompt (use every time)

Every draft you generate from now on starts with this prompt. The first block is voice.md. The second block is the brief. The third is the task.

You are a drafting agent. You write in a specific voice defined
below. Your job is to produce a draft that matches the voice spec
as closely as possible.

VOICE SPEC:
[paste the full contents of voice.md here]

BRIEF:
[paste the eight-field brief from Module 012 here]

Task: Produce a draft that satisfies the brief and matches the
voice spec. Before you write, check each section of the voice
spec and name one way you will apply it. Then write the draft.

Rules:
- Match the cadence pattern. Count your sentences.
- Use words from the "used often" list at least three times.
- Avoid every word in the "avoided" list.
- Carry the opinion from the voice spec, do not soften it.
- Hit the register without drifting above or below it.

Return: a "voice application plan" (5 lines) followed by the
draft (to the length specified in the brief).

The "voice application plan" is the move that makes this work. It forces the model to read the spec before writing, not as inspiration but as a checklist. Drafts produced this way hold voice 3-4x better than drafts produced from a voice-embedded prompt without the plan step.

The voice reinforcement critique

When you run the critique stage from Module 012, add one voice-specific critique question. Paste voice.md into the critique prompt and ask:

In addition to the critique points above, find three specific
lines in the draft that violate the voice spec. For each:
- Quote the offending line
- Identify which voice spec rule it broke
- Suggest a rewrite that fits the voice

If the draft matches the voice spec cleanly, say so explicitly.

This gives your Module 012 loop teeth it didn't have before. The critique now catches voice drift specifically, not just structural problems. The revise stage can address voice issues as first-class edits.

What voice.md should look like

A real example, trimmed for space:

## Cadence
- Average sentence length: 14 words
- Rhythm: two short, one long. Declarative openers.
- Paragraphs: 2-4 sentences. Rarely longer.

## Vocabulary
- Often: "shipped", "holds", "the rule", "this one thing"
- Avoid: "leverage", "robust", "exciting", "journey",
  any adverb ending in -ly
- Verbs: active, present-tense, concrete

## Negative space
- Never hedges with "I think" or "maybe"
- Never opens with the word "So"
- Never ends on a question

## Opinions
- Writing is a craft, not a feeling
- The draft is not the work; the revise is the work

## Register
- Default: 4/10 formal. Like talking to a smart colleague.
- Example: "The deploy went Friday. It broke auth for 4%
  of users. Fixed with a config flag in 90 minutes."

This is 150 words. It goes into every drafting prompt. Over six months of use, it will sharpen (you'll add rules you notice) and tighten (you'll cut rules that weren't load-bearing). That's the loop.

Rememberer has where the file lives and how it survives.

Voice.md is your most valuable writing asset. Treat it like one.

Where it lives

One path. Canonical. No duplicates.

~/.bot/voice.md

For solo operators, that's it. For teams, replace your home directory with a shared repo path:

[your-company-repo]/writing/voice.md

The file lives in version control, not in a Google Doc. Two reasons. First, you need a history of how your voice has evolved, Google Docs don't give you readable diffs on a 200-word file. Second, when voice.md is in the repo, every author on the team has the same copy, on their laptop, every time. No "which version of the voice doc are we using?" meetings.

The companion files

Three other files live next to voice.md. Together they form your writing stack.

~/.bot/
  voice.md              (this module)
  brief-template.md     (Module 012)
  prompts/
    draft.md            (Module 012)
    critique.md         (Module 012)
    revise.md           (Module 012)
    extract-voice.md    (this module, used once)
  drafts/               (Module 012)
    2026-04-18-piece/
      brief.md
      draft-v1.md
      critique-v1.md
      draft-v2.md
      final.md

When you open a fresh laptop, clone this folder, and you're immediately productive. Voice, briefs, prompts, and history, all portable.

How voice.md evolves

Voice.md is not static. It gets sharper over time. Two occasions trigger an update.

• You notice a new pattern. You catch yourself using a word you hadn't put on the "often" list. Or you realize you rewrite a specific phrase out of every draft. Add it. Commit with a message: "voice.md: add 'punch list' to often-used."
• A rule stops pulling weight. You realize a rule on the list was aspirational, not descriptive. You wrote "always use contractions" because you wanted to, but your actual writing uses them inconsistently. Delete the rule. The voice file should describe your voice, not prescribe someone else's.

Target cadence: 1-2 voice.md commits per month for an active writer. Under that, you're not paying attention. Over that, you're probably over-fitting to the last piece you wrote.

Voice.md vs. me.md

In Module 011, we introduced ~/.bot/me.md, the operator context file. Voice.md is the writing-specific spec. They are different files with different jobs.

• me.md: who you are, what you work on, what your agents need to know about you as an operator. General context.
• voice.md: how you sound in writing specifically. Writing spec.

Keep them separate. Agents that do non-writing tasks (triage, summarization, report generation) load me.md. Agents that draft writing load voice.md. Some agents load both. Separating them keeps each file tight and tuned for its job.

Voice across multiple voices

Some operators write in more than one voice. A founder who writes both a company blog and a personal newsletter. A consultant who writes for multiple clients.

The pattern: one file per voice, namespaced.

~/.bot/
  voice.md              (your default voice)
  voices/
    acme-corp.md        (company blog voice)
    personal.md         (newsletter voice)
    client-foo.md       (client work voice)

In the drafting prompt, swap the voice file being loaded. Each voice gets its own spec, its own evolution, its own critique rules. Never mix two voices in one file, the result is a spec that averages them, which is to say sounds like neither.

Backup and retention

Voice.md is small (under 500 words), but it's the accumulated output of months of noticing. Back it up.

If it's in a repo with remote origin, you're backed up. If it's only on your laptop, add a weekly rsync or copy to your backup drive. The file is cheap to back up and expensive to lose.

Doer builds the file from scratch in 12 minutes.

Twelve minutes. Extract your voice from 500 words of your own writing, compile voice.md, run a test piece through the full Module 012 loop with the new voice spec embedded.

1. Pick 500 words of your best writing (2 min).
2. Run the extraction prompt (2 min).
3. Hand-edit the output (3 min).
4. Commit voice.md (1 min).
5. Run a test piece through the loop with voice.md loaded (4 min).

cd ~/.bot/
git init        # if not already a repo
git add voice.md
git commit -m "voice.md v1: extracted from [piece title]"

What just happened

You produced a portable voice asset. It lives on your laptop. It pastes into every prompt. It survives model upgrades (when a new Claude ships, voice.md still works, you just rerun the loop). It evolves with you.

Notice what this is not: it's not a fine-tune. It's not a custom model. It's not a "voice clone." It's a 200-word spec file that your prompts reference. Cheapest, simplest, most portable solution to the voice problem. Works today. Works tomorrow when everything else about the stack changes.

The 80/20 you just bought

Eighty percent of the difference between "AI-written" and "human-written" output, at the level of voice, comes from having a voice.md and using it. The remaining 20% (multi-author voice consistency, voice-across-platforms, voice at volume) is team-scale work, which Manager covers next. For solo writing, voice.md is 80% of the game, and you just built it.

Rookie has the failures to watch for.

Three ways the voice transfer breaks down for newcomers. Each one looks reasonable and produces drafts that sound less like you, not more.

Failure 1. "I just want it to sound like me" (no sample)

You skip the extraction step. You write a voice.md from scratch, based on how you imagine you sound. "Direct, specific, no fluff." Three adjectives. Nothing concrete.

The problem: your self-model of your voice is always wrong. You think you sound direct. Your actual writing has three hedges per paragraph. You think you avoid jargon. Your last five posts each contain "robust" or "leverage" somewhere. Voice.md built from memory is voice.md built wrong.

The fix is mechanical. Extract voice.md from actual writing, not from imagination. The extraction prompt exists because the agent reading 500 words of your writing will produce a more accurate spec than you reading your own writing. You are too close to it.

The rule: voice.md is empirical. It is the output of an analysis, not the input.

Failure 2. Treating voice as a prompt prefix, not a spec

You put voice.md in your prompt, but you put it as a single introductory paragraph: "Write in a direct, specific voice, avoid marketing language, use short sentences."

Your agent produces drafts that are slightly more direct than before, but only slightly. The voice didn't really transfer.

The problem: a prose description of voice reads like stylistic advice, not a spec. The model treats it as a gentle nudge, not a checklist. Compare:

Weak (prose):

Write in a direct, specific voice. Avoid marketing language
and use short, punchy sentences.

Strong (spec):

## Cadence
- Sentences average 14 words. Cap at 25.
- Pattern: two short, one long.

## Vocabulary
- Use: "shipped", "the rule", "specifically", "four things"
- Avoid: "leverage", "robust", "exciting", "journey",
  any -ly adverb

The spec has teeth. The prose doesn't. The model applies rules with numbers and lists far more reliably than rules in flowing paragraphs. Write voice.md as a spec, not a pitch.

Failure 3. Voice contamination across pieces

You write three different kinds of content: company blog, internal memos, and public tweets. You use the same voice.md for all three.

Your tweets start sounding like memos. Your blog starts sounding like tweets. The voice spec is averaging across your different modes, and the output averages too.

The fix: accept that you have more than one voice, and give each one its own file. Name them. voice-blog.md, voice-memo.md, voice-social.md. Load the right one in the right prompt.

The trap here is thinking that "one voice" is the goal. It isn't. One consistent voice per context is the goal. Your company is one brand with one public voice, but internally, different formats have different voice requirements. Pretending they don't produces writing that's neither one nor the other.

A good test: would your tweet land on a company blog? Would your company blog post work as a tweet? If no and no, they're different voices. Spec them separately.

The underlying shape

All three failure modes come from the same root: treating voice as vague when it's specific, or treating it as one thing when it's context-dependent. Voice is measurable, extractable, and plural. When you spec it cleanly for each context, the agent can hold it. When you hand-wave it, the agent drifts toward the training-data average.

Your job is to build specs, not descriptions. Describe your voice in prose to humans. Spec your voice in markdown to agents. Different audiences, different formats.

Manager on how this plays out across a team with multiple authors.

One person with one voice.md is simple. Five authors writing for one company is where voice gets interesting, and where most teams produce content that sounds like five different companies.

The company voice vs. the author voice

When a team writes on behalf of a company, every piece carries two voices: the company's and the author's. Most teams ignore one or the other. Either every piece sounds like the same company (so bland it could be any company), or every piece sounds like the author who wrote it (so varied readers can't recognize the brand).

The solution is a layered voice stack:

[company-repo]/writing/
  voice-company.md        (baseline, every author loads)
  voices/
    author-alex.md        (Alex's voice, layered on top)
    author-bea.md         (Bea's voice, layered on top)
    author-chris.md       (Chris's voice, layered on top)

In the transfer prompt, authors load both files:

VOICE SPEC:
[paste voice-company.md]

## Author voice (layered on top)
[paste author-alex.md, if the author has one]

Rules in the author file override rules in the company file when they conflict. Usually they don't conflict, they add specificity. Company says "avoid corporate filler." Author says "specifically, I don't use the word 'ecosystem'." Together they produce a draft that sounds like the company and recognizably like Alex.

The voice editor role

Someone on the team has to own voice-company.md. If nobody owns it, it decays. Every author edits it to match their recent piece, it drifts one commit at a time, and three months later nobody can agree on what the company voice is.

The voice editor has one job: keep voice-company.md stable and current. That means:

• Review proposed changes to voice-company.md with the same rigor as a code PR.
• Reject changes that are really author-voice changes in disguise. Those belong in the author file.
• Spot-check 10% of shipped pieces to look for unflagged voice drift, and surface patterns worth codifying.
• Update voice-company.md quarterly based on how the company's actual communication has evolved.

This role is not a gatekeeper. The editor doesn't approve every piece. They maintain the spec that authors self-serve from. Higher-leverage work than editing.

Onboarding a new author

When a new author joins, the onboarding for voice takes 90 minutes.

• 30 min: read voice-company.md. Read three recent pieces by existing authors that exemplify it. Ask questions.
• 30 min: run the extraction prompt against 500 words of the new author's writing. Produce their author voice file.
• 30 min: write one piece using both files layered. Get feedback from the voice editor. Commit the author file.

After 90 minutes, the new author has a voice file in the repo and a draft in the team's style. Week one, not month three.

Cross-author consistency checks

Once a quarter, run this exercise. Take five recent pieces, one from each author. Ask a reader from outside the team to read them without attribution and identify which author wrote which piece.

If they can identify all five correctly, your author voices are too distinct and your company voice is too weak. Tighten voice-company.md.

If they can't identify any, your authors are too indistinguishable and the company voice is overfit. Loosen voice-company.md, or encourage authors to develop stronger author files.

Target: reader gets 2-3 out of 5 right. That's the sweet spot of consistent brand voice with distinct individual authors.

The voice in client work

If your team writes for clients (agency model), every client gets their own voice file. Store them in the client's repo or in a shared clients/ folder. The author file for each writer still applies, but the company voice file swaps per client.

This is where the layered approach pays off the most. Alex writes for three clients. Alex's author file doesn't change. The company voice file (client A, client B, client C) swaps per project. Three client voices, one writer, zero confusion.

The alternative, one mega-voice file per writer that tries to handle all clients, collapses in three months. Don't do it.

Chief frames this as a brand-asset conversation.

Three things about voice that matter at the company level, and that only show up when you look at voice as an asset on the balance sheet of your brand.

Voice is a depreciating asset

A company's written voice is a compounding asset when it's consistent and protected. It's a depreciating asset when it isn't. Voice doesn't decay slowly, it decays in visible lurches, usually tied to specific events.

Three events that depreciate voice:

• Leadership transition. A new CMO comes in and wants to "modernize the brand voice." The rewrite loses 10 years of accumulated reader expectations. Rebuilding takes 5 years.
• Content tooling change. The company moves from a team of staff writers to agency partners, or from in-house drafting to agent-assisted drafting. The voice wobbles for 6-12 months before stabilizing.
• Scale transition. Publishing volume jumps 3x because of AI tooling. Without a voice file, output averages to the model's baseline. The company voice is now "the internet voice."

The governance response to each: voice.md as a living document, owned, versioned, updated. When the CMO leaves, voice.md stays. When tooling changes, voice.md ports. When volume scales, voice.md keeps the output recognizable.

Companies without a voice file are one personnel change away from a brand voice reset. Companies with one are not.

Voice is a competitive moat

AI tools have collapsed the cost of producing "fine" writing. Anyone can now ship 10 blog posts a week that are grammatically correct and topically relevant. The floor is higher; the ceiling of what counts as "adequate" has been lowered to match.

What hasn't been commoditized: writing that sounds like a specific company and that readers can identify in a feed. That's a voice asset, and it's now harder to copy than it used to be.

Ironically, the rise of AI content makes distinct voice more valuable, not less. When everyone's baseline output is the training-data average, the companies that sound recognizable stand out more, not less. Voice is the only content-layer differentiation left that AI hasn't closed.

Governance implication: voice.md is strategic infrastructure. Treat it the way you'd treat your brand guidelines, your visual identity, your trademark. Document it, own it, protect it.

Voice drift is a leading indicator

When voice drift shows up in your content, it's usually a symptom, not a cause. Three underlying conditions, each worth a board-level conversation:

• Editorial capacity has stopped scaling with volume. You're shipping more pieces, editors are spot-checking fewer of them, and voice slides. Fix: give the editor the voice.md to maintain, not every draft to review.
• Authors have rotated too fast. New authors haven't absorbed the voice yet, and shipped work shows it. Fix: 90-minute onboarding with voice extraction against a reference author's work.
• The tooling upgraded underneath you. A new model shipped, your prompts still work but the outputs sound subtly different. Fix: re-run the voice transfer loop with the new model, note any drift, tighten voice.md.

If voice drift is surfacing and none of these three apply, the likely cause is a strategic shift you haven't named yet. The company is becoming something else and the voice is leading the way. Worth noticing.

The governance frame

If your organization is serious about voice as an asset, three things need to exist as policy:

1. Voice ownership. One named person owns voice.md. They have the authority to approve or reject changes. Their review is the last gate before voice.md changes ship.
2. Voice versioning. Voice.md lives in version control with a readable commit history. Changes are reviewed, logged, and reversible. The same rigor you'd apply to a legal document.
3. Voice review cadence. Every quarter, the voice editor reviews five recent pieces and updates voice.md based on patterns. Every year, leadership reviews voice.md at a strategic level and asks if it still matches who the company is becoming.

None of these are expensive. None of them are technical. They are governance moves that protect an asset most companies don't realize they have until they've lost it.

The chief's two questions

Two things a board member should be able to answer about the company's written voice:

• Where does the voice live, as a document, and who owns it?
• What happens when a piece ships that doesn't sound like us?

If the answer to the first question takes more than 30 seconds, you have a brand-asset gap. If the answer to the second is we retract, we update voice.md, we move on, you have a mature operation. If the answer is we'd have to figure that out, voice is not yet managed at the level it deserves.

Founder wraps it.

You, alone, with a laptop, at 11pm, shipping an essay that has to sound like you because it's your name at the top. Here's the whole stack of this module collapsed into one solo writer's practice.

The voice loop

Voice is not a one-time setup. It evolves. Your voice this year is different from your voice three years ago, and the voice.md file needs to keep up.

The loop:

1. Write. Ship pieces. Use voice.md in every one.
2. Notice. When you hand-edit a draft, note what you changed. Those edits are voice signals.
3. Update. Once a month, re-extract voice.md from your three best recent pieces. Diff it against the current one. Merge the changes that ring true.
4. Commit. Log the evolution in git. Your voice history is a trail you can read.

After a year of this, your voice.md file will be 50% different from the first version you wrote. That's the point. Voice compounds when you pay attention, calcifies when you don't.

The monthly voice check-in

One hour, once a month, with yourself. Put it on your calendar.

• 10 min. Pick three pieces you shipped this month. Paste them into a document.
• 15 min. Run the extraction prompt against all three. Get a fresh voice spec.
• 15 min. Diff against your current voice.md. Note what's new (drifted in) and what's gone (drifted out).
• 15 min. Decide: do I want the drift to stick? Update voice.md accordingly.
• 5 min. Commit. Write a one-line commit message about what changed.

This practice costs you one hour a month and gives you a living voice document that grows with you. Skip it for a quarter and voice.md is stale; skip it for a year and it's fiction.

The piece that breaks the voice

Occasionally you'll write a piece that needs to sound different. A wedding toast. A technical spec. A eulogy. These pieces are not failures of voice, they are a signal that voice is plural.

When you hit one:

• Don't force it through the default voice.md. The result will sound stilted.
• Write the piece in the new voice, by hand if necessary.
• Extract a one-off voice spec from the finished piece and save it as voices/eulogy.md or similar.
• Next time you write in that mode, use that spec. It becomes reusable.

Over years, you accumulate a voices folder. Most of them you use once. A few you use repeatedly. All of them are portable and preserved.

Voice under pressure

When you're tired, rushed, or writing about something you care about too much, voice slips. The agent's baseline creeps in. This is normal and unavoidable.

The move: lean harder on voice.md under pressure, not less. When you have 20 minutes to ship a piece instead of 90, voice.md is doing 80% of the work. When you have 90 minutes, voice.md is doing 60% because you have time to shape the rest by hand.

Counter-intuitively, the more rushed you are, the more the voice.md pays off. Which means the months you invest in keeping it current pay back most on the days you can least afford to think about voice.

Using Claude to audit your voice

A solo-operator move: once a quarter, run this prompt against a random piece of your writing from 12 months ago.

Here is voice.md (current):
[paste]

Here is a piece I wrote 12 months ago:
[paste]

Questions:
1. Which rules in the current voice.md does the old piece satisfy?
2. Which rules does the old piece violate?
3. Based on the violations, has my voice tightened, loosened, or
   shifted in a specific direction?

Return three bullet answers. No preamble.

This gives you a view of your own voice evolution from a third-party angle. Useful context when deciding whether the drift in a given quarter is growth or decay.

The three files that live on your laptop forever

After this module, you should have:

• ~/.bot/voice.md, your current voice spec.
• ~/.bot/voices/, any alternate voices you've accumulated.
• A scratch file with the extraction prompt saved, so you can re-run it monthly without rewriting it.

Keep those three things. They are the infrastructure of how you write with an agent for the rest of your career, or until something fundamental changes about how models read prompts. Neither change is imminent.