Claude learned your bad habits from your last brief.
The opener you killed twice last month shipped to a client this morning.
Claude learned your bad habits from your last brief.
Claude opened a client draft with a banned question lead I had killed twice that month. Not a new mistake. The exact opener I had struck from the last two briefs, regenerated like it had never been flagged. Same opener style. Same buried benefit. Same structure the client pushed back on last quarter. Claude did not invent those patterns. The brief taught them.
Why Claude Repeats the Same Mistakes
Claude does not know what the last writer got wrong. You do. When you hand the model a brief with no constraints, it draws from every pattern it has seen: question openers, feature-led structures, soft value props buried three sentences in. Those patterns exist because they are common. Common is not the same as good.
In email production, the failure mode is rarely a terrible first draft. It is a draft that repeats the exact pattern the client pushed back on last quarter: the same opener style, the same vague benefit statement, the same "we're excited to share" energy that signals filler. Claude will reproduce any pattern it can infer from the brief. If the brief does not block those patterns, the model will find them.
Where the Anti-Pattern Block Sits
The block is the first of four mechanisms in the Remint Prompt Pattern we apply to every published prompt: prerequisites (this block), self-validation (the model checks its own output against the constraints), human gate (you approve before anything ships), and improvement proposal (the prompt surfaces recurring violations without rewriting its own rules).
The anti-pattern block lives in the prerequisites layer. It declares what the model cannot do before the brief tells it what to do. Self-validation then enforces the constraints on the output. The human gate sits between draft and send. The improvement proposal grows the block over time, but only the operator commits the changes.
The Full Wrapper
Here is the structure applied to a single client work. Every section is load-bearing. The bracketed fields are the only places you fill in.
## Prerequisites (required before running)
- An anti-pattern block tuned to this client
- VOICE.md for this client
- A brief with all six fields below filled in
If any prerequisite is missing, do not proceed. Respond:
"Cannot run. Missing: [list]. Provide and re-run."
## Anti-pattern block
Do not:
- [opener move that is out for this client]
- [phrases banned, listed verbatim]
- [structure that has failed for this audience]
- [tone described with an off-brand example]
- [recent revision pattern logged from the last cycle]
## Brief
Email type: [flow position, e.g. third send in a 3-part sequence]
Audience: [profile, last interaction, likely objection]
Offer: [the offer, unchanged across segments]
Goal: [the action the email is asking for]
Tone: [voice register coordinates]
Length: [hard limit on body copy]
## Output format
Subject: [subject line]
Preview: [preview text, max 90 characters]
Body: [email body, no greeting, no sign-off, plain copy only]
## Self-validation (run before returning output)
Before returning, check the draft against the anti-pattern block:
1. No banned phrase appears in subject, preview, or body
2. Opener does not match any banned pattern
3. Structure does not match any banned structure
4. Tone matches VOICE.md, not the off-brand example
5. Body word count is at or below the Length value specified in Brief
If any check fails, fix internally and re-check. If you cannot satisfy a
check after one attempt, return:
"Validation failed: [rule]. Cannot produce compliant copy."
## Human gate (before anything is queued)
After returning the draft, state:
"Review the draft above. Type APPLY to queue this for send, or REJECT with
the specific revision needed."
Do not move the draft to the send queue until APPLY is received.
## Improvement proposal (optional)
If during this run a pattern in the brief made you reach for a banned move,
append at the end of your output:
"PROPOSED RULE ADDITION (review before adding to the anti-pattern block):
[one line describing the move you almost made and why it's worth banning]"
Do not edit the anti-pattern block yourself. Only propose.How to Build Your Client Block
The most useful version is client-specific, not generic. Start with the actual revisions from the last engagement. If the client pushed back on question openers three times in a row, that goes in the block as a verbatim ban. If they flagged "synergy" once, it goes in the block. If they rejected a feature-led structure on the last campaign, that pattern goes in the block with a note on what they prefer instead.
Keep the block in a template file named for the client. Update it every time a revision reveals a pattern the model keeps repeating. Over time, it becomes a fast-loading document of everything you know about what does not work for that audience. The block grows sharper with each production cycle. New team members inherit all of it immediately.
A few rules for keeping the block clean. Be specific about the prohibition, not vague. "No clichés" is not actionable. "Do not open with a question" is. "Avoid jargon" is not actionable. "Do not use the words synergy, leverage, or drive results" is. The more specific the constraint, the less the model has to interpret it.
When the Block Is Working
When the block is working, first drafts come back structurally correct. The opener is not a question. The first sentence leads with a benefit. The tone is calibrated to the client before any revision happens. The feedback loop between what the client wants and what the model generates gets shorter with each new version of the block.
In my audits I often find that teams using Claude for email copy are spending revision rounds fixing patterns the model defaulted to. The anti-pattern block closes much of that gap before the first pass. You spend the revision time on the actual copy, not on undoing defaults.