Good morning.
Last week you deleted a word out of an AI draft. You deleted the same word the week before, and the week before that, and nothing on the other end has any idea you keep doing it.
This one is about what happens to a correction after you make it, plus the prompt that reads your edits and writes the rules down for you.
— Sam
IN TODAY’S ISSUE 🤖
The same word you delete every week
Where a correction goes after you fix it
The sixty seconds that stop the drift
The prompt that reads your edits for you
Four rules from my own file, with dates
Why every rule needs a date on it
Three places the file reloads from
The Edit You Make Every Week
I keep a file of words nothing I publish is allowed to contain. It runs about forty entries now: delve, tapestry, robust, seamless, testament, foster, boasts, underscore, landscape when there’s no actual land involved.
Every single one of those got there the same way. A draft came back with the word in it, I took it out by hand, and at some point I noticed I’d taken it out enough times to be worth writing down.
That gap between the first deletion and writing it down is where most people are stuck permanently. They catch the word, fix it, ship the piece, and feel fine about it, because editing is fast and it feels like the job. Next week the word comes back. They fix it again.
An agency owner I work with described this to me as the model getting worse over time. It wasn’t getting worse. He’d made the same nine corrections about forty times each and never told it once.
Where Your Corrections Go
When you fix a draft by hand, the correction goes into two places, and a model can read neither of them.
The first is your head. You now know something specific about how your business writes, and it stays there, available only when you happen to be the one reading the draft.
The second is the edited file itself. That version is better, and it’s sitting in a sent folder or a CMS where nothing will ever compare it against what the model handed you. The difference between those two documents is the most valuable writing instruction you own, and it evaporates the moment you hit send.
So the next session starts from exactly where the last one started. This is why voice feels like it decays. Nothing is decaying. You’re just watching the same starting point produce the same result while your knowledge of what’s wrong with it lives somewhere the work can’t reach.
The Sixty Seconds After You Edit
The habit is small enough that it survives a bad week, which is the only reason it works.
Edit the draft the way you already do. Nothing changes here. Fix it, ship it, move on with your day.
Before you close the tab, ask one question. What rule would have stopped me making that edit? State it so it covers the next piece as well as this one. Asking what you changed instead gets you a list of typos.
Write it as one line in a file. Not a paragraph, not a philosophy. “No em dashes. Use commas, periods or parentheses.” That’s a complete rule and it took eleven seconds.
The question is key, because most edits don’t have a rule underneath them and you’ll write nothing that day. Fine. The ones that repeat are the ones that surface, and they surface in about three weeks. Roughly one edit in five turns into a line, in my experience, which means a file worth having takes a couple of months rather than an afternoon.
What you can’t do is skip the question and try to write the file from scratch in one sitting. I’ve watched several people try it. You end up with “professional but friendly” and “clear and concise,” which describes almost every business on earth and constrains nothing.
The Prompt That Reads Your Edits
Answering the question by hand is fine, and after a few weeks most people stop bothering. So hand that part over.
This one takes the draft the model gave you and the version you shipped, works through every difference, and tells you which of them are rules. Paste it into any model with both versions underneath.
Compare two versions of the same piece of writing and pull out the reusable rules hidden in the edits between them.
VERSION A is the draft an AI model produced. VERSION B is the version I published after editing it by hand.
Work through every difference between the two. For each one, decide which of these it is.
ONE-OFF: the change only makes sense for this specific piece. A fact correction, a name, a detail about this client, a cut made for length. Discard these.
RULE: the change would apply the same way to the next thing I write. A word I removed because I never use it, a construction I rewrote because I never phrase things that way, a structure I imposed, something I always cut.
For every RULE, write one line stating it as an instruction, in the imperative, specific enough that following it would have produced VERSION B without me editing anything. "No em dashes, use commas or parentheses instead" is the right size. "Write more clearly" is not a rule.
Be hard on yourself about the ONE-OFF category. Most changes in any single draft are one-offs. If you produce more than six rules from one comparison you are calling one-offs rules, so go back and cut to the changes that would recur.
Mark each rule CONFIRMED if the same change appears more than once inside this piece, and CANDIDATE if you only saw it happen once.
Output the rules as a plain list and nothing else. No preamble, no explanation, no closing summary.
VERSION A:
[paste the draft the model gave you]
VERSION B:
[paste what you actually published]Three things in there matter, and the prompt stops working if you drop them.
The one-off and rule split is the whole job. Without it a model will hand you back every difference it can find, including the client’s name, and you’ll have forty rules off one draft and no way to tell which matter.
The six-rule cap forces it to discriminate. Models are agreeable and will happily promote a typo fix into a style principle. Capping the output makes it choose.
Confirmed and candidate is the discipline from the last section, moved into the prompt. A change you made once might be a mood. Promote candidates into the file only when a second comparison turns up the same one, and you’ll write fewer rules that you later have to retire.
Run this against the last three things you published and you’ll have the beginnings of a real file this afternoon instead of in two months.
After a few passes the instructions stop changing, and that’s the point to save them as a Skill so it fires on “check this against my voice file” without you pasting anything.
The File Behind This Newsletter
The voice file behind this newsletter runs to a few thousand words. It’s not elegant. It reads like a list of arguments I’ve had with drafts, which is what it is.
Some of what’s in it:
No em dashes anywhere. Replace with commas, colons, parentheses, or a restructured sentence.
Never use “the shift.” It flattens whatever is happening into an abstraction. Name the specific change instead, and if you reach for the word, you haven’t worked out what’s going on yet.
No negative parallelism. “It’s not X, it’s Y” and every variant. State what the thing is and let the reader evaluate it.
No landing sentences. A closing line engineered to snap shut. If it would work as a pull quote on a slide, rewrite it.
That third and fourth one arrived together on July 31, after I ran two versions of the same paid issue and read them back to back. The em dash rule is years old. And I added one last week, after catching the phrase “the one to sit with” in a draft, which is a sentence that announces something is important instead of just saying the important thing.
Forty entries, one at a time, each one paid for by a draft I had to fix. That’s the only way I know to get a file that constrains anything.
The date matters more than it looks. A rule with a date on it tells you which drafts it was written against, and it lets you retire the ones that stopped being true. Two of mine got overwritten in July because a newer rule contradicted them, and knowing when each arrived is what made that call obvious rather than a coin flip.
Where The File Goes So It Reloads
A rule in a chat window lasts as long as that window. The file has to sit somewhere the work reads on every run, or you’re back to re-explaining yourself.
Three places, depending on how you work:
Drop it in a project and every conversation inside that project starts with it loaded.
Reference it from a Skill, alongside the comparison prompt above, and any task that fires the Skill picks up both the rules and the mechanism that grows them.
Put it in the folder your agents run out of and everything reading that folder inherits it, which is the version that scales past you to whoever else is drafting.
Then hand it to the next person who writes anything for your business, which is the part nobody does. The file is the fastest onboarding document you’ll ever write, and it cost you sixty seconds at a time.
Let me know if you have any questions (reply to this email).
Last Byte
The reason this works has nothing to do with AI. You’ve been making these calls for years, in the half-second before you delete a word, and the only thing that’s changed is that there’s now something on the other end that would use them if you wrote them down.
Run the prompt against the last three things you published and you’ll have a file by tonight.
Once it exists, the agent that drafts against it from a corpus of your best work is the Ghostwriter Build Pack inside Cortex, and it’s a lot easier to build when the rules are already written.
Talk soon,
Sam Woods
The Editor
