Build your own phrase list, then make it earn its place

A fixed list stops teaching you

Published lists of AI-sounding words are a useful starting point and a poor specification. They are built from aggregated observations, which means they describe the average draft rather than yours, and after a week or two of use they stop telling you anything you did not already know.

What does keep teaching is your own repeat list. Every writer has one: a connective they reach for when a paragraph runs out of steam, a verb they use for three different operations, a product name they capitalise three different ways. Those are the terms worth marking, and they are specific to you or to one client.

A configurable matcher is the tool for that job. Literal strings catch exact words and phrases; regular expressions catch the shapes a list cannot hold, such as next-level written with a hyphen, a space or neither, or a figure followed by percent spelled out or as a symbol.

The discipline that makes it work is subtraction. A rule list that grows for months without anything being removed eventually matches a fifth of the document, at which point every mark is noise and you stop reading them.

Rules that pay for themselves

The best literal rules are single words you can no longer see. Not the words a model overuses in general, but the ones you have stopped noticing in your own work because they appear in every third sentence. Triangulate them by reading three of your own pieces back to back.

The best regex rules describe a shape with a small variation: a phrase that sometimes starts a sentence and sometimes does not, a number that carries a unit inconsistently, a citation marker with two possible formats. Each of those is one rule covering four instances you would otherwise mark by hand.

Threshold rules are worth their own entry. A pattern that matches a run of three adjectives, or a sentence over forty words, is a structural rule rather than a vocabulary one, and it is exactly what a phrase list cannot express.

Rules for a specific client are the most valuable of all and the least portable. If one client has asked for no exclamation marks and another wants the product name always capitalised, those are two rules for two projects, and they should be switched off rather than deleted when the project ends.

• A word you use in every third sentence.
• A phrase that appears in two formats depending on the sentence.
• A unit or citation written inconsistently.
• A client-specific style rule you keep forgetting.

Why the preview is read-only

When the text can be edited while you read it, the thing you are judging changes under your cursor and every count becomes a moving target. You mark the draft, edit one sentence, and the per-rule totals now describe a document that no longer exists on the page.

Keeping the preview read-only means the count means something, and it means the same thing a minute later. It also stops the small, seductive detour where a review turns into a rewrite and you lose the evidence of what the draft was like when you started.

The input box is separate on purpose. Paste there, read the marked result below. One extra step, and in exchange you get a stable reading of your own text plus the ability to keep the marked version open while you work on the original somewhere else.

Invalid patterns are reported rather than silently ignored, which matters more than it sounds. A regex with an unbalanced bracket matches nothing and looks like a clean result; being told the rule did not compile is the difference between a finding and a false negative.

Reading the counts without over-reading them

One hit is noise, and hitting a word once does not mean the word is wrong. A rule that fires forty times is telling you something about how you write, and it is usually worth acting on.

The useful move is to turn rules off one at a time and watch what remains. If a document stays covered in marks with a single rule enabled, that rule has found a real pattern. If the marks vanish when you disable one rule, you have found one habit rather than a systemic problem.

Watch for overlap, too. A word can be matched by two rules, and it will be counted twice, which inflates the total and makes a small problem look large. Turn one off and the duplicate disappears from the totals.

And remember what a match is: a place where a phrase appears, not a verdict about authorship. The words on any list are ordinary English, used constantly by careful writers, and the only interesting question is whether the matched phrase is doing any work in its sentence.

Writing rules that survive a case change

The commonest broken rule is one that only matches a lowercase word, written in a list where the rule is case-insensitive and the sentence starts with a capital. The matcher compiles patterns case-insensitively by default, which solves the simple case and creates a new one: a rule for a product name that should be capitalised will happily match the lowercase version and tell you nothing.

Word boundaries are the second fix. A rule for the word art will match article, partial and start, producing a flood of hits that looks like a serious finding. Wrapping the pattern in word boundaries, or writing it as an explicit phrase, cuts the noise to something you can read.

Whitespace is the third. Text pasted from a PDF carries non-breaking spaces, double spaces and soft hyphens, and a rule written for a normal space will miss every instance. Where a phrase might arrive in either form, allow the variation in the pattern rather than writing two rules that will drift apart.

And test a rule on a paragraph where you know the answer before you trust it on a document. Ten seconds of checking saves a review spent chasing hits that are not there or missing a pattern that never compiled.

Sharing a rule list with a team

A rule list is the most portable asset in an editorial workflow: it is short, it is plain text and it encodes what a team has agreed to care about. Shared as a list of patterns, it turns a style guide from a document into a check.

Keep the shared list small and the personal list separate. Six to ten team rules that everybody applies, plus whatever an individual has added for their own habits, and the team rules reviewed on a schedule by the person who owns the style guide.

Name rules in the language the team uses rather than in the language of the pattern. A rule called hedge-stacking disputes is legible in a review note; a rule called regex-3 is not, and a finding nobody can name is a finding nobody acts on.

Write down why each rule exists, at least for the surprising ones. The exclamation mark rule and the product capitalisation rule will both be questioned, and the answer belongs next to the rule rather than in someone's memory of a meeting.

Three rules that earn their place

If you write only three rules, make them the ones that catch the widest class of problem in your own work: a connective you overuse, a phrase that has become a tic, and a shape that hides a missing argument such as then helps with or in order to.

Keep each one narrow enough that a hit is unambiguous. A rule that matches a family of phrases produces hits you have to adjudicate one by one, which is the same work as reading without them.

And measure the payoff. If a rule fires twice in a thousand words and neither hit needs changing, it is costing you attention rather than saving it.

Matching shapes, not just words

The rules that catch the most are the ones that describe a relationship: a noun followed by a passive verb with no actor, a sentence opening with a verb ending in ing, a list introduced and never delivered. Those are structural and no word list will find them.

They are also the rules that need the most care. A pattern too broad will flag every sentence, and a pattern too narrow will never fire. Write the rule on the sample, run it on the draft, and adjust once before trusting the count.

Rules for a second language

If you write in more than one language, the rules do not transfer. Connective habits, sentence length norms and the vocabulary of formality differ enough that a list tuned for English will mostly produce noise in German and miss the tells in French.

Keep a rule set per language rather than a translated one. The patterns are cheap to write and the alternative is judging draft prose against a standard written for another language, which is how careful writers get accused of sounding automated.

Retiring rules

A rule should be deleted when it stops changing your behaviour. That happens for one of two reasons: you have stopped making the mistake, or you have decided the pattern is fine.

Both are good outcomes. The first is the tool working itself out of a job; the second is you having made a judgement, which is the actual point of an annotation layer. Keeping the rule in either case turns a sharp instrument into decoration.

Review the list monthly, or at the end of a project. Ten rules that fire and matter beat sixty that produce a wall of colour, and the wall of colour is how people stop using these tools.