Here's my current best practices for steering Claude's default voice out of my writing, described in enough detail that you should be able to re-create any of these strategies. Spoiler alert: There's no magic bullet, and the problem seems to get worse as newer models are released.
Every model arrives trained with a house voice: the phrasing, rhythms, and structures it absorbed in training. As the models have gotten more sophisticated, that voice has become more distinct, recognizable across everything the model produces. It has also, in my experience, become harder to dislodge. You can give the newer models crystal-clear direction, and within a few subsequent prompts it drifts back to writing like its own.
Each practice below works against one of the model's defaults, and there are two ways to do that. Most of them counter a default directly. Two (Practices 3 and 5) work differently: they pick a model whose defaults are weaker to begin with, and then get out of the way.
I don't know the technical specifics, but here's my mental model: The model's writing habits were worn in across billions of training examples, and defaults that deep always win over 'write in my voice.' The most effective counter is telling the model what NOT to do. You can look at any sentence and tell whether it broke a ban. You can't do that with "write in my voice."
One thing to settle before any of this. Get the audience and the purpose wrong, and the piece won't be any good, no matter how skilled you or the model are. I've written that up at the end as Step Zero, because it needs none of the tooling below.
I maintain a file of writing rules that loads into every writing session. It holds some positive guidance, but the part that does the most work is all negative: banned words and banned structures. My list of words has the model's latest specific tells, collected over time as I get tired of seeing them ("crucial," "genuine," "comprehensive," every tense of "land," and several dozen more).
The banned structures are some of its overused writing patterns: no emdashes, no "it's not X, it's Y" sentence pairs, no four-item lists with identical syntax, no sentences that open with "And" or "But." Each time the model writes something you've grown tired of seeing, add it to the file (or just ask Claude to add it to the file), and load the banned list every time you draft something. My file keeps changing, because the models have different tells and preferences than they did six months ago.
Whenever I put serious editing effort into getting a draft into my voice, I have Claude go back through the session afterward and extract 'before & after' pairs: what it originally wrote, what I changed it to, and the pattern behind the change. My pair bank has a few hundred examples in it, grouped by failure type, with the strongest four or five starred in each group. (I have Claude automatically manage and curate this bank, so it's not as much work as it sounds.)
Why pairs? They seem to be more effective than a list of rules. A rule asks the model to abstract a principle and re-apply it while drafting, and that abstraction step is where the default voice can leak back in. A pair shows the exact example, and the model imitates it directly. When pairs go into a prompt, I inject the relevant thirty or forty, never the whole bank.
The lightest models (Gemini Flash, Anthropic Haiku, ChatGPT Nano or Mini) seem to arrive with less of a house voice than their heavyweight siblings. Their prose comes out flatter; there are fewer tells to edit out and less personality pushing back against direction.
In practice, this becomes a split. I will use a powerful model (eg: Opus) to develop the brief. I'll chat with Opus to iterate and align on the argument, the talking points, what to include, and in what order. This activity takes advantage of Opus's ability to do heavy reasoning. When I'm done with that, I send the finished brief to a lighter model that does nothing but write prose based on the brief. This works because the thinking was already locked in before the writing started. The same idea runs underneath the tools below: separate the thinking from the writing, and hand the writing to whichever model has the least personality.
When you're doing this in practice, use Claude Opus or Sonnet to develop the brief and then switch to Haiku (in a new session) to actually draft the piece. For ChatGPT, develop the brief using GPT 5.X medium or high, and then have 5.5 Instant write it in a new session.
Most of my approaches started as repair, designed to fix a model's voice after it was already on the page. /pen is designed to address the problem before anything gets written down.
Pen is a Claude skill I've developed. It's a page of instructions that Claude Code follows whenever I type the command, and every slash-named tool in this list works the same way. I invoke it at the start of any piece that needs to be written in my voice. It tells Claude what I'm writing and who it's for. From there, it builds a prompt for itself from four layers in a fixed order:
The order is intentional. I want the model copying something before I tell it what to avoid. The rules are the floor, not the target.
When I want a document drafted or revised in a flat, plain voice, I send it to Gemini rather than Claude. In my experience, Gemini's default voice sounds much more like me (and likely, you, too.)
The current version of this skill sends Gemini a full bundle, and the bundle is the re-creatable part: the task, the audience brief, my style rules, the source documents with all the context behind the argument, and a list of facts that must appear in the final draft.
When the output comes back, Claude checks it against the facts list and reports any drift as numbered items for my call. If you try this approach, know that Claude never seems to like Gemini's output. To counteract this, I purposely tell Claude that it may format and fact-check, but it cannot rewrite, rank, or clean up another model's output. When I've let it judge, it preferred itself and discarded Gemini wording I would have kept.
Drafts that matter get a full audit by the voice doctor. This is another skill I've made that is its fifth generation. Here's the idea behind it. Ask one prompt to catch everything at once, and it misses things. Give it one kind of problem to look for, and it finds every instance. So /voicedoctor5 runs three narrow passes.
The first pass contains no AI at all. It's a plain text search for all of the banned words and structures in Practice 1. The second pass is the AI scan, and it takes the narrowing idea further: it checks one failure category at a time (negate-then-affirm constructions in one check, preaching and validating in another, empty headers in a third; ten categories in all), and each check sees only that category's five starred pairs before it reads the draft. The third pass sends the whole document to Gemini for suggested edits.
One key feature of the voice doctor is separating the diagnosis from the solution. When it's done, the output is a numbered list where each item quotes the offending text, names the pattern, cites the pair it matches, and proposes a fix. Then I go in and decide which to accept. The separation is the whole point. If I let the model repair the draft on its own, it would write the repairs in its own voice, and I'd be right back where I started. I want it to tell me what's wrong. I decide what to do about it.
Second-opinion is another skill I built, and it's the one I reach for when a piece just won't come together after 2 or 3 rounds of edits. By that point, the problem usually isn't the wording, it's that I've settled into an approach that doesn't work and I can't see past it. More editing won't fix that. What I need is to see how someone else would have built the piece from the ground up.
That only works if the other model has no idea what I wrote. Show it your draft and ask for its take, and it anchors to what's already on the page and hands you back a lightly reworded version of the same thing. Keep the draft away from it, and it has to build the piece from scratch, so what comes back is its own.
So the skill sends Gemini the audience brief and the facts it needs, and never my draft.
To recreate it, all you need is the Step Zero brief (below), a request for two to four fresh options, and your writing rules, sent to a different model with your own draft left out. Claude hands me the options verbatim and unranked, and there's usually a sentence or a structure in there that shows me what my stuck draft was missing.
I wanted to share one last approach that requires no technical installation. The other seven practices in this guide rely on custom skills inside Claude Code. This one works directly inside any tool. I call this Step Zero because it belongs at the very beginning of any writing process. Before you ask a model to write a paragraph, paste the answers to these five questions into the window:
To save time, ask the model to draft the five answers for you. If you have already pasted some notes or an outline into the chat thread, the chatbot can generate these responses in seconds. You can then edit the results to fix its mistakes. Correcting the model's draft is much faster than writing your own, and it keeps your next draft on track.