Writing rules a machine can check

A rule a person can follow is not necessarily one a script or a model can check. "Be friendly" means something to a writer and nothing at all to a machine. So you rewrite the guidance until every rule has a definite pass or fail. You name the exact words instead of the sentiment, put numbers on the parts that were left to taste, and stay honest about which rules still need a person to decide. For example, "be friendly" becomes a limit on how much of a message is warmth and how much is information, which is something that is easier for a model to determine.

• Use a model to turn each sentence of a written guide into a check that code can run, then let the code do the checking from then on. The expensive step — reading a vague document and working out what it actually forbids — happens once, when you build the rules. Every check after that is fast, free, and gives the same answer for the same input. Anthropic policy compiler
• Keep the lines you could not convert, and hand them back with the rules you could. Some sentences in a style guide or a policy are too vague to become a check a script can run. Anthropic's policy compiler returns those alongside the rules it did produce, so you can see which parts of the guide still need a person to read and judge them, rather than assuming the whole thing is now covered. Anthropic policy compiler
• Put a number on tone, instead of asking a writer to judge how friendly is too friendly. LobeHub sets a budget of 80% information to 20% warmth, rising to 70/30 at named moments — a first run, an empty state, a long wait, a failure — with a hard cap of one sentence of warmth and a clear next step straight after it. LobeHub
• Sort your rules by the kind of check each one needs. According to Vale, there are four things a script can do without any judgment at all: swap one word for another, flag something that should never appear, count something against a limit (words per sentence, say), or run a formula such as a reading-level score. Anything that fits none of the four needs a person or a model, and now you know which ones. Vale
• Declare on each rule what is allowed to enforce it — a pattern match, a grammar checker, the model checking its own work, or a full review by a model. That stops anyone writing a pattern for a rule that actually needs judgment, and stops anyone paying for a model call on something a script can prove. agent-style
• Give each rule a three-part shape: the rule in words, a pattern that catches it, and the fix to apply. slop-no-more
• Write down an innocent sentence your rule must not flag — a near miss that looks similar but is perfectly fine. It gives you a test for false alarms to run alongside the examples the rule is supposed to catch, and finding one is what shows you where the edge of the rule actually falls. slop-no-more
• Write punctuation rules per surface. What reads well in a paragraph is wrong in a toast or on a button, because every character competes for space there — so the rule for a notification has to be written separately from the rule for body text rather than inherited from it. figma-ux-writing-style
• Put testable numbers in the guidance, so the advice can be checked rather than only agreed with. For example, "keep sentences short" becomes "under 30 words", which is something a script can count and a reviewer cannot argue with. You can also say "~30 words" if you don't want it to be too specific. ux-writing-skill
• Name the exact verbs to use in each situation, rather than describing the tone you are after. For example, Gemini CLI's guide gives two lists of verbs. It uses is, will and must when the product reports something it actually did, and suggests, may and appears when it reports something the model worked out. A reader can then tell a fact from a guess, and a reviewer can check the rule instead of arguing about how confident the sentence sounds. Gemini CLI
• Give a surface with different conventions its own reference file, instead of burying an exception in the main list. For example, Gemini CLI's reviewer switches to a separate rule set whenever the settings file is the one being edited, so settings labels and descriptions follow their own conventions rather than the rules written for error messages and status text. Gemini CLI
• Let the same rule be stricter in some languages than in others. For example, Reelang blocks the dash outright in English, German and Dutch, but only warns about it in Russian, Spanish, French, Hungarian and Portuguese, where the dash is standard or required grammar. A single ban would have been wrong in five languages, so the rule carries a level per language rather than a list of exceptions. Reelang
• Push pattern matching further into prose than it looks like it can go. A pattern can check things that sound like judgment calls: wordiness, reading level, sentence length, and sentences where it isn't clear what a word like "it" refers to. GitLab runs 53 such rules on every documentation change, none of which needs a model. GitLab
• Treat formatting as a tell. Bold-label lists and emoji bullets say "generated" as loudly as any vocabulary does, and both are mechanically checkable. textlint AI-writing preset
• Start from someone else's list rather than a blank page. The i18n content hook runs nine checks every time the file holding a product's interface text is edited. They include a 25-word maximum, plain language with no jargon, an action where one applies, no exclamation marks, no banned words (please, invalid, disabled, oops), sentence case, and Oxford commas. Most of those apply to almost any product, so they are a reasonable set to adopt as a first step, before you work out what yours should be. The i18n content hook

Saying what you couldn't check

A tool that reports nothing wrong is telling you one of two things. Either it looked and found nothing, or it never looked — and you cannot tell which. Here the tool says which. It marks the questions it had no way to answer, lists the checks it did not run, and refuses to give a verdict on anything its evidence cannot settle.

For example, it can prevent a tool from looking at the code and saying with confidence that there's only one primary button on the screen, even though the real rendered page shows more than one.

• Write down what your tool is not able to judge. For example, if your tool is analysing a static design in Figma, it should not claim to know whether the interface is usable, accessible, localised, or built the way it was drawn. Every review tool should know what kind of evidence it actually has, so that it doesn't overclaim. balise-ux-writing
• Pair each kind of claim with the evidence that can support it. Decide in advance, for each kind of finding, what would settle it: whether reading the code is enough, whether somebody has to look at the rendered page, or whether somebody has to click through the real product. The tool should then give only the verdicts its own evidence reaches, instead of guessing at the rest. LobeHub
• Have the tool mark what it couldn't check. Anything it assumed rather than confirmed should reach the output labelled as an assumption, instead of arriving as fact alongside everything it did verify. Wix /ux-content
• Have the tool hand back two tables with any audit: one listing the checks it ran, and one listing the things it looked at and decided were fine. Together they let a reader tell "nothing wrong here" from "didn't look." better-interface
• Put a line in the report saying how big a difference has to be before it means anything. writing-eval scores a draft on how far it sits from a body of writing you nominated as the target, and it tells its readers to treat differences under 3 points as noise. Without that line, a score that shifts by two points reads as writing that got better, when nothing has actually changed. writing-eval
• Write into the instructions that the tool may not assume anything. Salesforce's version is one line: only apply what was explicitly retrieved. It closes the gap where a model fills in a brand voice from memory instead of admitting it found nothing. Salesforce
• Tell the tool how sure to sound. Writing the expected level of confidence into the instructions stops it stating a guess in the same voice it uses for a rule. figma-ux-writing-style
• Give the judge an explicit "insufficient information" exit, so it's never forced into a fake verdict.
• Be honest about where your checking stops. For example, a hook only sees what the agent does inside its own session, and a check on the pull request only sees what arrives that way, so somebody editing a string by hand slips past both. Say which door you are guarding, so nobody assumes you are guarding the other one. The i18n content hook

Keeping the rules outside the tool that reads them

Your rules can live inside the tool, or somewhere the tool fetches them from. If they live inside it, changing a rule means releasing a new version of the tool and waiting for everyone to update. If they live outside it, you edit one file and every copy picks up the change.

There are four ways to do the second: have the tool read them from the repository it is already working in, fetch them from a URL, ask for them over a tool call, or ship them as a package with version numbers. The choice between fetching live and shipping a version has no right answer. Fetching means everyone is always current but nobody can choose to keep using an older version, and a package means the reverse.

• Publish the rules at a fixed address and have the tool fetch them each time it runs, rather than carrying its own copy. One edit updates every installation with no reinstall, no version bump and nothing to republish — Vercel changes one markdown file and all ~46,800 installs pick it up on their next run. The cost is that it stops working offline, and people can't choose to keep using an older version. Vercel
• Serve your standards over a tool call instead of embedding them, so the rules and the tool can change independently. The same tool then works for any brand. Salesforce
• Look the rules up at run time from where they already live, so the design system's current state is always what applies. Intercom
• Keep the standards in one place and have every other tool read from it, rather than giving each its own copy to drift out of step. Intuit
• Publish the house style as a versioned package, not a document — with releases, diffs, and a version number a team can pin. Keep the terminology dictionary in the same package, so words and rules ship together. SmartHR
• Generate everything you ship from one source, so the skill file, the written spec and the server that answers questions all come from the same definitions and cannot drift apart. Atlassian Design System MCP
• Point your search at the live source instead of maintaining a copy of it. If the guidance already lives in the component library, index that, so nobody has to paste it into a document and paste it again after every change. Intercom VERBI
• Publish your style guide at a URL that returns markdown, not only HTML. GitLab's docs hand back the whole guide as plain text if you add /index.md to the address, so an agent fetches it in one request instead of picking its way through a web page. GitLab
• Never let your guide defer to a guide the agent can't read. "Otherwise follow AP style" is a hole, because the agent has no way to read AP style. If a convention matters, write it down. GitBook

Making the output arguable

When a tool flags a line, the writer can accept it or ignore it, and with nothing else to go on, some people might ignore it. This gives them a third option. The tool names the rule behind each suggestion, so the writer can look that rule up, disagree with it, and take the disagreement to whoever owns the rule rather than arguing with a tool.

It also makes the tool's own mistakes findable, because a suggestion citing a rule it did not actually follow is something you can see.

The commercial worked example is Ditto. Every suggestion already names the rule that triggered it — that is the core of this technique in product form. Through 2026 they also pushed Specs: beside a component in the codebase, a small markdown file (they use the .ditto.md name) lists every piece of user-facing text that component shows — title, button, helper, tooltip — and carries the style rules that apply to those pieces. A root file holds rules that apply everywhere; component files add the specifics. When an agent edits that component, the right rules are already sitting next to the code. A single giant style guide in the repo root gives every component every rule, and agents grab the first thing that looks relevant. Specs try to give the agent only the rules for the surfaces it is touching — so the citation has somewhere precise to point.

• Cite the triggered rule on every suggestion, so a writer argues with a rule rather than with the tool. Ditto’s linting does this commercially; Raven’s open audits take the same shape — name the rule, quote the line, suggest the fix. Borrow the finding shape even if you never buy either. Ditto
• Put the rules next to the surfaces they govern, not only in a root guide. Ditto Specs are the 2026 packaging of that idea: declare each text surface on the component, pull matching rules into the file beside the code, and commit it so the whole team shares the same citation target in version control. Ditto
• Put a link on every rule, pointing at the page that explains it. A writer who disagrees with a flag can then read the reasoning behind the rule rather than guessing at it, and can see for themselves whether it was applied correctly. Vale
• Attach a reason to every avoided word. "Supercharge — too marketing-speak" is teachable; a banned-words list isn't. figma-ux-writing-style
• Write "show which guidelines you applied" into the instructions as a requirement, rather than hoping the tool does it unprompted. Salesforce
• Make the agent give its reasoning before its answer, rather than after. Atlassian found it improved the copy itself, rather than only making the tool easier to check. Atlassian
• Number the findings, so a person can reply "fix 1, 3 and 5" and track what's been handled. Metabase
• Give every rule a number, and never renumber or reuse it. When the tool flags a line it cites that number, so somebody can look up which rule was actually broken. GitBook numbers its rules G-10, MS-9 and so on. If those numbers ever shift, every flag raised in the past and every decision you recorded against them starts pointing at the wrong rule. GitBook
• Make every failing verdict carry the replacement copy, rather than a note about it. "Make it more specific" leaves the work with the reader, so it isn't a finding — the finding is the sentence you would put there instead. value-upfront-rewrite
• Give the reviewer a few options to choose between, rather than one suggestion to accept or refuse. Anthropic's /ux-copy returns a table with a row for each option, and columns for the copy itself, the tone it strikes, and what that option is best for. The reviewer makes a choice instead of judging a single answer. Anthropic /ux-copy
• Offer options only where the wording is genuinely a matter of judgment, and give exactly one answer for anything mechanical. figma-ux-writing-style offers alternatives for error messages, calls to action, loading states and headings, and a single correct answer for things like which apostrophe to use, capitalisation, or number formatting. A reviewer shouldn't be handed a menu for something that has one right answer. figma-ux-writing-style

Constraining the tool instead of instructing it

A skill or a prompt only works if the model decides to use it, and sometimes it doesn't. So instead of telling the tool what to do and hoping, you set limits that hold even when the model ignores its instructions.

They come in two kinds. Some are checks that run on every change and block anything that breaks a rule a script can settle on its own. Others are boundaries set before the tool starts: what it may read, what it may change, and what it has to ask about rather than fill in itself.

• Let the agent run the mechanical checks on its own draft. This does not undo keeping the writer and the reviewer apart, because a check like this involves no judgment and gives the same answer whoever runs it. Having the agent run it while it drafts means it fixes what it finds, rather than finishing and handing somebody a list to work through. textlint AI-writing preset
• Use the lock pattern when a review must not be skippable: block any edit to a copy file until a review has run, have the review leave a marker recording that it happened, and expire that marker afterwards so the next round needs a fresh one. Windy Road
• State an edit boundary — the list of things the tool may read, and the shorter list of things it may change. An agent working in a live design file or a codebase can do real damage by writing where it was only meant to look, so the two lists have to be written down separately. balise reads the text and structure of the design file and hands back suggested copy, and is never allowed to edit the file itself. balise-ux-writing
• Default to read-only when you can't tell what was being asked for. A request that might mean "review this" or might mean "change this" should get a review and a report back, not a guess, because a review nobody wanted costs a read and an edit nobody wanted costs the work. balise-ux-writing
• Name the things the tool may never invent — prices, limits, policies, research findings. For example, if you ask a model to write a pricing page and don't give it the prices, it might make some up, and the made-up numbers will sound just as certain as the copy around them that is true. The tool has no way of telling which facts it is allowed to supply and which it has to ask for, so you have to write that list down. balise-ux-writing
• Make rejection the default when the tool decides what gets into a set. bco-signals excludes a job posting unless every required criterion is met and at least one of its signal tests passes, rather than admitting things until a reason to remove them turns up. Anything it turns away is still written down, with a note naming which criteria would have applied, so the same item isn't assessed from scratch next time. bco-signals
• Keep judgment out of the automatic gate. A gate should hold only rules a script can settle with certainty, because one that tries to decide something arguable will be wrong often enough that people may start working around it — and once they do, the mechanical rules stop holding too.
• Separate "the tool ran" from "the content is acceptable" in whatever the tool reports back. Finding problems is a successful run. Whether those problems are bad enough to stop the work is a separate decision, and it belongs to the team. If the tool reports failure every time it finds something, then whatever it happens to flag becomes the thing that blocks work, and nobody ever decided that. writing-eval

Learning from every correction

Every time a reviewer changes something the tool produced, they are telling you what it got wrong. So you keep those corrections instead of letting them disappear into a review thread.

A correction you see once is worth writing down. The same correction twice is worth acting on, either as a new rule if a script can catch it, or as a stored test case if it needs judgment.

• Save every answer someone marked wrong as a permanent test. That one habit builds a growing set of real, hard cases for almost no extra work — you're not running a project to collect test data, you're keeping what users already told you. Duolingo
• Treat a human edit as a signal, and feed it back into the standards. When somebody changes what the tool produced, that edit is evidence the guidance was either wrong or missing. Atlassian routes those changes back into the content standards the tool reads, rather than letting each one stay a private fix in one document. Atlassian
• Promote a correction the second time you see it. Once is worth writing down. Twice means it becomes either a rule the script checks, which a model can draft for its own recurring mistake, or a stored test you re-run from then on if it needs judgment.
• Don't let the agent invent a new label the first time it sees something. bco-signals needs the same pattern in at least two separate postings before a new grouping can be created, and states the bar plainly: would a second reader independently notice this as a distinct, recurring pattern? Without a floor like that, a tagging system grows a new category every time it meets something slightly unfamiliar, and the labels stop meaning anything. bco-signals
• Watch which way the number is moving, not what the number is. If people can mark each of the tool's suggestions good or bad, the share marked good will settle somewhere. Duolingo's settled at around 80%. That figure on its own says very little, because it depends on your product and how hard the work is. What tells you something is a change: a rate that starts falling means either the tool got worse or the work got harder, and both are worth looking into. Duolingo Slack agent

Separating the writer from the checker

A model asked to check its own draft, in the conversation that produced it, will approve it. You can instruct it to be harsh and it will still approve it, because the reasoning that produced the draft is sitting right there and reads as justification.

So the fix is not a better instruction. You run the check somewhere the drafting never happened, so the reasoning behind the draft isn't sitting there for the model to agree with: a fresh agent starting with a clean slate, or a separate process.

Metabase goes a step further and ships its reviewer as a separate skill with no ability to write at all, so it has to report what it found rather than fixing it and moving on. A permission holds where an instruction might not.

Two 2026 packages restate the same separation without inventing a new technique. Uxcel’s microcopy skill writes first, then hands the draft to companion review skills — a flow audit, an accessibility look at the language, a dark-patterns check — instead of declaring victory after the draft. ContentRX runs one editorial brain through many doorways (chat with an agent, the editor, a pull request, the command line), so the draft moment and the merge moment apply the same standard. If only the pull request is strict, people ignore the early warning; if only the chat agent is strict, bad copy still merges.

• Hand the review to a fresh agent, in a conversation that holds none of the drafting. Role-playing a critic in the same conversation doesn't work, because the model rates its own output favourably however you word the instruction. Wix /ux-content
• Pair every write skill with a named review skill, and make the handoff part of the workflow — not a polite suggestion at the bottom of a README. Uxcel’s path is generate, then refuse to call it done until a review lens has run; sota-ux-writing ships write and audit as two modes of the same system. Uxcel
• Take the write tool away from your reviewer. Metabase's review skill lists the tools it is allowed to use: read, search and run. Write is not among them, so the reviewer cannot change the file even when it decides it should, where an instruction not to edit would have left that up to the model. Metabase
• Let the writer and reviewer use one shared rules file, so the thing that drafts and the thing that checks can't disagree. ContentRX’s architecture lesson is the same idea at product scale: one opinionated standard everywhere the check runs, or you have three tools and no standard. Metabase · ContentRX
• Compare two versions blind, and set the bar before you look at the results. When ux-writing-1 was tested against the model it was tuned from, both rewrote the same 90 strings, and a reviewer judged each pair without knowing which answer came from which. The bar was agreed in advance: at least 60% preference across at least 30 comparisons where the reviewer actually had one. It came out at 83%. ux-writing-1
• Don't let an automatic score decide whether the writing got better. The same two models were also scored automatically, and the numbers came out almost identical, 0.928 against 0.917 — a gap too small to mean anything. Human reviewers preferred one of them 83% of the time. Anyone reading the score alone would have concluded the tuning did nothing. ux-writing-1

Deciding terminology and keeping it consistent

Terminology is the set of words your product has agreed to use for the things in it — one word per concept, with the alternatives ruled out.

First, you need to work out which words need a decision at all. Then you need to make that decision, and make the tool stick to it. The approved words go in front of the model before it writes, and a script checks the output against the same list afterwards, since a banned word is something a script can settle on its own.

The localization industry built tools for this before content design did, and one of them put a number on it. Lingo.dev matches terms by meaning rather than by exact spelling, so a request about a bill finds the entry for invoice, and that cut terminology errors by 59% on regulatory content.

• Write your terminology as closed lists. Set out the full set of words you are allowed to use, rather than a set you would prefer. For example, LobeHub lists every term its product may use and tells the agent never to alternate synonyms, so nothing drifts between bot, assistant and AI agent. It does the same for verbs, so the same action is always called the same thing. A closed list is something a script can check, where a preference can only be argued about. LobeHub
• Give your terms severity types — preferred, allowed, forbidden — so a gate can block on one class and merely warn on another. Locize
• Make terminology decisions before the copy exists. Terminology decided during design is a decision; decided after launch, it's a migration. Wix terminology-research
• Filter out the words that don't need a decision, rather than treating every word as a term worth fighting over. The Wix skill keeps a concept only when all three of these are true: users will see the word on screen, there is more than one reasonable thing you could call it, and different teams would otherwise call it different things. Anything that fails one of those is dropped. Wix terminology-research
• Rank your sources in advance, so a disagreement resolves by rule rather than by the agent's judgment in the moment. The Wix skill weighs four of them in a fixed order: the company's own internal glossary first, then how users actually talk about the thing, then industry convention, and plain language last. Wix terminology-research

Reviewing the whole screen

Most checks read one string at a time, which catches a bad sentence but never catches a bad screen. Here the tool looks at every string together, in the place it appears, and asks whether somebody reading it would know what to do next.

It is also the only kind of review that can come back and say the words are fine and the screen is the problem. For example, it can tell you that two buttons are competing to be the main action, or that the thing the copy tells somebody to do isn't on the page at all.

Looking at the screen as a whole doesn't mean skipping the individual strings. Each one still gets read, and the step that makes that work is sorting it by what it is — a heading, a button, a placeholder, an error, a notification — before judging it, so that only the rules for that kind get applied.

Coinbase’s Figma experiment hit the same failure: each string passed on its own, and the screen still did not hold together. Whole-screen review is the fix — grade the frame, not the string list.

• Let the review conclude "this isn't a copy problem." Permission to recommend a different component or layout is what stops it polishing wording on a screen that shouldn't exist in that shape. Wix /ux-content
• Ask whether the user can actually do the thing your copy implies. Read the code to find out rather than assuming, and treat an action nobody can see — behind a hover, an icon, a collapsed menu — as no action at all. Wix /ux-content
• Review content in the same pass as layout and type, and consolidate to one verdict, rather than issuing separate audits. better-interface
• Grade the frame, not each string in isolation. If title, body, and actions do not answer each other, the screen fails even when every line would pass a string-level lint. Write that relationship check into the instructions — Coinbase had to, after per-string grading approved incoherent modals. Coinbase

Testing with simulated readers

You describe a handful of readers: what they already know, and what they came to do. Each one runs as a separate agent that sees the screen and nothing else, including nothing of what the others have said.

They are not asked whether the copy is clear, because anything can be talked into saying yes. They are asked what they would do next. A simulated reader who reaches for the wrong button has found something that asking "is this clear?" would never have surfaced.

How much you can trust the answers is still an open question. Simulated readers do reproduce broad patterns of response, but a 2026 Google Research comparison against a real field study found they miss the variety and depth of what people actually do. They work as a cheap first pass between a draft and real users, not as a replacement for talking to anyone.

• Run each simulated reader as a fully separate process, with no visibility into the others' answers. If they all run in the same conversation, each one sees what the others have said and starts agreeing with them, so five personas give you one opinion five times over. claude-persona
• Base personas on real user research, and ask what they'd do, not what they think of the copy. A persona can be prompted into saying it likes something; "which button would you click" is much harder to fake. claude-persona
• Test decision screens by showing only the buttons. Hand a fresh agent the labels on their own, with none of the surrounding copy, and ask which one it would click. If it picks differently from the one you intended, that is a finding, and asking "is this clear?" would never have produced it. Wix /ux-content

Retrieving the right rules at the moment of writing

Your style guide, glossary and approved copy sit outside the model, in files it can search. When a request arrives — write the empty state for the invoices screen, say — the agent searches that material, pulls out only the parts bearing on that request, and works with those in front of it, the way a new writer might work with the style guide open to the relevant page.

Handing it everything every time costs more and works worse. You pay for every word you send, a long prompt gets skimmed rather than read, and rules written for somewhere else get applied here. For example, the tone rules for a marketing email will make a tooltip worse if they arrive alongside it.

Two things decide whether it works. Your material has to be broken into pieces small enough to fetch one at a time, each labelled with the kind of thing it applies to, or the search returns whole documents and you are back to handing over everything. And the request has to be sorted into a kind before anything is searched, so only the matching part gets read. Most bad output from this technique is the model faithfully following a rule that should never have been fetched.

• Attach the guidance to the component rather than to a document, so that where a string sits is what selects its rule. Frontitude binds its guidelines to design-system components, so rewriting any instance of EmptyState loads the empty-state rule without anyone searching for it. Frontitude
• Have the tool work out what kind of question it is before it searches anything, then search only the part of your material that matches rather than all of it. Most bad answers come from a rule that was fetched when it should never have been. PayFit

Putting worked examples in the prompt

Instead of describing what good looks like, you show it. Five to ten pairs of before-and-after copy go straight into the prompt or into the skill file, and the model copies the pattern it can see. There is nothing to search and nothing to keep in sync.

The catch is that nothing gets left out. Every rule and every example you wrote is in front of the model on every request, whether or not it applies to the job in hand. That is fine for ten examples. Once the file is long enough to hold rules that pull in different directions, the model has no way of telling which one it is supposed to follow.

It is still worth starting here, whatever you eventually build. If ten good examples don't improve the output, then breaking your whole style guide into files for the tool to search won't either, and that is a great deal more work. This is the cheap way to find out whether handing the model your rules helps at all.

• Write your guidance as before-and-after pairs. The same pair shows a model what good looks like, gives a reviewer something concrete to judge against, and doubles as a test case you can re-run later. You write it once and it does three jobs. ux-writing-skill
• Write new copy against copy that was already approved, not only against the rules. Frontitude's assistant reads the approved copy library alongside the guidelines, so when it drafts a new string it has your actual sentences in front of it rather than only a description of them. Rules never cover everything: how long a heading usually runs, how formal the product sounds, whether you say "we". Approved copy is where those unwritten decisions can be seen. Frontitude

Mining the rules out of copy you already shipped

Most products carry far more copy than written guidance, and that copy already holds decisions nobody wrote down. Here you point an agent at your live product, have it read every customer-facing string, and get back a draft style guide built out of the patterns it found. Ditto's onboarding agent does this from a codebase, and Crowdin's Copilot does it from past translations.

What you get back is a starting point rather than a finished guide, and somebody has to read it, because shipped copy holds your inconsistencies alongside your conventions and nothing in the output separates the two. For example, if three screens say "Delete" and a fourth says "Remove", the mined guide records whichever appeared more often, not whichever you would have chosen.

• Mine the rules from the copy you already shipped, then ratify them by hand. It gives you a first set of rules to work from without writing one from nothing, but keep in mind that production copy contains your inconsistencies too. Ditto
• When you can't put your voice into words, measure it instead. Take 25 to 40 pieces of writing you already approve of and record what they have in common — sentence length, how often openings repeat, reading level, how varied the vocabulary is — then score new writing against those numbers. It gives you something to check against in the gap between an abstract principle and a banned-words list. writing-eval

Reusing a string instead of writing one

Before writing anything new, the tool searches your approved copy for a string that already does the job. In a product of any size a good deal of what looks like a writing task turns out to be a lookup, and using the string that already exists is what keeps the same action worded the same way everywhere.

Ditto does this twice over: as a tool the agent calls while it drafts, and as a check on the pull request that catches a duplicate before it merges.

• Have the tool search your approved copy for a string that already does the job, before it writes a new one. In a product of any size, a good deal of what looks like a writing task turns out to be a lookup. Ditto

Shaping and sizing the tool itself

These are not techniques for producing content. They are the decisions teams made about the tool itself — how big the entry file is, when each source gets read, how two tools avoid triggering on the same request, and what you can change without rewriting anything.

• Keep the entry file small and load everything else on demand, so the tool only reads what the task in front of it needs. Intercom's loads 120 lines out of 1,000. Intercom
• Tag every source with when to read it — always, per component, on search, or as a suggestion. Ambiguity about when to consult a document is what makes agents skip it. Intercom
• Put the guardrails in the standing instructions the model gets before every request, rather than in a review step afterwards, so they apply to every answer instead of only the ones that reach the review. Intercom VERBI
• Make every tool's description say what it does and where it stops, naming what its nearest neighbour covers instead. Then run an automated check for descriptions that have started to overlap. That combination is what stops a large set of small tools slowly duplicating each other. Designer Skills Collection
• Audit your tool set for competing descriptions. Two skills triggering on the same request is a failure mode that stays invisible until someone looks for it. Intuit
• Write the trigger words people actually say, taken from research rather than from your own vocabulary. Intuit
• Keep single-purpose capabilities separate from the workflows that call them, so you can improve one without rewriting every workflow that uses it. Designer Skills Collection
• File each rule by what it governs — the words in one file, the way the screen behaves in another. A new rule then has one obvious home, and the files never drift into saying the same thing differently. LobeHub
• Turn a framework into a sequence of steps rather than a list somebody has to remember. A list gets skimmed and half-applied, whereas steps in a fixed order get worked through. ux-writing-skill
• Make adding a check a matter of writing a config file, not writing code. Then anyone can add one. Duolingo
• Let the output adapt to where it lands. The same tool collects every issue and posts them to a pull request in one batch, as a comment rather than a blocking change request — and falls back to a plain numbered list in the conversation when there is no pull request to post to. Metabase
• Require a localization section in the output. Anthropic's /ux-copy ends every response with notes for translation: idioms that won't carry across, words that get much longer in other languages, anything that depends on local context. It puts the cost of localization in front of somebody while the copy can still be changed, rather than after it has shipped and gone out for translation. Anthropic /ux-copy
• Spend your effort on the architecture, not the prompt wording. Six months of improving the instruction didn't move quality at Wix; splitting the job into separately verifiable checks did. Wix /ux-content
• Decide what you're building before you tune it. Temperature, the dial for how much a model varies its answers, reads as though writing needs a high setting — but a tool applying your style guide wants consistency, not variety. PayFit started at the most creative setting, got what they called a flood of hallucinations, and settled near the factual end. PayFit
• Ask a model to shorten its own instructions once you have written them. It can usually cut a lot without changing what the tool does, which leaves more room for the task itself. Intercom reports a 70% reduction with behaviour intact.
• Write down the problems you haven't solved, where anyone reading about your tool will see them. Windy Road keeps theirs as numbered open problems in the same repository as the tool. Their problem 077 is a gate that passes copy matching every documented rule while the copy still sounds wrong. That is more useful to somebody building the same thing than any of the parts that work. Windy Road hooks