The system prompt mistakes that make Claude worse, not better

The system prompt is where most Claude integrations either come together or fall apart. A good one turns a capable model into a focused specialist. A bad one makes Claude hesitant, inconsistent, or subtly wrong in ways that are hard to trace back to the source.

Here are the failure patterns you'll see most often — and what to do about each.

Mistake 1: Writing a system prompt like a legal document

The instinct to cover every edge case in the system prompt is understandable. What if a user asks about competitors? What if they swear? What if they try to get Claude to do something off-topic? You write a rule for each scenario.

The result is a 2,000-word document full of "do not," "always," "never," and "in the event that." Claude reads all of it — but behaves like someone who has been given too many rules and is now paralysed trying to follow them all simultaneously.

The fix: write principles, not rules. "Stay focused on topics related to our product" outperforms a list of thirty prohibited topics. "Match the user's tone — professional but warm" beats five paragraphs about communication style. Trust Claude to apply a principle intelligently rather than trying to enumerate every case.

Mistake 2: Vague identity instructions

"You are a helpful AI assistant for Acme Corp." This tells Claude almost nothing. What does Acme Corp do? Who are the users? What do they usually need? What does a good interaction look like?

Claude will fill in the gaps as best it can — and the gaps it fills in won't match your mental model of what "helpful for Acme Corp" means.

The fix: be specific about context, not just identity. "You are a support assistant for Acme, a project management tool for architecture firms. Most users are project managers dealing with billing, permissions, or getting new team members set up. They're busy and want direct answers, not explanations of what's possible." Now Claude has something to work with.

Mistake 3: Contradicting yourself

System prompts written over multiple sessions, or by multiple people, often contain quiet contradictions. "Keep responses concise" in one paragraph, "make sure to explain your reasoning fully" in another. "Always recommend consulting a professional" alongside "give users clear, actionable advice."

Claude doesn't flag the contradiction — it tries to satisfy both instructions, producing outputs that satisfy neither.

The fix: read your system prompt as a single document before shipping it. Ask: do any two instructions pull in opposite directions? When they do, decide which one wins and remove or reframe the other.

Mistake 4: Not showing Claude what good looks like

You can describe the output you want in great detail and still be surprised by what Claude produces, because descriptions of quality are genuinely hard to interpret consistently. "Professional but warm" means something different to everyone who reads it.

The fix: include an example. One good example of the interaction you want — an ideal question and an ideal response — communicates more than three paragraphs of description. It's not always possible, but when it is, it's the highest-leverage thing you can add to a system prompt.

Mistake 5: Setting it and forgetting it

A system prompt written at launch will drift out of alignment with your product as the product evolves. New features, changed policies, updated pricing, new user personas — none of this makes it into the system prompt unless someone deliberately updates it.

The fix: treat your system prompt like a living document. Review it quarterly at minimum. When something in your product changes, ask whether the system prompt reflects that change. When Claude starts producing outputs that feel off, the system prompt is often the first place to look.

The underlying principle

A good system prompt is clear, specific, internally consistent, and grounded in examples. It tells Claude who it is, who it's talking to, what it should focus on, and what good looks like. Everything else is noise.

When in doubt, cut. A shorter, sharper system prompt almost always outperforms a longer one that's trying to anticipate every scenario.