Your voice and tone guide has a new reader
A style guide used to be read by people who could ask what you meant. Now a model reads it too, and it can't ask. Here's what changes when you write for both.
Who reads your voice and tone guide? For most of its history the answer was writers, who could ask a colleague when a rule was unclear, look at the product for an example, and absorb the house style over a few weeks. The guide has a second reader now, and that reader does none of those things: it treats every sentence as literal instruction, imitates every example it is shown, and fills each gap with the most average version of whatever you described. A guide written for the first reader fails the second in specific, fixable ways, and I found those ways by maintaining the guide for this site, which loads into every Claude session I run in the repo.
A rule with the reasoning cut away
The clearest lesson came from a page of my own. An earlier version of the leadership page on this site was built from short, clipped declarations like "If I don't trust you, I don't hire you." It read as cold even where the belief behind it is warm, because each line states a rule and drops the reasoning, and the guide now says to give the belief behind each rule and the room to explain it. The live page now says: "I have to know I can trust you before you start, because the moment you're on the team I stop reviewing your decisions and start relying on them."
Models imitate the form of whatever they are shown, and Booking.com's writers watched their chatbot copy the inconsistent examples the engineers had supplied (their account), so clipped rules in a guide produce clipped copy in the draft.
The anatomy that holds up for both readers
The guide opens with hard rules for every register, flat and checkable: no em dashes, and real numbers over vague qualifiers whenever a real number exists. A model can verify a rule like that and a reviewer can check it in seconds. Next come nine numbered AI tells collected from flagged drafts, which give the model something specific to avoid and give me a vocabulary for review comments ("announcement sentence" is a complete comment). Each register carries a sample, because description alone does not carry a voice, and a scope section states which source wins when two instructions conflict.
The guide grew by layering
On 2026-09-15 a commit loaded a single writing voice into every session, and on 2026-09-26 another replaced it with the register-based guide. The single voice broke quickly, because one author writes a team announcement, a status note for leadership, a private reflection, an email to an outside partner and the public pages of a site, and the rules for each are opposites in places (parentheticals are welcome in one and stripped from another). The guide's opening paragraph says there is no single tone. What replaced the single voice is a short core that applies everywhere and a layer that applies by context, each small enough for the model to hold. Content teams know this as base voice plus tone by situation, and the machine reader makes it mandatory, because it cannot infer which situation it is in unless the prompt says so.
Grade it before you tune it
Intuit's content design team (their notes) reuses a universal voice prompt inside larger system prompts and has people grade model output against a shared rubric, feeding the patterns back into later prompts. The rubric comes first because "it doesn't sound like us" gives a prompt nothing to edit, while a finding such as "sentences run long and the apology repeats" does. Intuit also warns that the Markdown files grounding its tools go stale, so give your guide an owner and a review date.
What to change in yours
Find every place the guide says to be approachable or human and attach one example that obeys the line and one that breaks it. Put your terminology in a list with the preferred term, the banned term and the reason, because a choice between two near-synonyms is the kind of decision a model will get wrong a thousand times if nobody writes it down. Split the guide into a short core that goes into every prompt and task-specific layers (errors, onboarding, notifications, release notes) that load only when they apply. Start with the vaguest line in your guide and replace it with a sentence of reasoning, an example that follows it and an example that does not.
Be the first to rate this article.
Let's work together.
Open to select projects and collaborations — design systems, accessibility, and AI-native product work.