Claude Project Instructions: Write Them Well
RedHub AI Editorialupdated August 18, 20263 min read
Jump to a section7
TL;DR
- What it is: the custom instructions that apply to every chat in a Claude Project.
- Who it's for: anyone whose Project gives inconsistent results — see how to use Claude Projects.
- How it works: set role, rules, format, and what to avoid — specific enough that any chat behaves the same.
- Bottom line: vague instructions are why a Project feels no different from a chat. Specific ones are the whole point.
How do you write good Claude Project instructions?
Good Claude Project instructions tell Claude four things clearly: the role it's playing, the rules it must follow, the format you want back, and what to avoid. They're specific enough that any chat in the project behaves consistently — a new conversation and a week-old one produce the same style of output. The most common mistake is writing them like a vague job description ("be helpful and professional") instead of concrete direction Claude can actually act on.
Best for: making a Project reliable. The Blueprint Library ships written instructions for ten functions.
The instructions are the part of a Claude Project that most people leave half-empty — and it's the part that decides whether the Project is worth having. Instructions are what make every chat behave the same way without you repeating yourself. Here's the anatomy of instructions that work.
The four things good instructions cover
- Role. Who Claude is in this project — "you are a support reply writer for a B2B SaaS," not just "assistant." The role frames everything else.
- Rules. The non-negotiables — what to always do and never do. "Never invent a policy; if unsure, say so and flag it for a human."
- Format. The shape of the output you want — length, structure, tone. "Reply in under 120 words, warm but direct, no corporate filler."
- Context assumptions. What the knowledge base already covers, so Claude uses it instead of asking. "Product facts are in the knowledge base — draw on them, don't guess."
Specific beats polite. "Be professional" tells Claude nothing it didn't already assume. "Never use exclamation points; lead with the answer, not a greeting" is direction it can actually follow. Write rules you could hand to a new hire.
Vague vs. specific, side by side
| Vague (does nothing) | Specific (works) |
|---|---|
| "Be helpful and professional" | "Lead with the answer in the first sentence; no throat-clearing" |
| "Write good marketing copy" | "Match the brand voice doc; no hype words (revolutionary, game-changer)" |
| "Answer support questions" | "If the answer isn't in the knowledge base, say so and don't invent one" |
The honesty rule worth building in
The single most valuable instruction you can add is a permission to say "I don't know." Left to default, a model fills gaps confidently — which in a Project with real stakes means inventing a policy, a number, or a fact. An instruction like "if the knowledge base doesn't cover it, flag that instead of guessing" turns Claude from a confident guesser into a reliable one. It's the difference between output you can trust and output you have to double-check every time.
Instructions are one of the three parts of a working Project. The Blueprint Library writes them for ten functions so you start from a working example, not a blank box — and the Prompt Practice Lab builds the prompting skill that makes your asks inside the project sharper.
Start from instructions that already work
Ten Claude Projects with the custom instructions written for you — sales, support, marketing, ops, and more.
Get the Blueprint Library — $79 →See how instructions fit with the knowledge base and your prompts in the full Claude Projects guide.
Decision Guide
Rewrite your instructions if: your Project gives inconsistent results or feels like a normal chat.
Keep them tight if: you're tempted to write a novel — a page of specific rules beats five of vague ones.
Best first step: add the "say I don't know" rule and one concrete format rule, and test a chat.
Common Questions
How do I write Claude Project instructions?
Cover four things clearly: role, rules, format, and what the knowledge base already handles. Be specific enough that any chat behaves the same.
Why is my Claude Project inconsistent?
Usually vague instructions. "Be professional" gives no real direction; specific rules about format, tone, and what to avoid produce consistency.
How long should instructions be?
As long as they're specific and no longer. A page of concrete rules beats five pages of vague ones — Claude follows direction, not word count.
What's the most important instruction to add?
Permission to say "I don't know" — "if the knowledge base doesn't cover it, flag that instead of guessing." It's what makes output trustworthy.
Should instructions repeat what's in the knowledge base?
No. Instructions say how to act; the knowledge base says what to know. Point Claude at the knowledge base rather than pasting its contents into instructions.
Can I reuse instructions across Projects?
Yes — a good rule set (like the honesty rule and format rules) travels well. Starting from written blueprints gives you reusable, proven instructions.