AI Brand Voice Guidelines: Why Mine Are Mostly a List of Things Not to Say

I have a written voice spec. It is not a brand book. It is four months of me correcting the same mistakes in the same order, eventually written down so I would stop typing them.

Most of it is a list of things not to say.

That surprised me when I finally read it back. I had expected the useful part to be the description of how I sound. Instead the description sits at the top doing very little, and the working half is a set of prohibitions, a set of rules that spell out exactly what breaks if they are ignored, and a set of mechanical constraints that have nothing to do with tone at all.

I run about fourteen launched products and three blogs, and a lot of the copy that goes out is drafted by a model before I see it. So I have had an unusual amount of feedback on what a voice document does and does not do. This is what I learned, including the part where my own file contains a contradiction I have not resolved.

Why AI copy still sounds like AI after you write brand voice guidelines

The standard advice is to pick three to five adjectives, add a short do-and-do-not table, and paste it in. I did that. The output got slightly better and stayed obviously machine-written.

The reason is simple once you see it. Every adjective people choose is one the model already believes it is producing. Ask for friendly, confident and direct, and the model will tell you the draft is friendly, confident and direct. It is not lying. Those words have no edge. They do not rule anything out, so they cannot change anything.

The second reason is that the tell is not in the word choice. It is in the shape. A model reaches for a small number of structures over and over: the universal opener that assumes what most people do, the three-beat arrow list, the closing line that reframes the whole thing as a shift in how we should think. You can swap every noun in that skeleton and it still reads as generated, because readers pattern-match structure faster than vocabulary.

The third reason is the one almost nobody writing about this seems to have hit, and it is the most important. A voice guide is not a setting. In Claude Code, the instruction files that carry standing rules are, in Anthropic's own words, treated as context and not as enforced configuration, and the documentation is blunt that there is no guarantee of strict compliance. The file is delivered to the model as a message. It competes with everything else in the window. It is a strong influence and it is not a switch.

That single fact reorganizes the whole problem. If the document is influence rather than enforcement, then the question is not "how do I describe my voice" but "what kind of writing survives being merely influential."

What actually belongs in an AI brand voice guide

The banned list is the half that does the work

My file has more prohibitions than descriptions, and the prohibitions are specific to the point of being petty.

Never open a post with a sentence that begins by asserting what most people do, or what everyone is doing. Never use the construction that pairs a common practice with a newly available alternative. Never close with a line about how the real shift is this, or how something feels less like one thing and more like another. No hype vocabulary: revolutionary, unlock, supercharge, and the multiplier claims. No manufactured urgency. No invented social proof.

Those look like nitpicks. They are the only part of the file I can verify.

That is the actual argument for negatives. A prohibition is checkable and an adjective is not. I can scan a draft for a banned phrase in seconds and get a yes or no. I cannot scan a draft for "confident" and get anything but an opinion, and neither can the model that wrote it. Anthropic's guidance on writing instructions lands in the same place from the other direction: it tells you to prefer instructions concrete enough to verify, and gives examples like specifying two-space indentation rather than asking for properly formatted code. The writing equivalent of two-space indentation is a banned phrase list.

There is a second reason negatives outperform. A description leaves the entire space of bad output available, because everything the model produces feels consistent with the description to the model. A prohibition removes territory. Twenty removed phrases is twenty fewer default moves, and defaults are exactly what makes generated copy feel generated.

Rules that name the damage outlive rules that state a preference

The prohibitions that stuck are the ones that say what breaks.

Compare two versions of the same rule. Version one: use the correct pricing language. Version two: pricing is a ladder from $29 to $199, framed as "$199 or less", never as a flat $199, and sellers keep "up to 81%", never a flat 81%, because live ads and landing pages carry those exact numbers and a wrong version contradicts them in public.

Version two survives compaction, competing instructions and a long session. Version one does not. The difference is not politeness or emphasis. Version two contains a fact, its exact anti-fact, and a consequence, and that gives the model something to hold onto and something to lose.

I adopted that pattern after a specific failure. A model gave me a job title I have never held and wrote it into published copy. It was a reasonable-sounding inference from the surrounding material, and it was wrong, and it went out. The fix was not a request to be more careful. The fix was a line stating what I actually did, the specific thing I am never to be called, and the note that inventing biography damages trust with people who can check. That line has held since.

So the pattern I now use for anything that must not drift: the fact, the anti-fact, the exact numbers where numbers exist, and one clause naming the damage.

The rule most guides skip: rotate the skeleton

Voice documents talk about tone and almost never about structure, which is strange, because structure is where the repetition shows.

My rule is that the same framework does not run twice in a row. Not the same opener, not the same list-then-moral shape, not the same title construction.

I know this rule matters because I broke it on my own blog and did not notice for five days. Three posts in that window used near-identical title constructions, each naming some half of a process that other write-ups skip. Individually every one of them was fine. Read down the index, they were a template. I caught the third one only because I checked the published list before settling the title, and I now do that check every time, against the live list rather than against my notes.

A model will not catch this for you. It has no memory of what you published last week unless you hand it that, and even then it optimizes each piece in isolation. Skeleton rotation has to be a written rule plus an actual look at the last few pieces.

Formatting constraints are voice rules, and leaving them out breaks things in public

This is the part I would add first if I were rewriting my file from scratch, because it is the part that fails loudest.

Markdown does not render on LinkedIn, Facebook or Instagram. Those platforms print the asterisks. A draft full of bold subheads is correct in a document and broken in the feed, so the rule in my file is that social copy is plain text, list items use an arrow character, and paragraphs are separated by double returns rather than single ones so the text does not clump on a phone.

Character limits are worse, because they fail silently until they do not. Posts on X can run to 280 characters, and X's own character counting documentation states that every URL is wrapped by its link shortener and counts as 23 characters regardless of the original length. So the real budget is 280, minus 23 for each link, minus whatever tags you are carrying. A model asked for a short post will happily hand you two hundred ninety-four characters that look fine in a chat window and cannot be published. That has broken for me in production, which is why the arithmetic is written in the file rather than assumed.

None of this is tone. All of it decides whether on-brand copy is usable, and a voice guide that omits it produces drafts that read beautifully and cannot ship. If you are building the publishing side of this, I went deep on the platform-by-platform constraints in a separate piece on what a social posting API actually grants you, and the short version is that the formatting rules are the easy half of that problem too.

Where the file has to live, and why that decides everything

A voice guide pasted into a chat is a voice guide for that chat. The moment you open a new session, start a scheduled job, or hand the work to a second agent, it is gone.

Claude Code loads standing instruction files at the start of every conversation, and it loads them by scope: an organization-managed file, a user-level file that applies to everything you do, a project file committed alongside the code, and a local file for private per-project preferences. They are concatenated rather than overriding each other, broadest first, so the most specific instructions are the last thing read. The memory documentation lays out the full resolution order.

For voice, that hierarchy maps cleanly. The user-level file carries what is true no matter what I am working on: the banned openers, the hype list, the plain-text-on-social rule, the never-invent-biography rule. Each project file carries what is only true there: the pricing language for one product, the positioning for another, the tagline that must be quoted exactly.

Two details from those docs changed how I write the files. Length hurts: the guidance is to target under two hundred lines per file, because longer files consume more context and reduce adherence. And instructions given only in conversation do not survive a context compaction, while a project-root file is re-read from disk and re-injected. Anything you want to hold across a long session has to be in the file, not in something you said an hour ago.

The reason this matters more than it sounds is unattended work. Several of my publishing routines run on a schedule with nobody watching. There is no one in the loop to say "that is not how I talk." Whatever is in the file at the moment the job fires is the entire quality mechanism. That is also why I keep a human gate on anything irreversible, which I wrote about in detail when I mapped the trigger, fan-out and approval layers of my repurposing workflow.

And one honest limit: because instruction files are context rather than enforcement, they can be overridden by a sufficiently insistent prompt or simply lost in a crowded window. If something must be blocked no matter what the model decides, the documentation points at a hook, which runs as a shell command at a fixed point and does not care what the model concluded. A banned-phrase check is a good candidate for that. Mine is currently a habit rather than a hook, which is a gap I am naming rather than hiding.

Contradictions are the failure you will not see coming

Here is the part I have not solved.

My file says no hashtags. Clearly, near the top, in the voice section. It also describes a daily post that ships with four hashtags and budgets its character count around them, because that format works and I kept it.

Both statements are in the same document. I did not put them there in the same week, and for a while I did not notice they were fighting.

The documentation is explicit about what happens next: if two rules contradict each other, the model may pick one arbitrarily. Not the newer one, not the more specific one, not the one nearer the top. Arbitrarily. Which means the behavior looks like drift. The model follows the rule for a while, then does not, and you conclude it is getting worse, when in fact it is choosing between two things you told it.

I fixed this the cheap way rather than the clean way. The rule now states the prohibition and names the single carve-out explicitly, with a note that the carve-out stands until I decide otherwise. It is not elegant. It is unambiguous, which is the property that matters.

If you take one maintenance habit from this, make it that one: read your voice file end to end every month or so and look only for pairs of rules that cannot both be followed. It is a fifteen-minute job and it will explain behavior you have been blaming on the model. This is the same failure mode I described in the instruction files that keep fourteen products from drifting, and it shows up in voice files far more often than in technical ones, because voice rules accumulate emotionally, one irritation at a time.

The rule that has saved me the most rework has nothing to do with tone

The single most repeated correction in my logs is not a phrasing issue. It is an audience issue.

Copy addressed to me kept ending up in pages addressed to a buyer. A landing page that opens with a section on design choices. A training document with a paragraph on recommended next upgrades. A product page explaining the marketing angle behind itself. Every one of those is a sentence the model wrote to its operator, left in a document meant for a customer.

It is an easy failure to produce and a slightly humiliating one to ship, because it makes the page read as an internal draft someone forgot to clean.

The rule is a routing rule rather than a tone rule. Anything a user receives contains zero copy addressed to me or to the agent. Operator material is not deleted, it moves to a separate operator file. Giving the model somewhere to put that content matters, because if the only instruction is "do not write it," it will write it anyway and bury it in the middle.

That is the general shape of a good voice rule, and it is why I distrust guides built entirely from adjectives. Most of my highest-value rules are not descriptions of a personality. They are decisions about what goes where.

How to tell whether your brand voice guidelines are working

Almost nobody who writes about this says how to check. Adherence is treated as something you either have or do not. I use three signals, and none of them is a score.

Correction repeat count. If I type the same correction into a chat for a second time, that correction belongs in the file. Anthropic's guidance says the same thing more or less verbatim, listing "the same mistake a second time" as the trigger for writing something down. This is the highest-signal metric I have, because it is generated by my own irritation and requires no instrumentation. The number of times I retype a correction should trend to zero. When it does not, the file is wrong, not the model.

A mechanical pass over drafts. Before anything publishes, the banned terms get searched for. This catches the hype vocabulary, the banned openers, and, on this blog specifically, any phrasing that would reveal process rather than substance. It takes seconds and it is the only check in my system with no judgment in it.

A skeleton diff. Before settling a title or structure, I look at the last several published pieces and confirm I am not repeating the shape. As above, this is the check I actually skipped, and the one that caught me.

What I do not do is score outputs on a rubric. I have no confidence that a voice score of seven out of ten means anything, and inventing a number would make me feel measured without making the copy better.

For an outside check, Google's guidance on people-first content is more useful than it looks. It asks whether a reader would bookmark or recommend the piece, whether it shows first-hand expertise from actually having done the thing, and whether the content exists primarily to attract search visits. That last question is the useful one, because a voice failure and a substance failure usually arrive together. Copy that sounds generated is usually copy that had nothing specific to say. The helpful content guidance is worth reading as a voice document in its own right.

Build your voice file this weekend

You do not need a brand workshop. You need your own corrections, which you have already written.

1. Open your chat history and pull the last twenty corrections you typed. Not the prompts, the pushback. "Do not start it like that." "That is not what we charge." "Nobody says this." That is your specification and it is already drafted.

2. Convert each one into either a banned phrase or a damage rule. Banned phrase if it is a specific string. Damage rule if it is a fact, in which case write the fact, the anti-fact, the exact numbers, and what breaks when it is wrong.

3. Add the mechanical constraints. Which platforms render markdown, which do not, the character budgets including what a link costs, list formatting, paragraph spacing. Boring and load-bearing.

4. Put it where it loads automatically. A user-level file for what is always true, project files for what is true in one place. Keep each under a couple hundred lines, and prefer trimming to appending.

5. Read it end to end once a month, hunting only for contradictions. Fix them by writing the exception into the rule rather than leaving two rules to fight.

That is a two-hour job and it will outperform any amount of adjective selection.

Watch the workflow this sits inside

The voice file only earns its keep when something is generating at volume, because at one post a week you would simply edit by hand.

The session where I built the machine that made this necessary is the web monitor to content factory workflow. It covers the ingestion side, the fan-out into multiple formats, and where the human belongs in the loop, and the voice layer described here is the quality mechanism underneath all of it. That session has finished, but the full replay is available instantly, with no waiting for a next cohort.

If you want the ongoing version, the Reinventing AI Accelerator is where the live sessions happen, along with the vault of AI apps, tools and agents that come out of them. Members get the builds themselves, not just the recordings. One small ask: if you join, bring a real project. The material lands very differently when you have something specific to point it at.

Frequently asked questions

Should I give the model writing samples or written rules?

Both, but they do different jobs and rules do the harder one. Samples teach cadence and vocabulary, which the model picks up quickly and well. Samples cannot teach a prohibition, because an absence is invisible: no sample demonstrates the opener you never use. Rules are the only way to encode a negative, and negatives are what stop the default patterns. If you are choosing where to spend an hour, write the rules. Add three or four annotated samples afterwards for texture.

How long should an AI brand voice guide be?

Shorter than you want it to be. The practical ceiling in Claude Code is roughly two hundred lines per instruction file, and the documented reason is that longer files consume more context and reduce adherence. So the file is competing with itself: every marginal rule slightly weakens the others. That constraint is useful. It forces you to keep the rules that prevent real damage and drop the ones that express taste. If your file is growing past that, split it by scope rather than padding one file, and put the situational material where it only loads when it is relevant.

Why does the model follow my voice guide for a while and then stop?

Three common causes, in the order I would check them. First, contradictions: two rules that cannot both be followed produce behavior that looks exactly like drift, and the model may resolve it arbitrarily each time. Second, the instruction was given in conversation rather than in a file, in which case it can disappear at a context compaction while file-based rules get re-read. Third, the file is long enough that adherence has degraded across the board, and you are noticing it on the rule you care about most. None of these is the model getting worse. All three are fixable in the document.

Can I just use project instructions or a custom assistant instead of a file?

For interactive work, yes, that is the same mechanism with a different interface. The difference shows up in automation. If a scheduled job runs a draft at six in the morning with nobody watching, the rules have to be somewhere that loads without a human opening an interface. That is the practical argument for a plain file in the repository or in your user configuration rather than settings inside one product's chat interface: it travels, it versions, and any tool you point at that directory reads the same thing.

Does a voice guide help with how AI search engines and Google treat my content?

Indirectly, and not in the way people usually hope. There is no voice setting that earns rankings. What a good voice file does is push the writing toward specificity, and specificity is what both readers and Google's people-first guidance actually reward. The self-assessment questions in that guidance ask whether the content demonstrates first-hand expertise from having done the thing. A voice file full of your real numbers, your real failures and your real prohibitions makes that kind of writing the path of least resistance. A voice file full of adjectives does not.

The short version

Your voice guide is mostly a list of things not to say, and that is not a failure of imagination. It is the only part a model can verify, the only part you can check in seconds, and the only part that removes the default patterns that make generated copy recognizable.

Write the prohibitions. Name the damage next to each fact. Include the unglamorous formatting arithmetic. Put the file where it loads on its own. And once a month, read it looking for the two rules that cannot both be true, because that is the drift you will otherwise blame on the model.