How to Save and Reuse Claude Project Instructions Across Every New Chat

The short answer: put your instructions somewhere Claude loads automatically, instead of pasting them into every conversation. On claude.ai, that means creating a Project and writing your instructions into its custom instructions field, so every chat inside that Project starts with them already applied. If you work in the terminal, Claude Code reads a file called CLAUDE.md from your project directory at the start of each session, and that file becomes your persistent instruction set. If you build on the API, the equivalent is a version-controlled system prompt. Everything below is about doing this well, because most people stop at "I made a Project" and never get the compounding benefit.

Why pasting instructions every time is a losing game

I resisted this for longer than I should have. I kept a notes file with my "Claude preamble" and pasted it at the top of every new chat. It worked, in the sense that a bucket with a hole in it works. The problems show up over time.

First, you drift. The version you paste on Tuesday is not quite the version you pasted on Friday, because you tweaked one copy and not the other. Second, you forget. The one chat where you skip the preamble is the one where Claude formats things the way you explicitly told it not to, and now you are re-explaining rules you wrote down weeks ago. Third, and this is the real cost, your instructions never improve. When they live in a paste buffer, there is no single place to refine them, so they stay frozen at whatever quality they had when you first wrote them.

Persistent instructions fix all three. One canonical copy, applied automatically, improved in place.

Projects on claude.ai: the main tool for this job

Claude's Projects feature exists almost exactly for this problem. A Project is a workspace that groups related conversations, and it has two parts that matter here.

Custom instructions are the persistent rules. Whatever you write there is applied to every conversation started inside that Project. This is where your standing guidance goes: who you are, what you are working on, what output format you want, what Claude should never do.

Project knowledge is the persistent context. You can add documents, and Claude can draw on them in any chat within the Project. Instructions say how to behave; knowledge says what to know. Keeping those separate is the single biggest quality improvement most people can make. Your style guide is knowledge. "Always follow the style guide, and flag any sentence you were unsure about" is an instruction.

The workflow that falls out of this: create one Project per ongoing area of work, not one giant Project for everything. My split is roughly one Project per product, plus one for writing. The instructions in each are short and specific to that context, which is exactly why they work.

Writing instructions that actually hold up

Most project instructions I have seen are too long, too vague, or both. A few principles that have survived contact with real use:

State constraints, not vibes. "Be concise" does almost nothing. "Answers under 200 words unless I ask for depth. No summaries at the end of responses." does a lot. Claude follows concrete, checkable rules far more reliably than adjectives.

Include context Claude cannot infer. Your stack, your audience, your definitions. "This project is a SwiftUI iOS app. When I say 'the manager', I mean SubscriptionManager." That one line saves a clarifying exchange in every single chat.

Write the failure modes down. When Claude does something you dislike, do not just correct it in the chat. Go update the project instructions so the correction is permanent. This is the habit that makes the whole system compound. A correction made once, in the right place, never needs to be made again.

Keep it short enough to audit. If you cannot reread your instructions in under a minute, you will stop maintaining them, and stale instructions are worse than none because you trust them. When mine grow past a screen, I prune. Every line should change Claude's behavior in a way I can name. If I cannot say what a line is for, it goes.

Claude Code: CLAUDE.md is the same idea for the terminal

If you use Claude Code, the mechanism is a file rather than a settings field. Claude Code reads CLAUDE.md at the start of a session, and it supports layering: a global file in your home directory under .claude for rules that apply everywhere, and a per-repository file at the project root for rules specific to that codebase. Project-level rules take precedence where they conflict, which is the right default. The repo knows its own law.

This design has a property the web interface cannot match: the file lives in your repository, so it is version-controlled, reviewable in pull requests, and shared with anyone else working in the repo, human or otherwise. My global file holds durable working rules (how to verify work, when to ask before acting, formatting requirements). Each repo's file holds only what is true of that codebase: build commands, architecture notes, conventions that are not obvious from the code itself.

The same maintenance habit applies. When Claude Code does something wrong twice, the fix belongs in CLAUDE.md, not in your next prompt.

What does not belong in persistent instructions

Knowing what to leave out matters as much as what to put in.

Anything derivable from the context should stay out. If the code already shows the convention, do not restate it; restating invites drift when the code changes and the instructions do not. One-off task details stay out; they belong to the conversation, not the Project. And secrets stay out entirely. Instructions and knowledge files are configuration, and API keys or credentials have no business in configuration you might export, share, or commit.

Also resist the urge to write instructions for problems you have not had. Speculative rules ("never use recursion") are noise that dilutes the rules earning their keep. Add rules in response to real behavior, and your instruction file becomes a distilled record of everything you have actually learned about working with the model.

A simple system that scales

Here is the whole practice in four habits:

1. One Project (or CLAUDE.md) per ongoing context, with short, concrete instructions.
2. Reference material goes in project knowledge or repo docs, not in the instructions themselves.
3. Every repeated correction gets promoted into the persistent instructions the moment it repeats.
4. Prune on a regular pass. If a line has not changed behavior lately, cut it.

That is it. The tooling is genuinely simple; the leverage comes from treating your instructions as a living artifact instead of a paste buffer. Six months of small promotions and prunes produces something no single writing session could: a precise, tested description of how you want an AI collaborator to work with you.

FAQ

Do project instructions carry over to chats outside the Project? No. Custom instructions apply only to conversations inside their Project. For preferences that should follow you everywhere on claude.ai, look at your account-level settings, which apply across conversations. Keep universal preferences there and project-specific rules in Projects.

What is the difference between project instructions and project knowledge? Instructions shape behavior in every chat: tone, format, rules, role. Knowledge is reference material Claude can draw on: specs, style guides, past decisions. If it is a rule, it is an instruction. If it is a fact Claude might need, it is knowledge.

How long should my instructions be? As short as possible while still being concrete. A focused page of specific rules reliably beats several pages of vague ones, and shorter instructions are the ones you will actually keep maintaining.

Can I share these instructions with a team? For Claude Code, yes, naturally: commit CLAUDE.md to the repository and everyone who clones it gets the same instructions. On claude.ai, team plans support shared Projects, so a well-maintained Project can carry its instructions and knowledge to the whole group.