← All articles

How to write Claude Custom Instructions that actually work

Most Custom Instructions are vague paragraphs that Claude ignores. Here's the 6-section structure that consistently produces sharp, on-voice output — with the common mistakes that quietly break everything.

Better with Claude · tutorial

How to write Claude Custom Instructions that actually work

Custom Instructions are the single biggest leverage point inside Claude Projects. They're also the part most people get wrong on their first try.

The default instinct is to write a friendly paragraph: "You're a helpful marketing assistant who writes in a clear, professional tone." Claude reads this, nods politely, and proceeds to give you generic output indistinguishable from what you'd get with no Custom Instructions at all.

Good Custom Instructions look completely different. They're structured, specific, and opinionated. This guide is the structure that consistently works — with examples and the 4 most common mistakes that quietly break the whole thing.

Why vague instructions fail

Claude has been trained on millions of examples of "clear, professional writing." When you say "clear, professional tone," it averages across all of them and produces median output. You're competing with the entire corpus of generic content on the internet.

Specific instructions cut through. They tell Claude not just what to be but what to avoid, what good looks like, and how to format. Those constraints are what give you outputs that don't sound like a content mill.

The 6-section structure

This is the structure that holds up across hundreds of Projects:

1. Role

Who Claude is in this Project. Specific to the point of feeling constraining. Not "writing assistant" but "senior content strategist at a B2B SaaS company, 10 years of experience, deep technical fluency."

The more specific, the better. Claude has internal representations of what a "senior content strategist" sounds like that's very different from a "writing assistant." Use that.

2. Voice

How you sound when you write. Three knobs:

  • Register: formal, casual, or somewhere in between
  • Energy: direct and punchy, or measured and thoughtful
  • Reference points: if useful, name writers/publications. "Sounds like a knowledgeable peer, not a marketer. Closer to Stratechery than to a SaaS landing page."

3. Default format

What most outputs should look like by default. This is the single best place to enforce your taste. Examples:

  • "Structured prose. No bullet points unless I explicitly ask. Headlines in sentence case, not Title Case."
  • "Always lead with the conclusion. Reasoning follows."
  • "Maximum 300 words per response unless I say otherwise."

Be opinionated. Claude won't guess your preferences — it'll default to the median, which is usually too long and too bullet-heavy.

4. Always

Non-negotiables. The things every output must include or do:

  • "Always lead with a user outcome, not a feature."
  • "Always use concrete numbers and named examples when possible."
  • "Always cite a source when stating a fact about the industry."

5. Never

Often the most useful section. The patterns Claude must avoid:

  • "Never use the words ‘leverage,’ ‘synergize,’ ‘unlock,’ ‘robust.’"
  • "Never open a piece with ‘In today's fast-paced world' or any variation."
  • "Never use rhetorical questions to introduce sections."
  • "Never produce 5+ bullet points unless the content genuinely requires a list."

Specific bans work way better than "avoid corporate jargon." List the actual words.

6. What good looks like

The quality bar in one sentence. This is the highest-leverage line in the entire instruction block:

  • "Copy a busy CTO would read to the end and forward to her team."
  • "A reply that feels personally written, not templated."
  • "An analysis a senior partner would sign off on without changes."

Claude calibrates against this. Without it, "good" means "average for the category."

A complete example

Here's what good looks like, end to end:

# Role
You are a senior content strategist at a B2B SaaS company.
10 years of experience writing for technical buyers (CTOs, VPs of Eng).
Deep familiarity with the developer-tools market.

# Voice
- Direct and concrete. Closer to Stratechery than SaaS marketing.
- Sounds like a knowledgeable peer, never a salesperson.
- Confident without being arrogant.

# Default format
- Structured prose, not bullet lists, unless I ask.
- Lead with the conclusion. Reasoning follows.
- 300-500 word responses by default.
- Headlines in sentence case.

# Always
- Lead with a user outcome, not a feature.
- Use concrete numbers and named companies when possible.
- Anticipate the most likely objection and pre-address it.

# Never
- Use: leverage, synergize, unlock, robust, seamless, cutting-edge.
- Open with: "In today's", "It's no secret that", "Did you know that".
- Use rhetorical questions to introduce sections.
- Produce 5+ consecutive bullet points.
- Hedge ("might," "could," "potentially") when stating clear truths.

# What good looks like
Copy a busy CTO would read to the end and forward to her team.
That's the bar.

The 4 most common mistakes

Mistake 1: Too vague

"Write in a friendly, professional tone" tells Claude nothing. Every output Claude produces is already "friendly and professional." Specific bans + named reference points do the work this section was supposed to do.

Mistake 2: Contradictory instructions

"Be concise but include all relevant details." "Be casual but maintain professionalism." Claude picks one, usually the wrong one. Decide which one wins.

Mistake 3: 2,000 words of instructions

Long instruction blocks dilute. The signal-to-noise ratio matters. 300-500 words of tight, opinionated instructions beat 2,000 words of every-possible-edge-case. If you need 2,000 words, you probably need 3 different Projects instead.

Mistake 4: Forgetting to update

Your taste evolves. Your business evolves. Custom Instructions written 6 months ago might no longer reflect what you want. Re-audit your top 3 Projects every quarter — usually you'll find 2-3 lines worth changing.

How to test instructions

Two-step test:

  1. Same prompt, two Projects. Create a duplicate of the Project with no Custom Instructions. Run the same prompt in both. The outputs should be visibly different — different voice, different format, different length. If they're similar, your Custom Instructions aren't doing enough work.
  2. Edge case test. Try an ambiguous prompt — the kind where Claude has to make a judgment call. Does your output follow your Voice + Always + Never rules? If not, find which section it violated and tighten that section.

Iterate based on output, not theory

Every time you have to manually edit a Claude output, ask yourself: "Why did I have to fix this?" If the answer is "the tone was off," that's a Voice issue. If "the format was wrong," that's Default Format. If "it used a word I hate," add it to Never.

Your Custom Instructions should grow tighter over months as you accumulate these patches. After 6 months of weekly use, a great Project has Custom Instructions that produce output you barely need to edit.

A shortcut for the 80% case

Writing Custom Instructions from scratch for 10 different Projects takes hours. Most of the work is generic — "avoid corporate jargon"-type rules apply to almost any business writing.

We've done that work in the Better with Claude Projects Pack. 50 Projects, each one shipped with Custom Instructions already written, tested, and tuned. Import in 3 minutes per Project. Edit later if you want to adjust the voice for your specific brand. Way faster than writing from scratch.

Related articles

tutorial
How to use Claude Projects: the 10 every Pro user should run
11 min
tutorial
The 5 Claude prompt patterns every user should know
8 min
tutorial
Claude Code for non-developers: 10 practical use cases
10 min
How to write Claude Custom Instructions that actually work · Better with Claude