How to Stop Claude From Repeating Its Verbal Tics (The Complete Fix)

You asked Claude to write something clean and professional, and it came back with “It’s not that this approach is wrong, it’s that there’s a more nuanced way to think about it.” Again. For the fifth time this week. You want to stop Claude from writing that phrase, and about fifteen others just like it, and you are not alone.

Claude has a set of deeply baked stylistic habits: rhetorical constructions, hedging phrases, and filler transitions that recur constantly across outputs. Some are mildly annoying. Others actively undermine the tone of your product. This guide shows you exactly how to kill them, permanently, using system prompts, CLAUDE.md configuration, and as a last resort, API-level filtering.

The Crutch Phrases Claude Reaches For (And Why They Exist)

Before you can stop Claude from using a phrase, it helps to understand why it reaches for these patterns in the first place. Claude is trained on an enormous amount of human writing, and certain rhetorical structures appear constantly in that training data, especially in explanatory, argumentative, and instructional text.

The result is a set of go-to constructions Claude treats as “helpful” even when they are not:

• The pivot reframe: “It’s not that X, it’s that Y.” Used whenever Claude wants to soften a correction or redirect. Feels diplomatic in moderation. Becomes grating at scale.
• The certainty hedge: “It’s worth noting that…” / “It’s important to keep in mind that…” These appear constantly in academic and professional writing, so Claude learned they signal seriousness.
• The faux-humble opener: “Certainly!” / “Absolutely!” / “Great question!” Response cheerleading. Harmless once, infuriating after the hundredth time.
• The unnecessary adverb stack: “Essentially, fundamentally, this is really just…” Claude stacks softening adverbs before delivering a plain statement.
• The meta-commentary wrapper: “Let me break this down…” / “Here’s how to think about this…” Claude narrates what it is about to do instead of doing it.

None of these are technically wrong. They all appear in good human writing. The problem is density: Claude uses them far more frequently than a skilled human writer would, and they drain authority from your prose.

Method 1: Stop Claude From Using Phrases via System Prompt

The fastest fix is a direct prohibition in your system prompt. Claude follows explicit negative instructions well, especially when the prohibited behavior is clearly named.

Here is a battle-tested block you can paste directly into your system prompt:

STYLE RULES — follow these without exception:
- Never use "It's not that X, it's that Y" constructions.
- Never open a response with "Certainly", "Absolutely", "Great question", or "Of course".
- Never use "It's worth noting", "It's important to remember", or "It bears mentioning".
- Never narrate what you are about to do. Do it.
- Avoid stacking softening adverbs: essentially, fundamentally, basically, simply, just.
- Write in plain, direct prose. One idea per sentence where possible.

A few notes on making this work reliably:

Be specific, not general. Telling Claude to “write more concisely” or “avoid filler” does almost nothing. Naming the exact phrases you want eliminated is far more effective. Claude can match against specific strings in its context window in a way it cannot match against vague stylistic descriptions.

Put the rules near the top of the system prompt. Instructions buried at the end of a long system prompt get deprioritized. Stylistic rules especially need to be seen early.

Use the imperative mood. “Never use X” outperforms “please avoid X” or “try not to use X.” Claude interprets hedged instructions as more flexible.

Repeat critical rules. If one phrase is a dealbreaker for your product, list it twice: once in the rules block and once inline before the task. Repetition increases compliance on the items that matter most.

This approach works well for one-off API calls and short-lived chat sessions. For something more permanent, you need the next method.

Method 2: Use CLAUDE.md to Enforce Style Rules Permanently

If you are using Claude Code or the Anthropic API in a long-running project, system prompts are fragile. You have to remember to include them. They drift between teammates. They get edited and the style rules quietly disappear.

CLAUDE.md solves this. It is a configuration file that Claude Code reads at the start of every session, automatically, without you doing anything. You define your style rules once and they apply forever.

Here is what a solid style section in a CLAUDE.md looks like:

## Writing Style

When writing any prose, documentation, commit messages, or code comments:

- Do not use "It's not that X, it's that Y" constructions. Rewrite as a direct statement.
- Do not open responses with affirmations ("Certainly!", "Of course!", "Absolutely!").
- Do not use "It's worth noting", "it's important to mention", or similar throat-clearing.
- Do not narrate your process ("Let me walk you through..."). Just do the thing.
- Prefer active voice over passive voice.
- Prefer short sentences. Break compound thoughts into separate sentences.
- No em dashes. Use a comma, colon, or separate sentence instead.

The advantage of CLAUDE.md over a system prompt is persistence. New conversation, same rules. New project member clones the repo, same rules. You refactor your system prompt for a new feature, style rules survive because they live in a separate file.

For a deeper look at building CLAUDE.md files that actually change how Claude behaves across a project, see our guide on Best CLAUDE.md Files for Claude Code (2026). And if you want a broader framework for making Claude outputs consistent across sessions, How I Made My Claude Setup More Consistent covers the full system.

Wait, that framing is backwards. Let me clarify: both methods are good. Use the system prompt for quick fixes and one-off sessions. Use CLAUDE.md for anything project-level or longer-term. They are complementary, not competing.

Method 3: API Filtering as a Backstop

Sometimes a phrase slips through despite good system prompt hygiene. This can happen when Claude is mid-generation and a verbal tic appears before the constraint context fully activates, or when a very long output causes earlier instructions to fade in influence.

For production applications where consistency is non-negotiable, a post-processing filter is the right answer. The idea is simple: after Claude returns a response, run it through a regex or string replacement layer before displaying it to the user.

Here is a lightweight Python example:

import re

PHRASE_REPLACEMENTS = [
    # The classic pivot reframe
    (r"[Ii]t'?s not that (.+?), it'?s that", r"Rather,"),
    # Faux affirmations at sentence start
    (r"^(Certainly|Absolutely|Of course|Great question)[!,.]?\s*", "", re.MULTILINE),
    # Throat-clearing hedges
    (r"[Ii]t'?s worth noting that\s*", ""),
    (r"[Ii]t'?s important to (note|remember|keep in mind) that\s*", ""),
    # Process narration
    (r"[Ll]et me (walk you through|break this down|explain)[^\n]*\.\s*", ""),
]

def clean_claude_output(text: str) -> str:
    for pattern, replacement, *flags in PHRASE_REPLACEMENTS:
        flag = flags[0] if flags else 0
        text = re.sub(pattern, replacement, text, flags=flag)
    return text.strip()

This is a blunt instrument and should be used carefully. Regex replacements can create grammatically broken sentences if the phrase is embedded in complex syntax. Always test your patterns against a representative sample of outputs before shipping to production.

The better use case for API filtering is logging, not replacement. Instead of silently rewriting Claude’s output, log every instance of a prohibited phrase so you can identify which rules need strengthening in your system prompt. Treat the filter as a diagnostic tool that tells you where your instructions are leaking.

How to Test Whether Your Fix Actually Worked

Developers often add phrase prohibition rules and assume the problem is solved. It usually is not, at least not completely. You need to verify.

The most reliable test is adversarial prompting: deliberately ask Claude to write in contexts where it naturally reaches for the banned phrases.

Try prompts like:

• “Explain why my original approach was wrong and what a better approach looks like.”
• “Describe the key difference between X and Y without being condescending.”
• “Help me understand a topic you think I might be oversimplifying.”

These are exactly the contexts where “It’s not that X, it’s that Y” and its cousins appear most often. Run them ten times, vary the content slightly, and check whether any prohibited phrases slip through.

If you are building on the Claude API and want a more systematic approach, you can automate this. Create a test suite of adversarial prompts, run them against your production system prompt, and assert that prohibited phrases are absent in the output. Run this suite every time you update your system prompt. A few minutes of automated testing here will save you hours of embarrassing output reviews later.

One Pattern That Breaks All the Rules

There is a special case worth calling out. Sometimes the phrase you want to stop Claude from writing is not a verbal tic but a structural habit: Claude’s tendency to qualify every claim with “however,” “that said,” or “it depends.”

This one is harder to suppress because it reflects something Claude actually does think: that most things have nuance and caveats. Asking Claude to stop hedging entirely tends to produce overconfident outputs that are worse in a different way.

The better fix here is not “never hedge” but “hedge once per response, at the end, not constantly throughout.” Something like:

When caveats or exceptions exist, address them once at the end of your response in a single paragraph. Do not sprinkle hedges throughout. State your main answer directly and confidently first.

This preserves Claude’s epistemic honesty while eliminating the exhausting rhythm of claim, hedge, claim, hedge that makes its writing feel mealy-mouthed.

For a fascinating look at the gap between what Claude says and what the model actually represents internally, see What Claude Says vs What Claude Actually Thinks. It provides useful context for understanding why these patterns are so persistent.

When the Phrase Is Yours, Not Claude’s

One final check: make sure the phrase you are trying to stop is actually Claude’s habit and not a reflection of your prompt or context. If your source document, your few-shot examples, or your task description use a phrase repeatedly, Claude will mirror it back to you.

Before you revise your system prompt, search your input for the phrase. If it appears in your prompt even once, remove it and test again. Claude is an exceptional pattern matcher and will pick up stylistic signals from everything in its context window, including your own instructions.

The Bottom Line

Stopping Claude from writing specific phrases is not magic: it is explicit, specific instruction combined with systematic testing.

Start with a system prompt prohibition that names the exact phrases you want eliminated. Move those rules into a CLAUDE.md file if you are working on anything longer than a single session. Add a logging filter at the API layer to catch what slips through and inform future prompt improvements. Test adversarially and iterate.

The full toolkit takes about an hour to set up properly. After that, Claude writes the way you want it to without you having to think about it again.

If you want Claude behaving consistently across your entire workflow, not just in one context, the Cursor vs GitHub Copilot 2026 comparison covers how the major AI coding tools handle style configuration differently, which is useful context if you are deciding where to invest your prompt engineering time.

For questions about prompt engineering, Claude API vs OpenAI API 2026 covers the full developer-facing differences between the two platforms, including how each handles system prompt compliance.