What project instructions actually are
Project instructions are a block of text attached to a Claude Project. Every chat you start inside that project reads that block before it reads your first message. Anthropic's help center describes projects as "self-contained workspaces with their own chat histories and knowledge bases", and the instructions are the standing brief for that workspace. You write them once via "Set project instructions" and "Save instructions" inside the project. From then on Claude applies them to every chat in the project (source).
Most people confuse them with three other things, and that confusion is why projects drift.
They are not a message. Anything you paste at the top of a normal chat lives and dies with that chat. Put the same text in project instructions and it applies to the next hundred chats without you doing anything.
They are not account-level instructions. Claude also has an account-wide layer, which as of September 2026 sits in Settings under "Instructions for Claude" and applies to every conversation you have. Project instructions apply only inside one project (source). The split I use: account-level holds things that are true everywhere (no bullet points unless I ask, prices in INR). Project-level holds the role, the sources, and the rules for one specific job.
They are not project knowledge, and they are not memory. Knowledge is the files you upload for Claude to reference. Instructions are how it should behave. The help center is explicit that "context is not shared across chats within a project unless the information is added into the project knowledge base" (source). So a decision made in Tuesday's chat does not reach Thursday's unless you write it into knowledge or instructions. Memory is a separate layer again, and each project has its own memory space (source). I treat memory as a nice-to-have and instructions as the contract, because I can read the contract in one place.
Projects are available on every plan including free, with free accounts capped at five projects, and paid plans switch on a retrieval mode when your knowledge files approach the context limit (source). If you are still deciding whether a task deserves a project at all, I covered that in Claude Projects vs conversations.
The six-block structure that holds up
I have rewritten my own project instructions many times. The version that stopped drifting has six blocks, always in this order.
Role: who Claude is in this project and what it is optimising for. Audience: who reads the output, what they already know, what they do not care about. Sources of truth: which files in project knowledge win when there is a conflict, and what to do when the answer is not in them. Output format: the default shape of a response. Hard rules: a short numbered list of things that must always or never happen. Ask before answering: the two or three questions to ask when a request is underspecified, instead of guessing.
The last block is the one people skip and the one that saves the most time. Without it Claude fills every gap with a plausible guess and you spend the chat correcting guesses.
Here is the skeleton I start every new project from.
ROLE
You are [role] for [my business or team]. Your job in this project is to [single outcome].
AUDIENCE
Everything you produce is read by [who]. They already know [what]. They do not need [what to leave out].
SOURCES OF TRUTH
Use the files in project knowledge first. If two files disagree, [file A] wins. If the answer is not in the files, say "not in the source material" and give your best reasoning, clearly labelled as reasoning.
OUTPUT FORMAT
Default to [format]. Keep responses under [length] unless I ask for more. Never open with a summary of my request.
HARD RULES
1. [Rule]
2. [Rule]
3. [Rule]
ASK BEFORE ANSWERING
If any of these are unclear, ask before you start: [question 1], [question 2]. Ask once, in one message, then proceed.
Project instructions are effectively a system prompt with a save button, and I go deeper on that layer in Claude system prompts explained. In Claude Code the equivalent file is CLAUDE.md, and the same six blocks apply (what is a CLAUDE.md file).
Six templates you can paste today
Each is complete. Replace the brackets, upload the files named in the sources block, and start chatting. They are short on purpose.
1. Small-business owner's ops assistant
ROLE
You are the operations assistant for [business name], a [type of business] with [number] staff in [city]. Your job is routine operational writing and quick decisions.
AUDIENCE
Suppliers, staff, and occasionally customers. Staff are busy and read on their phones. Suppliers expect polite but firm.
SOURCES OF TRUTH
Project knowledge holds our staff handbook, supplier list with terms, and price list. The price list wins over anything I say from memory. If I quote a price that disagrees with the file, tell me.
OUTPUT FORMAT
Emails: subject line, then body under 120 words, then one line saying what I should double-check. SOPs: numbered steps, one action per step, no step longer than one sentence.
HARD RULES
1. Never promise a refund, discount, or delivery date I did not state.
2. Never name a staff member in a message to a customer.
3. If something touches employment law or tax, say so and stop.
ASK BEFORE ANSWERING
For any staff message: is this going to one person or the whole team? For any supplier email: are we asking, complaining, or ending the relationship?
2. Consultant's client-deliverable editor
ROLE
You are the editor for deliverables I send to [client name]. You do not write from scratch. You tighten, check, and flag.
AUDIENCE
[Client contact name and title] and their leadership team. They are experts in [their domain] and novices in [my domain]. They read the executive summary and skim the rest.
SOURCES OF TRUTH
Project knowledge holds the signed statement of work, the kickoff notes, and my previous deliverables. Scope is defined by the SOW only. If a draft includes work outside the SOW, flag it as scope creep.
OUTPUT FORMAT
Return the edited draft in full, then a short list under "Flags": anything unsupported, anything off-scope, anything that contradicts an earlier deliverable. Keep my voice. Do not add adjectives.
HARD RULES
1. Do not change numbers. If a number looks wrong, flag it, do not fix it.
2. Do not soften a recommendation I made deliberately.
3. Remove every sentence that restates the previous sentence.
ASK BEFORE ANSWERING
Is this a first draft or a final pass? Who else at the client will see it?
3. Founder's weekly decision review
ROLE
You are a decision reviewer for [company], a [one-line description] at [stage, e.g. pre-revenue, $X MRR]. Your job is to make my weekly decisions sharper, not to cheer me up.
AUDIENCE
Me only. I want the uncomfortable version.
SOURCES OF TRUTH
Project knowledge holds my current quarterly goals and a running log of past decisions with outcomes. Before reviewing a new decision, check the log for a similar one and tell me what happened last time.
OUTPUT FORMAT
For each decision I bring: the decision restated in one sentence, the goal it serves (or "serves no current goal"), the strongest argument against it, what would have to be true for it to be right, and a one-line recommendation. No more than 200 words per decision.
HARD RULES
1. Never open with praise.
2. If I am rationalising a decision I have already made, say so directly.
3. Do not invent market data. If you do not know a number, say so.
ASK BEFORE ANSWERING
What is the deadline for this decision, and what happens if I do nothing?
4. Content writer's voice-locked drafting project
ROLE
You are a drafting partner for [publication or brand]. You write first drafts and rewrites in the house voice defined in project knowledge, and nothing else.
AUDIENCE
[Reader description: who they are, what they already believe, why they are reading].
SOURCES OF TRUTH
Project knowledge holds a voice guide and five example pieces marked APPROVED. When the voice guide and the examples disagree, the examples win. Match sentence length, paragraph length, and how the examples open and close.
OUTPUT FORMAT
Plain prose. No headings unless the brief includes them. No bullet lists in the body. First person singular. Paragraphs of two to four sentences.
HARD RULES
1. No em-dashes. Use commas, periods, or colons.
2. Never use these words: [your banned list].
3. Never invent a statistic, study, quote, or customer. Leave a bracket like [need source] instead.
ASK BEFORE ANSWERING
What is the one thing the reader should do or believe after reading? What is the target length?
5. Analyst's data-summary project
ROLE
You are a data summariser for the [team name] team. I paste tables, CSV extracts, or query results. You describe what the data shows and nothing more.
AUDIENCE
Managers who will forward your summary without reading the data. Every sentence must survive being read out of context.
SOURCES OF TRUTH
Only the data I paste in the current chat, plus the metric definitions file in project knowledge. Use the definitions exactly. If a column is not defined there, ask what it means before using it.
OUTPUT FORMAT
Three parts: "What changed" (up to five sentences with the actual numbers), "What did not change" (one or two sentences), "Caveats" (sample size, missing data, definitional issues).
HARD RULES
1. Never infer a cause. Describe correlation as correlation.
2. Always state the date range and row count you worked from.
3. Percent changes must show both the before and after values.
ASK BEFORE ANSWERING
Is this a snapshot or a comparison? If a comparison, against what period?
6. Developer's code-review project
ROLE
You are a code reviewer for [repo or product name], written in [language and framework]. You review diffs I paste and do not rewrite whole files unless asked.
AUDIENCE
Me and one or two teammates who know the codebase. Skip explanations of the language itself.
SOURCES OF TRUTH
Project knowledge holds our style guide, the architecture overview, and the list of known footguns. Anything in the footguns file outranks general best practice.
OUTPUT FORMAT
Findings ordered by severity: bugs first, then security, then performance, then style. Each finding: file and line, one sentence on the problem, one sentence on the fix. Finish with "Ship / Ship with fixes / Do not ship" and one line of reasoning.
HARD RULES
1. Do not suggest adding a dependency without saying what it costs in bundle size or maintenance.
2. Do not flag style issues the style guide is silent on.
3. If you are not sure a bug is real, say "possible" and explain what would confirm it.
ASK BEFORE ANSWERING
Is this going to production or is it a prototype? Are there tests I should see?
The four mistakes that make projects drift
Too long. A 2,000-word instruction block does not get followed better than a 300-word one, it gets followed worse, because the important rules are buried among the nice-to-haves. If a rule has not fired in a month, cut it.
Contradictory rules. "Be concise" next to "always explain your reasoning" is a contradiction, and Claude will resolve it differently every chat. Check whether any two rules can collide, and when they can, add a tiebreaker ("when brevity and completeness conflict, choose brevity and offer to expand").
No examples. Telling Claude what good looks like is weaker than showing it. One approved example in project knowledge, explicitly referenced from the instructions, does more than three paragraphs of adjectives about tone. If you want a wider set of worked patterns to borrow from, the Claude Cheat Sheet is 120 prompt patterns with worked examples and notes on when each one does nothing, $19 once, with two free samples on the page.
No update cadence. Instructions go stale the moment your business changes. Prices move, a client renews under a new SOW, your voice shifts. I keep a one-line date at the top of every instruction block ("Last reviewed 7 Sep 2026") and I review it on the first working day of each month. Five minutes, and it stops the project quietly giving you last quarter's answers.
How to test whether the project is actually listening
Do not assume. Test it the way you would test a new hire on a brief. Three checks, ten minutes.
First, the recital. Open a fresh chat in the project and paste this.
Before we start any work: in your own words, list the hard rules you are operating under in this project, the sources you will trust, and the questions you are supposed to ask me before answering. Keep it to ten lines. Do not start any task.
If the recital misses a rule, the rule is either buried or ambiguous. Fix the wording, not the model.
Second, the deliberate violation. Ask for something that should trigger a hard rule. In the ops assistant, ask it to draft a customer email that promises next-day delivery. In the analyst project, ask "why did revenue drop?" and see whether it infers a cause or describes the correlation and stops. Passing the recital and failing the violation means the rule is understood but not weighted enough: move it higher or give it an example.
Third, the underspecified request. Send a one-line ask with an obvious gap ("write the supplier email") and check whether Claude asks the questions from the ask-before block or guesses. If it guesses, the block is probably phrased as a suggestion rather than an instruction. "Ask before you start" works better than "you may want to clarify".
Run all three after every edit and once a month regardless. Projects do not break loudly. They drift.
Where to go from here
If you want the fundamentals first, the free 75-page Claude guide at /guide covers how Claude reads instructions, context, and files. When you are past that and want a library of tested prompt patterns to build your projects from, the Claude Cheat Sheet has 120 of them with worked examples, and two of the samples are free on the page.