The single most useful thing I have built into my artificial intelligence (AI) workspace is not a clever prompt. It is a gate: a rule that fires on a pattern the model can detect in its own draft, and forces a fixed checklist before that draft ever reaches me. It is unglamorous and it is the reason the assistant's output is hard to tell from my own writing.
Preferences Decay, Conditions Do Not
Everyone starts by telling the assistant how they like things. Be concise. Do not use em dashes. Lead with the answer. This works beautifully for about an hour. Then the session gets long, the context fills with the actual problem, and the standing preference quietly stops being applied. You correct it, it apologizes, it complies for three messages, and it drifts again.
The failure is structural, not moral. A preference is a thing to be remembered, and remembering competes with everything else in the context. So stop asking it to remember. Give it a condition instead.
The rule I use reads roughly: before emitting any text that looks like a message a person will read as from me, run this checklist and revise until every line passes. The trigger is not a mood. It is observable in the draft itself. Does the output open with a greeting or a name. Does it carry a subject line. Did I ask for a note, a reply, a summary to send. Any of those match and the gate fires, because the model can see them by looking at what it just wrote.
Three Properties That Make It Hold
| Property | What it buys |
|---|---|
| Triggers on an observable signal | It fires reliably, instead of being remembered inconsistently |
| Every check is binary | Each line passes or fails, so there is no judgment call to drift on |
| Runs before output, not after | You never see the draft that would have needed fixing |
The third row is the one people underrate. A checklist you apply after reading a bad draft has already cost you the reading. A gate that runs first means the bad draft does not exist.
What Goes On the List
Mine covers voice, leading with the answer, formatting rules precise enough to be mechanical, no raw links, concision, and one that matters more than the rest: nothing invented. Every factual claim has to trace to something in the thread, a file, or a source I can open. No inferred status, no guessed dates, no plausible-sounding numbers. That single line prevents the failure mode that actually costs you credibility, which is not a clumsy sentence but a confident wrong fact.
Two rules of thumb from living with this. Every item has to be checkable by reading the draft alone, because an item that needs information the assistant does not have will simply be skipped. And it has to stay short enough to run every time: a twenty-item gate is a gate that gets half-run. Six to eight items is where it stays honest.
Take It
Here is the whole thing as a file you can drop into your assistant's always-on instructions: output-gate.md. Swap my checklist for your own non-negotiables and keep the structure, because the structure is the part that works.
The general lesson is bigger than one checklist. Anywhere you find yourself repeating a correction to an assistant, you have found a place where you are relying on memory and should be relying on a condition. A preference is a hope. A gate is a rule.
This is part of a track on agent tooling and spec-driven development that goes deeper than a field report, with something you can download and run in each one. Free for now while the track grows; the deepest installments become a paid tier later.