How to stop AI from using em dashes.

If you want the fastest possible setup: paste a single sentence into each LLM's custom-instructions field and you're done. 90 seconds, three platforms, 90 to 95% effective. If you also use Claude Code (the coding terminal), one extra file install locks the rule in globally across every project. A regex lint script at the end catches anything that still slips through.

If you are wondering why em dashes specifically matter, skip to the FAQ at the bottom. The short version: LLMs overuse them because training data for polished prose uses them heavily while casual human writing almost never does. I check for them when I'm trying to figure out if something is AI-written, and I'm not alone in that. After em dashes, I also check whether someone just find-and-replaced them with hyphens (that pattern is obvious too). Commas-as-replacement reads more natural, which is why the prompt on this page rewrites in context rather than doing a character swap.

Start here: the 90-second setup

This is the minimum viable version. If you only read one section on this page, read this one. For each platform, paste the sentence below into the listed settings field.

• Claude (web / desktop): Settings, Profile, Custom Instructions. Paste. Save.
• ChatGPT: Settings, Personalization, Customize ChatGPT, “How would you like ChatGPT to respond?” field. Paste. Save.
• Gemini: Saved Info, or create a default Gem with the text above as its system instruction.

You are done. The rule sticks across every chat on that account from now on. Reliability runs about 90 to 95% on Claude and ChatGPT; Gemini lands closer to 85% on long outputs. For the missing 5 to 15%, the lint script at the bottom of this page catches anything that slips through.

For Claude Code (global rules file)

This is the most thorough Claude Code setup and the one I use personally. Save the block below to ~/.claude/CLAUDE.md. Claude Code reads this file every session on every project, so the rule applies to all chat output, all generated code, all commit messages, all PR descriptions, across every repo you work in. The block includes code-safe exceptions so it will not break regex patterns, Unicode escapes, or test fixtures that legitimately need dash characters.

# No em dashes or en dashes

Never use em dashes (\u2014, the long one) or en dashes (\u2013,
the shorter one) in any text you write for me.

Applies to: chat replies, commit messages, PR descriptions, code
comments, docstrings, markdown files, JSX text content, string
literals meant for display, generated prose, file names.

Replacements (choose by context, do not mechanically swap):
- Two independent clauses: period + new sentence
- Parenthetical aside: commas or parens
- List or clarification intro: colon
- Compound modifier before noun: hyphen (work-for-hire)
- Numeric range: "to" or hyphen (2 to 5 years)

Self-review before sending: scan for both characters. If found,
rewrite that sentence from scratch. Do not character-swap.

## Code-safe exceptions (preserve these)

Do not strip dashes where they are load-bearing:
- Regex patterns that match U+2014 or U+2013 literally
- Unicode escape sequences in source (\u2014 is fine; only the
  literal rendered character is banned)
- Test fixtures verifying dash-input behavior
- Data files where preserving original characters is required

If removing a dash would change code behavior or break a test,
preserve it and add `// em-dash-ok` as a line comment.

Project-specific override: if a particular repo needs different rules (e.g. it deals with legacy data files that contain dash characters), put a project-level CLAUDE.md at the repo root. Project rules override global rules where they conflict.

Code-safe exceptions (do not strip these)

A strict no-dash rule can accidentally break code if applied too literally. The CLAUDE.md block above lists exceptions explicitly, but here is the short version for anyone writing their own custom instruction:

• Regex patterns that match U+2014 or U+2013 literally. A lint script searching for em dashes needs the character in its regex.
• Unicode escape sequences in source code (\u2014, \u2013). Only the literal rendered character is banned; the escape form is fine and preferred.
• Test fixtures that verify behavior with dash characters as input data.
• Data files (locale files, migration scripts, historical records) where modifying characters would cause a correctness or round-trip issue.
• Existing string literals stored in databases or round-tripped through APIs where modification would cause a data mismatch.

When in doubt: if removing the dash would change code behavior or break a test, preserve it and add // em-dash-ok as a comment on the line. The lint script at the bottom of this page respects that override.

Regex lint script (belt-and-suspenders)

Prompts catch most cases; a regex pass catches the rest. Save this as lint-no-dashes.mjs in your project. Run on any generated file before shipping. Exits non-zero if any em or en dash is found, with file:line for quick fixing.

// lint-no-dashes.mjs
// Run: node lint-no-dashes.mjs <file-or-dir>
// Exits non-zero with file:line for any em/en dash found.
import { readFileSync, readdirSync, statSync } from "node:fs";
import path from "node:path";

const target = process.argv[2] || ".";
const PATTERNS = [
  { re: /\u2014/g, reason: "em dash (U+2014)" },
  { re: /\u2013/g, reason: "en dash (U+2013)" },
];

function* walk(p) {
  const st = statSync(p);
  if (st.isFile()) { yield p; return; }
  for (const f of readdirSync(p)) {
    if (f === "node_modules" || f.startsWith(".")) continue;
    yield* walk(path.join(p, f));
  }
}

let failed = 0;
for (const f of walk(target)) {
  const lines = readFileSync(f, "utf8").split("\n");
  lines.forEach((line, i) => {
    for (const { re, reason } of PATTERNS) {
      re.lastIndex = 0;
      if (re.test(line)) {
        console.log(`${f}:${i + 1}  ${reason}`);
        console.log(`    ${line.trim()}`);
        failed++;
      }
    }
  });
}
process.exit(failed ? 1 : 0);

What to do instead

Every would-be em dash should be replaced by rewriting the sentence in context, not by swapping the character.

FAQ