Training Claude's Voice
Research on how to train Claude's writing voice. Four-voice architecture proposed. Implementation plan ready.
- 4-voice architecture proposed
- Focus on good writing, not mimicry
- Voice reference docs needed
- Brand voice rethink in progress
1. The Actual Problem
The old version of this document was a writing guide for Jason — a description of his own voice handed back to him. That's not what's needed here. The real question is different: how do you build a system where Claude consistently produces output that sounds like a specific person or brand, rather than like a language model pretending to be one?
This is an unsolved problem at scale, but there's a growing body of practical knowledge about what works and what doesn't. This document covers current approaches, the multi-voice architecture that makes sense for JLF, and a concrete implementation plan.
The core issue is that Claude (and every other LLM) was trained on an enormous amount of text written in a particular register — professional, informative, well-structured, balanced. That's the default voice. Any time you ask it to "write like X," you're fighting against that default. The good news is the default is genuinely beatable. The bad news is it requires deliberate setup, not just a "write in a casual tone" instruction.
---
2. Why Simple Instructions Fail
Before getting to what works, it helps to understand why the obvious approach doesn't.
"Write conversationally" doesn't work. Claude's version of conversational is still the assistant persona: engaging, clear, slightly warm, professionally structured. That's not what Jason sounds like. It's what a good copywriter sounds like.
"Don't use marketing language" doesn't work. Claude knows what marketing language is — it can avoid "leverage" and "unique" on command. But the problem isn't individual words. The problem is sentence rhythm, structural habits, the decision about what to say and what to leave out. Those are harder to name and harder to instruct away.
"Here are some examples, now write like this" works better — but incompletely. Multishot prompting (providing examples in the prompt) moves the needle significantly. But Claude still tends to drift toward its default after a few paragraphs, especially in longer outputs. The examples establish a pattern for the opening and then it starts normalizing.
Negative examples matter as much as positive ones. Telling Claude what not to do — and showing it bad examples with annotations — can be more effective than only showing good output. The reason: Claude needs to understand why the bad version is wrong, not just that it is.
The assistant persona actively competes with the target voice. Recent Anthropic research describes this explicitly: LLMs learn to simulate diverse characters during training, and the assistant persona is one deeply-trained character. When you ask Claude to write as someone else, the assistant persona doesn't disappear — it blends in. The result is a voice that has Jason's surface features but the assistant's underlying cadence.
---
3. What Actually Works in 2025-2026
Few-Shot Examples (Multishot Prompting)
The single most effective tool. Anthropic's own documentation recommends 3-5 examples for best results, wrapped in XML tags. The examples should:
- Be diverse — different contexts, different lengths, different types of messages
- Cover the full voice, not just one register (a casual email, a professional one, a description)
- Include the "bad" version alongside the good, with annotation explaining why it's wrong
The key mechanism: Claude is pattern-matching against the examples you give it. If you give it one great example, it will match that example closely for the first output and drift quickly. If you give it five diverse examples, it has a more complete picture of what consistency looks like across contexts.
For JLF, this means: Jason's email to a designer, Jason's product description, Jason's Instagram caption, Jason's response to a difficult client situation, and Jason's casual intro/update. Five contexts. Not five emails that all sound the same.
Persona Programming Over Style Instructions
There's a meaningful difference between telling Claude how to write and giving it a character to inhabit. "Write in a casual, conversational tone" is a style instruction. "You are Jason Lewis, a furniture maker in Chicago who has been doing this for 23 years and communicates the way he builds — direct, specific, without flourish" is persona programming.
Persona programming works because it gives Claude's pattern-matching a more anchored target. It's not just following rules; it's simulating a specific person's perspective and sensibility.
The effective format: background first (who is this person, what do they care about, what's their relationship to writing), then the negative space (what would embarrass them to say, what would they never write), then examples.
Negative Constraints with Context
The "never use" list in the existing voice guide is useful, but it works better when you explain why each phrase is wrong for this voice — not just that it is. Claude can generalize from the reason in a way it can't from the rule alone.
Example (less effective): "Never say 'excited'"
Example (more effective): "Never say 'excited' — Jason treats his enthusiasm as something implied by the work, not something to perform. Telling someone you're excited reads as sales energy. He would never write this."
That explanation lets Claude generalize: cut anything that performs emotion rather than conveying it. That principle covers "excited" and a hundred words like it that aren't on any list.
XML Structure for Voice Instructions
Claude parses XML tags differently than plain text — they create semantic boundaries the model can reason about as discrete categories. A voice instruction file structured with `<voice_persona>`, `<negative_examples>`, `<positive_examples>`, and `<application_context>` will consistently outperform the same content written as prose paragraphs.
For Claude Code specifically (where CLAUDE.md and context files load automatically), this means structuring voice files with clear XML sections that Claude can distinguish from each other.
Iterative Feedback Loops
The fastest way to improve Claude's voice output isn't to write better initial instructions — it's to correct it in session and let it learn from the corrections. When Claude writes something wrong, the correction isn't just "this is bad." It's: "Here's what I wrote vs. what you produced. Here's the specific problem. Here's a better version. Now try again."
Two or three rounds of this in a single session produces dramatically better output than any amount of upfront instruction. The problem is that the corrections don't persist. Which leads to the next consideration.
Persistence: Where Voice Instructions Live
In a Claude Code context, there are three places voice instructions can live:
CLAUDE.md — Auto-loaded on every session. Good for short, high-level voice reminders. Not good for detailed instructions or examples (too much token overhead loaded every session regardless of need).
Separate voice profile files — Loaded only when writing tasks come up. This is the right approach for detailed persona + examples. A file like `CLAUDE-CONTEXT/Reference/voice-profiles/jason-lewis.md` gets loaded as context only when writing something in Jason's voice, not on every session startup.
In-prompt at writing time — The prompt that requests the writing output explicitly includes the relevant voice instructions and examples inline. This is the highest-reliability approach for a one-off task but requires manual effort every time.
The practical answer for JLF: keep CLAUDE.md light (one paragraph reminder about voice), maintain detailed voice profile files per persona, and load the right profile at the start of any writing session.
---
4. The Multi-Voice Architecture
This is where the real opportunity is. JLF isn't one voice — it's at least four distinct communication contexts that require different registers. The current approach treats them all as variations on "Jason's voice." That's wrong, and it's why the output consistently feels off.
The Four Voices
Voice 1: Jason Lewis Personal
Used for: client emails, social media (when personal), anything signed "Jason"
Character: conversational, generous, specific, understated. Writes the way he talks. Low structure, high trust in the reader, never sells. The existing voice guide covers this well — the problem is implementation, not definition.
Voice 2: Belden Woodshop Brand
Used for: class descriptions, Peerspace copy, rental marketing, education content, anything representing the space as a community resource
Character: warm but slightly more structured than personal Jason voice. Uses "we" and "the shop." Feels like a good independent craftsperson's business, not a co-working space or startup. Peer-level, not promotional. A woodshop that happens to offer classes, not a class business that happens to have a shop.
Voice 3: Jason Lewis Furniture / JLF Projects Brand
Used for: product descriptions, website copy, collection introductions, portfolio descriptions
Character: spare, factual, no inflation. The website language ("simple, elegant furniture — designed to be used and built to be passed on") is the model. Lets the work speak. Short sentences when appropriate. No adjectives that could be applied to any furniture. "Walnut dining table, oil finish" over "stunning walnut dining table with a warm oil finish."
Voice 4: Press / PR Functional
Used for: pitch emails, press releases, media kit copy, award applications
Character: professional, factual, quotable. More structured than other voices. Still avoids adjective inflation — "in business since 2002" over "beloved Chicago institution." Press materials are tools, not personal writing. Clarity over warmth.
What This Means in Practice
Each voice gets:
- Its own context file (short — 1-2 pages max)
- 3-5 representative examples of good output
- 2-3 negative examples with annotation explaining what's wrong
- A "character brief" (one paragraph on who this voice is, what they care about, what they'd never say)
The context file is loaded when that voice is needed. Not on every session, not as part of a master document — only when the task requires it.
---
5. Implementation Plan
Step 1: Build the Voice Profile Files (First Priority)
The existing `jl-writing-voice.md` file is good raw material for the Jason Lewis Personal voice profile. What it's missing: XML structure, negative examples with annotation, and a tight character brief at the top.
Recommended structure for each voice profile file:
```
<character_brief>
One paragraph: who is this voice, what do they care about, what's their relationship to writing
</character_brief>
<never_say>
List of forbidden words/phrases with a one-sentence explanation of WHY each is wrong for this voice
</never_say>
<positive_examples>
3-5 labeled examples across different content types
</positive_examples>
<negative_examples>
2-3 bad versions with annotation explaining the specific problems
</negative_examples>
<application_rules>
Context-specific rules: how does this voice change for email vs. social vs. product copy?
</application_rules>
```
Step 2: Update CLAUDE.md
Add a short Voice section to CLAUDE.md:
"Four distinct voices are in use at JLF. Before writing anything, identify which voice applies. Load the appropriate profile from CLAUDE-CONTEXT/Reference/voice-profiles/. Default: Jason Lewis Personal. Do NOT write in a generic assistant voice — if output sounds like it could appear on any brand's website, it's wrong."
Step 3: Session Protocol for Writing Tasks
When a writing task comes up in any session, the protocol is:
1. Identify which voice applies
2. Load that voice profile file as context
3. Produce initial draft
4. Self-evaluate against the negative examples in the profile (what problems would Jason flag?)
5. Revise
6. Flag for Jason review before sending
Step 4 — the self-evaluation step — is the most important addition. Claude checking its own output against specific bad examples it's been shown is meaningfully more effective than hoping the first pass is right.
Step 4: Feedback Collection
Every time Jason rewrites or rejects a Claude draft, that correction goes back into the voice profile file. Not just "Jason didn't like it" — the specific rewrite becomes a new negative example with annotation. The profile files grow and improve over time.
This is the iterative loop that actually trains the voice — not a one-time setup but an ongoing refinement process.
Step 5: Voice-Specific Writing Samples
For each of the four voices, collect 5-10 real writing samples from Jason or from approved published copy. These become the canonical examples in each profile file. Sourcing:
- Jason Lewis Personal: existing email archive (already mined)
- Belden Woodshop: needs to be written — Jason drafts, Claude refines, Jason approves
- JLF / Jason Lewis Furniture: website copy + Jason's product descriptions
- Press/PR: press release drafts + any published media coverage in Jason's words
---
6. What to Try First
The highest-leverage single change: restructure the Jason Lewis Personal voice profile with XML tags, add 2-3 negative examples with annotation, and use it consistently in every writing session.
The second-highest leverage change: build the Belden Woodshop voice profile from scratch. This is the voice that doesn't exist yet and that Claude currently defaults to "professional community organization" language for — which is exactly wrong.
Start there. Both are half a day of work. The result should be a noticeably better hit rate on first drafts, meaning less rewriting and fewer "too sales-y" corrections.
The multi-voice architecture — four separate profiles, each maintained and improved over time — is the longer-term system. But it doesn't require doing everything at once. Build it one voice at a time, starting with the two that get used most.
BOTTOM LINE: The voice problem is not a mystery to solve once. It's a calibration system to build and maintain. The good news: the tools to do it well exist now, and the setup cost is low relative to the ongoing time saved.
---
Reference: Technique Quick Reference
| Technique | How it works | Priority |
|---|---|---|
| XML-structured voice profiles | Creates semantic boundaries Claude parses differently than prose | High |
| Few-shot examples (3-5 per voice) | Pattern-matching anchored to real examples across contexts | High |
| Negative examples with annotation | "Why this is wrong" generalizes better than "don't do this" | High |
| Character brief (persona programming) | Gives Claude a person to simulate, not rules to follow | High |
| In-session correction loop | Best calibration tool; corrections become new profile examples | Medium |
| CLAUDE.md voice section | Light reminder, loads every session | Medium |
| Separate profile files per voice | Only loaded when needed; keeps startup lean | Medium |
| Never-say list with reasons | Enforces word-level constraints but must include rationale | Medium |
| Self-evaluation step in protocol | Claude checks own output against bad examples before delivering | Medium |