How to Build an Editorial Style Guide Your Briefs Can Point To

Almost every content brief has a line near the bottom that says "follow the style guide," with a link. Click it at most companies and you land on a brand book from 2021: forty slides about the logo, a color palette, a page of adjectives describing the brand personality, and somewhere around slide thirty a note that the company name is always capitalized. Writers open it once. Then they guess.

Nobody reads it.

So editors end up fixing the same things on every draft, by hand, forever. Serial commas added and removed, "sign up" changed to "signup" and back again by a different editor the following week. Each fix takes ten seconds, and a team publishing thirty pieces a month spends a surprising number of editor hours on ten-second fixes that a two-page document would have prevented. This guide covers how to write that document, what to leave out of it, and how it divides the work with your content briefs.

The guide and the brief do different jobs

A brief is disposable. It describes one article: the reader, the angle, the keyword, the examples that have to appear. When the piece ships, the brief is done.

The style guide holds every rule that would be identical across all of your briefs. That is the whole test for what goes in it. If you catch yourself pasting the same sentence into a third brief ("we write in second person," "never call customers users"), the sentence belongs in the guide, and the briefs should stop carrying it.

The reverse matters just as much. A rule that applies to one article or one client stays in the brief. Style guides bloat when people treat them as a place to record every preference anyone has ever voiced, and a bloated guide gets skimmed exactly like the brand book did. The twelve fields of a good brief include a voice section, and it should shrink to two or three article-specific notes once the guide exists.

Start from your last twenty edits

Do not start from a blank page, and do not start by adopting a published manual wholesale. Pull the last twenty edited drafts, with tracked changes or comment history intact. Go through every change an editor made and sort it into one of two piles. The first pile holds changes about this particular article: a weak argument, a missing example, a claim that needed a source. Ignore that pile. The second holds changes the editor would have made to any article by any writer. That second pile is your first draft of the style guide.

On most teams the second pile is short and repetitive. You will find maybe fifteen distinct rules, and four or five of them will account for most of the edits. Those four or five go at the top of the guide, in bold, because they are the ones costing you time.

This method has one real limitation. It only finds rules your editors already enforce. If nobody has ever decided whether you write "AI" or "A.I.," the edits will show inconsistency rather than a rule, and someone has to make the call. Make it quickly. A wrong decision applied consistently beats a right one applied twice out of five times.

What actually goes in

Sections vary by team, but a working guide for a content team usually covers the following, in roughly this order of how often each one comes up in edits.

Your product and company vocabulary. This is the biggest section and the one generic manuals cannot give you. Write down how every product name and plan tier is spelled and capitalized. Say what customers are called (clients, members, customers, teams) and what they are never called. List the competitor names writers tend to misspell. A writer can look up the serial comma anywhere. Nobody outside your company knows that the feature is "Smart Folders" in the UI but was "auto-folders" in last year's launch post, and that you never want the old name used again.

Mechanics. Heading case, serial comma, numerals versus spelled-out numbers, date format, how you write percentages. Pick a base manual to settle everything you do not list. AP and Chicago both work; the Google developer documentation style guide suits technical content well. Then write down only your exceptions to it. "We follow AP except for the serial comma, which we use" is a complete and useful sentence.

Voice, described through examples. This is where most guides fall apart, because they describe voice with adjectives. Every company on earth claims to be friendly and clear, and those words give a writer nothing to act on. Show pairs instead. Take a real sentence from an old draft, then show the rewrite the editor made, with one line explaining why. Five of these pairs teach more than a page of personality description.

Claims and sourcing. What counts as a source you will cite. Whether you link competitors. How recent a statistic has to be. Whether writers can quote customers by name, and who clears that. If your industry has legal exposure (health or finance, say, or anything with the word "guarantee" nearby), this section is short and strict and has a named owner in legal or compliance.

Formatting for the page. Paragraph length, how you use lists, whether you use bold for emphasis, how links are phrased, what image alt text should look like. Keep it to what your CMS actually renders.

A banned list. Words and phrases that have crept into drafts and that you want gone. Keep it honest and specific, and include the reason for any entry that is not obvious. A writer who knows why "leverage" is banned (it has appeared in eleven headlines this quarter) respects the list more than one who suspects an editor's pet peeve.

How long it should be

Two to four pages for the core document, which a new writer can read in about ten minutes. Anything beyond that, like the complete product glossary or the full list of approved sources, can live in linked appendices that people search instead of read. The core has to be short enough that a freelancer reads the whole thing before their first draft. Most will read it exactly once, so write it for that single reading.

Wiring the guide into every brief

The link at the bottom of the brief is where the guide goes to be ignored. Move it up, next to the voice section, and add one sentence about which parts matter most for this piece. "Pay attention to the product naming section, this article mentions four plan tiers." Writers follow a guide when the brief tells them where to look.

For freelance writers, send the guide once during onboarding and ask them to flag anything unclear. Their questions show you which rules are written badly. People inside the team stopped noticing the gaps long ago.

If your team drafts with AI assistance, the guide has a second reader now. Paste the mechanics and vocabulary sections into the system prompt or project instructions of whatever model you use, and keep the voice pairs in there as well, since models imitate examples far better than they follow adjectives. The banned list pays off most here. Models have their own recurring tics, and a list of them catches a lot of repetitive phrasing before an editor ever sees the draft.

Using it in the edit

Once the guide exists, editorial comments get shorter. A comment that used to read "we don't capitalize this, also please use sentence case in headings, see my earlier note" becomes "style guide, section 2." That shift frees the editor to spend comments on the argument and the examples, which is the part of editorial feedback that actually improves a piece.

Watch for the edits that keep happening anyway. If editors are still fixing the same rule every week, the rule is either buried or written so vaguely that writers read it two different ways. Both have the same fix. Rewrite the rule with a before-and-after example and move it higher.

Keeping it alive

Give the guide one owner, usually the managing editor or the most senior editor on the team. Anyone can propose a change; one person decides and records it with a date at the top of the document. Without an owner, guides drift in two directions at once, with new rules added in comment threads that nobody writes down and old rules quietly ignored.

Every quarter, repeat the twenty-edits exercise on recent drafts. It takes an afternoon. Rules that no longer show up in edits can move to an appendix, and new repeat offenders get promoted to the top. Product launches deserve their own pass, since every rename creates a vocabulary rule the moment it ships.

Then, finally, delete the line in your brief template that said "follow the style guide" and replace it with one that names the section that matters for this article. That single change does more for consistency across a content program than any amount of rewriting the guide itself.