Skip to content
← All posts

How to Stop Claude Using Em Dashes (and Other AI Writing Tells)

Why Claude keeps using em dashes, the instruction wording that actually stops it, where to set it once so it sticks, and a full de-AI edit pass prompt.

Samarth at CLSkills11 min read
claude writingem dashesai writing tellspromptsediting

Why Claude keeps reaching for the em dash

Nobody at Anthropic turned on an em dash setting, and there is no toggle to turn off. The habit is a style, and it comes from the writing Claude learned from. Well edited magazine prose, essays, and published nonfiction use em dashes constantly, because for a professional editor the em dash is a clean way to insert an aside or land a punchline. A model trained to write like good published prose picks that up, then overuses it, because it has no editor saying that three in one paragraph is too many.

That matters for how you fix it. If it were a setting, one instruction would do the job. Because it is a style, you are fighting a default that reasserts itself every time Claude is under pressure to sound polished. Long answers, persuasive copy, and anything with a reflective tone pull the em dashes back in. So the fix is not one line. It is a replacement rule, a place to store that rule so it persists, and a final check.

I write for clskillshub.com and everything that goes out has to survive a reader who treats an em dash as proof that a person did not write it. That is the reality in September 2026, and this is the workflow I use.

Why "don't use em dashes" alone fails

Three reasons, all of which I learned by watching it fail.

First, negative instructions are weak. "Do not use em dashes" tells Claude what to avoid and nothing about what to do instead. When the sentence it has already started needs a pause, it hits the choice point with no replacement in hand, so the dash wins.

Second, "em dash" is narrower than you think. Claude will sometimes drop the em dash and swap in an en dash or a spaced hyphen, which technically obeys your instruction and still looks like AI output. You have to name all three and say what replaces them.

Third, the instruction decays. In a long conversation, a rule given in message one is competing with twenty messages of context by message twenty. Without a check step at the end, it slips.

The phrasing that works has three parts: a positive rule about how to punctuate, an explicit replacement for each case where a dash would normally appear, and a final pass where Claude re-reads its own output and fixes any it missed.

Here is the version I paste at the top of a one-off chat:

Punctuation rule for everything you write in this conversation: use only commas, periods, colons, semicolons, and parentheses to separate clauses. Never use an em dash, an en dash, or a spaced hyphen as punctuation. Where you would normally put a dash, do one of these instead: end the sentence and start a new one, use a comma if the aside is short, or use a colon if the second half explains the first. Hyphens inside compound words like well-known are fine. Before you send any response, re-read it once and replace any dash you find.

Confirm you understand in one line, then wait for my first task.

The confirmation line is not decoration. It makes Claude restate the rule in its own words, which puts the rule into the conversation twice and makes it hold longer.

Setting it once so it persists

You do not want to paste that every time. Claude gives you two places to store instructions so they load automatically. Both are described in Anthropic's own help article on personalization features.

Account-wide: Instructions for Claude

Click your initials, open Settings, and find the section called Instructions for Claude. Anything you put there applies to every conversation on your account, and the help article lists it as available on all plans. This is where the dash rule belongs if you never want to see one again, anywhere.

Keep it short. This field is loaded on every chat, including the one where you ask for a recipe, so put rules here, not essays. Mine looks like this:

Writing rules that apply to everything:
1. Never use em dashes or en dashes. Use commas, periods, or colons instead. Hyphens in compound words are fine.
2. Do not open with a restatement of my question. Start with the answer.
3. Do not end with an offer to help further, a summary of what you just said, or a question back to me unless I asked for options.
4. Prefer plain words. Say "use" not "leverage", "start" not "embark", "important" not "crucial".
5. Vary sentence length. Do not write three parallel sentences in a row.
Before sending, re-read once and fix anything that breaks rules 1 to 5.

Per workspace: project instructions

If you only care about dashes in client work or blog drafts, put the rule in a Project instead. Inside any Project, click Set project instructions, paste your rules, and click Save instructions. Claude then uses those instructions for every chat within that project, per the projects help article. Projects are on the free plan too, with a cap of five projects for free accounts.

The two layers stack. I keep the short dash rule account-wide and put the longer voice guide for each client in their Project. Project instructions are also where you paste two or three paragraphs of your own writing as a sample, which does more for tone than any list of rules.

One caution: neither layer changes the fact that the habit reasserts itself in long drafts. The stored rule gets you most of the way on a first draft. The rest is the edit pass below.

The full de-AI edit pass

Em dashes are the most visible tell but they are rarely the only one. Once you strip them, the rest of the pattern becomes obvious: groups of three, "it's not X, it's Y" reversals, sentences that balance perfectly against each other, and a sign-off that offers to help. I covered the reasoning behind each of these in how to write AI prompts that don't sound like AI. Here I just want to give you the pass I run on every draft.

Paste this as a separate message after the draft exists. Running it as its own step works better than folding it into the original request, because Claude is now editing a fixed text instead of generating and self-censoring at the same time.

You are editing the draft below. Do not change the meaning, the facts, the structure, or the order of points. Only fix the following patterns. Make every fix, then output the full edited draft, then a short list of what you changed.

1. Dashes. Replace every em dash, en dash, and spaced hyphen used as punctuation. Use a period, comma, or colon. Hyphens inside compound words stay.
2. Tricolons. Wherever there is a list of exactly three adjectives, three nouns, or three parallel phrases used for rhythm rather than because there are actually three things, cut to one or two, or rewrite as a plain sentence.
3. Reversals. Remove every "it's not X, it's Y", "this isn't about X, it's about Y", and "X? No. Y." construction. State Y directly.
4. Balanced pairs. Find sentences built as two mirrored halves ("The problem is A. The solution is B.") and merge or vary them so the rhythm breaks.
5. Sign-off filler. Delete any closing that summarizes the piece, offers further help, asks the reader a question, or tells them what to do next in a generic way. End on the last real point.
6. Opener filler. Delete any opening that restates the topic, says the topic is important, or uses the words "in today's", "in the world of", or "when it comes to".
7. Inflated words. Replace leverage, utilize, delve, embark, navigate (when not about a map), crucial, vital, robust, seamless, comprehensive, transformative, and game-changing with plain words, or cut them.
8. Hedge stacking. Where two hedges appear in one sentence ("may potentially", "could possibly"), keep one.
9. Colon headlines. Remove "Title: Subtitle" patterns in headings and turn them into one plain heading.
10. Final check. Re-read the edited draft and confirm there is no em dash or en dash character anywhere in it.

Draft:
[paste your draft]

The change list at the end is useful for a reason beyond audit. Reading it shows you which tells your own prompts are provoking, and after a few weeks the first drafts come out cleaner because you adjusted the request, not just the edit.

When the pass over-corrects

Run item 2 on a draft that genuinely has three things to list and it will try to cut one. Run item 5 on a sales email that needs a next step and it will delete your call to action. Two fixes: either delete the items that do not apply before you paste, or add a line at the top such as "Exception: the closing paragraph contains a required call to action, leave it." I keep four saved versions, one each for blog drafts, client emails, LinkedIn posts, and internal docs, and the only difference between them is which items are switched off.

If you want the same job as a single reusable command instead of a long prompt, the ghost prompt does something similar with a shorter trigger. The long form above is easier to modify.

A shorter pass for quick replies

For a two paragraph email I use a compressed version:

Rewrite the text below with these constraints, keeping the meaning exactly. No em dashes or en dashes anywhere. No groups of three for rhythm. No "it's not X, it's Y". No closing line offering help or summarizing. Mixed sentence lengths. Output only the rewritten text.

[paste your text]

The long pass is for anything that will be read by more than one person.

Testing whether your setting actually took

After you save an instruction in Instructions for Claude or a Project, do not trust it. Test it with a request designed to provoke dashes. Reflective, slightly literary requests are the most reliable trigger.

Write 200 words on what it feels like to finish a long project, in a thoughtful tone, for a personal newsletter.

If the result has no dashes, your stored instruction is working. If it has one or two, the rule is loaded but losing to the tone pull, and the fix is to strengthen the replacement part of the rule (tell it exactly what to use instead) rather than repeat the prohibition. If it has five, the instruction did not save, or you are in a chat that started before you saved it. Stored instructions apply to new chats, so open a fresh one.

Run the same test once a month. Model updates change default style, and a rule that held in June may need rewording later.

The review checklist

Before anything goes out, I read it once against this list. It takes about a minute for a normal blog post. Use Find in your editor for the first item. If you do not have an em dash handy to paste into the search box, copy one from any earlier AI draft, they are never in short supply.

  1. Zero em dashes, zero en dashes. Search, do not skim.
  2. No list of three used purely for rhythm. If there are three items, there should actually be three items.
  3. No "it's not X, it's Y" or "this isn't about X" anywhere.
  4. No two consecutive sentences with the same structure and length.
  5. The first sentence says something. It does not announce the topic or say the topic matters.
  6. The last sentence is a point, not a summary, a question, or an offer.
  7. No leverage, delve, crucial, robust, seamless, transformative, game-changing, unlock, or "in today's".
  8. No heading in the "Something: Something Else" format.
  9. Bold is used for at most one phrase per section, or not at all. Heavy bolding of key terms is a tell on its own.
  10. At least one sentence a model would not produce: a specific number from your own work, a named example, a concrete detail only you would know.

Item 10 is the one people skip and it is the one that matters most. Everything above it removes negatives. Item 10 adds the thing that proves a person was here. In my case that is usually a number from our own analytics or a note about a mistake I made. For you it will be something from your own work, and nobody can prompt that in for you.

Where this fits in a content workflow

The dash rule and the edit pass are the last two steps of a longer process, and they work far better when the earlier steps are right. If the original request was vague, the draft will be generic, and no amount of de-AI editing turns generic into good. I walk through the whole sequence in how to use Claude for content writing, from brief to outline to draft to this edit.

If you would rather have the punctuation and structure rules as one pattern among many instead of digging them out of this post, the de-AI pass is one of the patterns in the Claude Cheat Sheet, 120 prompt patterns with worked examples and notes on when each one does nothing, $19 once, two free samples on the page at /cheat-sheet#sample. The "when it does nothing" notes exist because this pass is exactly the kind of prompt people run on a bad draft and then blame the prompt.

Start here if you have five minutes

Paste the account-wide rules into Instructions for Claude, run the 200 word test, then run the long edit pass on the last thing you published. The comparison between the two versions tells you more about your own tells than any list can.

If you want the rest of Claude set up properly before you go further, the free 75-page Claude guide covers Projects, instructions, and the core prompt patterns from scratch. After that, the Cheat Sheet has the full set of drafting and editing patterns with the notes on when each one fails.

Read next

How to Make Claude Write in Your Voice: The Voice Brief Method (2026)
Sep 8, 2026 · 11 min read
Write AI Prompts Like Humans
Jul 1, 2026 · 3 min read
AI Coding Assistant
Apr 17, 2026 · 3 min read