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.
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, Mini or Nano 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 matters. I want the model to start by copying good examples of my voice, and only after that does it see the list of things to avoid. If the rules come first, the model treats them as the whole assignment, and you get writing that breaks none of the rules and still doesn't sound like you. Clearing the banned list is the minimum bar. Sounding like me is the actual goal, and that comes from the imitation, not the rules.
When I want a document drafted or revised in a flat, plain voice, I send it to Gemini instead of 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.
For really important drafts, I use a skill that I made called /voicedoctor5. Now in its fifth iteration, it's designed to systematically search for all of the common issues. To do this, voicedoctor5 runs three sequential passes on the text.
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 that it diagnoses first. When it finishes, you get a numbered list of potential issues, and each item quotes the offending text, names the pattern it broke, cites the pair it matches, and suggests a fix. Then I can go in and decide which suggestions to accept. 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.
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 has nothing to do with the wording. 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 the original draft left out.
Here's one last approach, and it's the only one that needs no skills or setup at all. It works in any AI tool, because it isn't really a trick for handling the model. It's just good writing: figuring out who you're writing for, and what you want them to do. 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.