Rich Brooks opened a blog draft his Claude project had written from a podcast transcript and counted the word “actually” seven times in about 2,000 words. His first thought was that Claude had picked up a bad habit. Then he checked himself. Rich says “actually” about that often. Claude hadn’t drifted from his voice. It had copied it exactly.
I laughed when he told that story on The AI Social Playbook, partly because I recognized it. When I first trained an AI on my own writing, I gave it samples from more than 1,000 of my articles and asked it to describe how I write. It told me I prefer prose to lists, I lean on sci-fi and history for analogies, and I like breaking technical ideas down into simple ones. All useful. What that analysis couldn’t tell me was which of my habits I’d want left out.
If you run social for a brand or for clients, you’ve probably hit the same wall. You finally get a custom GPT or a Claude project writing captions that sound like the brand. A few weeks later, you notice every caption opens the same way, or every Instagram post carries the same cluster of emojis, and you’re back to editing by hand. The training worked. You never told it which parts of the voice to leave behind.
The voice comes from the source material, tics included
Rich’s setup shows why this happens. His project, the AOC Podcast Producer, starts from the episode transcript. As he put it on the show, you’re working from your exact words and your guest’s exact words, so the AI has the voice sitting right in front of it. That’s the strength of transcript-based repurposing, and it’s the source of Rich’s problem. Spoken language is full of filler that sounds fine out loud and clutters a page.
Social teams repurposing webinars, livestreams, or customer interviews inherit the same thing. The source carries your speaker’s verbal habits, and a model told to sound like that speaker will reproduce them.
How Rich trains the tics back out
Start with finished examples
Rich didn’t begin with adjectives. When he built the project, he uploaded transcripts alongside finished outputs he was especially proud of, so Claude could see what good post-production looked like for his show. He calls examples the special sauce, and I agree with him. In the RICCE framework I teach (role, instructions, context, constraints, examples), the examples are the step people skip, because typing “be conversational” feels like enough. The model can’t see what good looks like to you until you show it.
Write voice rules as behaviors you can check
His voice section reads like an editor’s style sheet. Here are a few lines from the instructions Rich shared with me after the recording:
Skip generic blog openings like “Picture this” or “Imagine this” – jump straight into your point
Keep paragraphs short (2-4 sentences) with conversational subheadings
Every Instagram post should end with “link in bio.”
You can hold a draft up against every one of those and see whether it broke the rule. Compare that with “sound authentic,” which no one can verify, including the model.
Read the first outputs for frequency
Errors jump out at you. Repetition hides, because each instance reads fine on its own. Rich spotted the pattern because he was reading a whole 2,000-word post in one sitting. When you review the first batch from any new project, read it once for accuracy and a second time to count: openers, emojis, the phrases you lean on.
Put the fix in a final check, and make it report back
This is the move I’d copy first. Rich didn’t bury the fix in the middle of his voice rules. He added a verification pass at the end of the instructions:
Once the blog has been written, double-check and fix the following:
There are no em dashes. Replace with commas, other punctuation, or rewrite the sentence.
Do not use the word “actually” more than once. Rewrite as necessary.
Now the project’s final notes tell him what it did. On the show, he read one back: “Double-checked, removed all but one of the actuallys.” That line matters more than it looks, because it gives Rich an audit trail. He can confirm the rule fired instead of hoping it did. (My own voice guide carries the same em dash ban, for the record.)
Ask whether it’s a one-off before you add a rule
When an output misses, Rich asks Claude a question before he touches the instructions: is this a one-off, or do we need to update your instructions? Claude gives its read, and Rich makes the call. That keeps him from bolting on a new rule after every bad draft, which is how instruction sets fill up with contradictions, while still catching the patterns that would repeat every week.
Re-check after model updates
Rich was clear that you can’t set this and forget it. Models change, and a project that respected your constraints in the spring can loosen up after an update. Every so often, he goes back to the original knowledge docs and instructions and compares them against what the project produces now.
Where this still breaks
A final check is the model grading its own homework. It handles anything you can count, like dashes and word frequency. It won’t catch a judgment error. In one recent episode, Claude credited Rich’s guest with a line Rich had said himself. Nothing in his rules covers attribution, so Rich caught it the old way, by reading the draft.
It also costs time up front. Rich told me he spends a lot of time on the setup so he doesn’t spend a lot of time on it each week. Today a blog post takes him five to 10 minutes to edit, against two to three hours to write from scratch, and he got there by iterating on the project, not on the first try.
For a social team, the translation is direct. Your platform rules are constraints. Rich’s project writes Facebook posts with no hashtags and Instagram posts that end with “link in bio” because he wrote those rules down. Whatever your brand’s tics turn out to be, the fix goes in the same place: a short final check the project runs and reports on before you ever see the draft. You can watch Rich walk through the whole project, Descript clip step included, in the full episode breakdown.
The list is the asset
Training an AI on your voice gets you a draft that sounds like you. The constraint list gets you a draft that sounds like you after an editor has been through it, and only that second draft gives you your time back.
Keep that list somewhere you own. Rich built his first version as a custom GPT in ChatGPT and later moved to Claude, and the same structure works in a ChatGPT project or a Gemini notebook. When you change tools, the examples and the rules are the part worth carrying with you.
Start small. Pull up the last 10 captions your AI drafted, find the opener or phrase that shows up most, and write the one-line rule that caps it.
