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

The prompt above works once you paste it into a session. A skill makes it load itself: one file that Claude reads automatically whenever the trigger condition in its own description matches, no copy-paste required.

1. Create the file. ~/.claude/skills/voice-rules/SKILL.md for a personal skill available in every project on your machine, or .claude/skills/voice-rules/SKILL.md inside one repo if the check should only fire there.
2. Phrase the frontmatter’s description as a trigger condition. name: voice-rules plus a description written as “use this skill whenever drafting or editing copy for [site/brand]” — so the skill loads itself the moment a matching request comes in, instead of waiting to be invoked by name.
3. Put the enforcement prompt and both rule tables in the body. A skill has no guaranteed access to a separate file elsewhere on disk, so make it self-contained: paste the instructions from Pattern step 4 above, followed by the Vocabulary and Style tables directly. (Skills can also bundle extra reference files in the same folder if the rule set outgrows one prompt.)
4. Test it cold. Start a fresh session, ask for a draft, and confirm the skill triggers on its own — the check should apply without anyone pasting a prompt or naming the file.

No install step, no server, no repo required — it’s the fastest way to carry the check into a session, and the first thing to reach for before wiring it into anything bigger.

Skip the manual write-up. Download the blank template below, fill in your own vocabulary and style rows, then paste the prompt underneath it — along with your completed doc — into a Claude session. It writes the SKILL.md (frontmatter, enforcement instructions, and your tables) for you.

Download the blank voice-rules template (.md)

I've filled in the voice-rules template. Turn it into a Claude Skill:

1. Create SKILL.md at ~/.claude/skills/voice-rules/SKILL.md for a personal skill available in
   every project on this machine, or .claude/skills/voice-rules/SKILL.md inside this repo if the
   check should only fire here.
2. Write the frontmatter as a trigger condition: name: voice-rules plus a description phrased as
   "use this skill whenever drafting or editing copy for [site/brand]" — not a title, so the
   skill loads itself the moment a matching request comes in.
3. In the body, paste this enforcement instruction, followed by the Vocabulary and Style tables
   from my filled-in doc below, verbatim:
   - 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 and every Style section before returning it.
   - If a rule and the immediate content genuinely conflict, say so explicitly rather than
     silently picking one.

Here's my filled-in doc:

[paste your completed voice-rules-template.md here]

A skill has to be installed on each person’s machine (or each agent’s config) to take effect. Wiring the same check into a repo instead means it comes with the codebase — anyone, or any agent, who clones it and reads its instructions inherits the check for free.

1. Commit the rule doc. Keep the vocabulary and style tables in the repo itself — this site uses docs/VOICE.md — so it version-controls alongside the copy it governs.
2. Point the repo’s shared instructions file at it. Most coding agents read one file at the start of a session (AGENTS.md/CLAUDE.md/GEMINI.md here — often the same file, symlinked, so every tool reads the same source). Add a line like “Drafting or editing any site copy? Also read docs/VOICE.md” to the section an agent already reads first.
3. Stop invoking it manually. Because that instructions file loads automatically, not by opt-in, the check now rides along on every future session in that repo — nobody has to remember the prompt, only that the doc exists.
4. Optional — render it for humans too. If the rules should be browsable, not just agent-readable, mirror them into a typed data file and a small component (this site’s VoiceRulesPanel, rendered above) instead of leaving them only in markdown.

This is one step up from a skill: it doesn’t travel with you across repos, but it does mean every agent working in this one applies the check without being asked, the same way AGENTS.md/CLAUDE.md already does for this site today.

The prompt above works inside one repo, for one agent that already has file access to docs/VOICE.md. Wiring the same rule doc into an MCP server makes the check portable — any MCP client (Claude Desktop, a different agent, a CI job) can call it without cloning the repo first.

1. Keep the source-of-truth format the team already edits. Markdown works, or a typed export like voiceRules.ts. The server should read this file at request time, not embed a copy — that’s what keeps a check from drifting out of sync with a doc someone edited by hand.
2. Scaffold the server. npm install @modelcontextprotocol/sdk zod, then start one file with McpServer from the SDK.
3. Expose the doc as a resource — voice://rules — that reads and returns the file live, so any client can pull the current rules without hardcoding them into a prompt.
4. Expose the enforcement prompt. Register a check-voice prompt that takes a draft string and returns the same instructions from Pattern step 4, filled in. This is the reusable skill: a client calls the prompt and gets back a ready-to-run check, instead of a human copy-pasting one.
5. Add a deterministic lint tool for the flat word list. Skip the model call for anything that’s a straight forbidden-term match: a lint-vocabulary tool that string-matches a draft against the table and returns hits directly. Fast, and it catches word-swap violations the prompt-only path would otherwise spend a model call on — keep both, since tone and cadence still need the prompt.
6. Test with the inspector before wiring the server into anything: npx @modelcontextprotocol/inspector node index.ts, then call the resource, the prompt, and the tool from its UI.
7. Register it with a client — claude_desktop_config.json’s mcpServers entry for Claude Desktop, or .mcp.json for Claude Code — pointed at the same stdio command either way.

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}`,
    },
  }],
}));

The prompt still does the actual judgment call; the server just makes it callable by any agent, not only one already working inside this repo. The same resource/prompt/tool shape generalizes to any severity-tiered rule set — swap the file the resource reads and the term table the tool checks.