Voice Rules: The Prompt That Keeps AI Copy On-Brand

Problem

A publication drafts copy across many separate sessions, and if it’s AI-assisted, many separate context windows. Without a written rule set, “brand voice” lives only in the author’s head — every new draft re-derives it from vibes, drifts a little further each time, and there’s no way to check whether a paragraph is on- or off-voice except a gut read. The fix used in production systems that publish at real volume isn’t a style guide nobody rereads — it’s a small, structured rule set a model is required to check a draft against every time it writes, edits, or rewrites something.

Pattern

Two pieces: a source-of-truth voice doc, and a prompt that enforces it.

1. Split the doc into two layers. Vocabulary — approved term ↔ forbidden synonyms, scoped by audience, ranked by severity. Style — off-brand behaviors (never), avoid-lists with the exact trigger words (default to break), cadence patterns to watch (not banned, just monitored), and tone principles. Word-level rules and sentence-shape rules get violated differently; conflating them into one flat list makes the doc unreadable and unenforceable.

2. Rank severity, don’t just list rules. Two tiers: CRITICAL (never break) and PREFERRED (holds by default, breakable with a stated reason). A flat “don’t use these words” list degrades into being ignored the first time a real sentence needs an exception; a severity split tells the drafting model which violations to refuse outright versus flag and explain.

3. Ground every rule in real copy, not taste. Mine the site’s own published pages for what’s already working — recurring phrases, sentence shapes, register splits — instead of inventing rules from scratch. A voice doc that contradicts the copy already live is worse than no doc at all. This site’s own /vibe-check page (a field guide to AI-slop design tells) turned out to already contain a full specimen of AI-slop copy too — “Unlock Your Next-Level Growth Journey,” “seamlessly delivers real results,” “Game changer!” — which became the forbidden-word list directly, instead of a guessed one.

4. Write the enforcement prompt. The doc is inert until a model is told to load and apply it on every call:

   You are drafting or editing copy for [site]. Before writing anything, read [path to
   VOICE.md] in full.
   
   - Treat every CRITICAL rule as a hard constraint — if a draft would violate one, don't
     write that version; find the compliant phrasing instead.
   - Treat every PREFERRED rule as a default — hold it unless there's a specific reason to
     break it, and say what the reason is if you do.
   - Check the draft against the Vocabulary table (approved vs. forbidden terms, scoped by
     audience) and the four Style sections (off-brand, avoid, patterns, tone principles)
     before returning it.
   - If a rule and the immediate content genuinely conflict, say so explicitly rather than
     silently picking one.

5. Wire it into the repo, not just the session. This site is built by more than one agent across sessions (AGENTS.md’s handoff protocol), so the pointer to the voice doc has to live where every agent already looks first — added to the “read before you write” list at the top of AGENTS.md/CLAUDE.md, next to the existing pointers to SPEC.md and BUILDLOG.md.

6. Render it, don’t just describe it. A markdown doc is easy to skim past. Pull the same rules into a small typed data file (src/data/voiceRules.ts — the same interfaces as the table below) and a plain component that renders them as an inspectable table, not another markdown wall. Two constraints kept it from turning into its own mini design project: no new colors (severity reuses the site’s existing mono .telem / .telem-accent readout labels instead of a colored pill) and no client framework (the tabs below are two radio inputs and a CSS sibling selector — no <script>). docs/VOICE.md stays the source of truth; this table is generated from data that mirrors it, not the other way around, so update both together.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
import fs from "node:fs/promises";

server.resource("rules", "voice://rules", async () => ({
  contents: [{ uri: "voice://rules", text: await fs.readFile("./VOICE.md", "utf-8") }],
}));

server.prompt("check-voice", { draft: z.string() }, ({ draft }) => ({
  messages: [{
    role: "user",
    content: {
      type: "text",
      text: `Before revising, read the voice://rules resource in full. Treat CRITICAL rules as ` +
        `hard constraints; PREFERRED rules as defaults, breakable with a stated reason. Check this ` +
        `draft against it and return violations plus a compliant rewrite:\n\n${draft}`,
    },
  }],
}));

Real result

Adapted from a 35-rule voice-rules system (18 vocabulary + 17 style rules) running in production against a real company’s blog studio — gating every Ideate/Create/Edit/Rewrite call, with company-wide rules for everyone plus a per-author layer on top for individual runs. Scaled down for a one-author site: docs/VOICE.md shipped with 12 vocabulary rules and 17 style rules, mined from this site’s own live copy — the About page, the homepage hero, both previously published recipes, and /vibe-check’s own catalog of tells supplied the forbidden-word list directly. AGENTS.md/CLAUDE.md now points every agent at it before drafting copy, including this recipe, which was checked against it before publishing. The table above is that same doc, rendered — not a screenshot of it.

Variations

• Multi-author sites should keep the two-layer split the production version uses: company-wide CRITICAL/PREFERRED rules plus a per-author layer that only applies to that author’s own drafts — worth adding the moment more than one byline exists here.
• Publishing at higher volume? Move the check from a manual prompt into CI: a pre-commit or PR check that diffs new/changed .mdx against the forbidden-word list and fails the build on a CRITICAL hit, instead of relying on the model to remember to self-check.
• The severity-tiered structure generalizes past prose — apply the same shape (approved/forbidden vocabulary, off-brand/avoid/pattern/tone-principle style) to PR titles, social copy, or release notes with a different vocabulary table and the same enforcement prompt.
• Want it in a single session with nothing to install first? Package it as a Claude Skill — see “Turn this into a standalone skill, step by step” above for the one-file version that loads itself on a matching request.
• Want every agent working in one repo checking automatically, with no prompt to remember? Wire the doc into that repo’s shared instructions file — see “Wire it into a repo, step by step” above for how AGENTS.md/CLAUDE.md already does this on this site.
• Want it callable outside a coding agent entirely — from Claude Desktop, a different agent, or a CI job? Turn it into an MCP server — see “Turn this into an MCP server, step by step” above for exposing the rules doc as a resource, the prompt as a callable primitive, and the vocabulary table as a deterministic lint tool.