Claude Projects Best Practices

A Claude Project works well when it is about one thing, its knowledge is the material every chat in it needs, its instructions are short and specific enough that a stranger could follow them, and whatever the chats decide gets written back into it. Most projects that disappoint fail on the last point: people treat the project as a folder of chats, when the chats cannot see each other and only the knowledge carries forward.

Scope a project to one body of work

A project is a workspace with its own chats, knowledge and instructions, and — where memory is on — its own memory. Anthropic’s help centre on how Claude’s memory works↗ (opens in a new tab) says each project has a separate memory space and project summary, kept apart from other projects and from chats outside projects. That separation is the reason to scope tightly: a project called “Work” gets a memory about everything and focus on nothing.

• Good scopes: one client, one product area, one piece of research, one recurring job such as the weekly report.
• Too broad: a team, a year, “misc”. The instructions end up contradicting themselves.
• Too narrow: one question. That is a chat, not a project.

If a chat lands in the wrong project, move it. The help centre’s guide to creating and managing projects↗ (opens in a new tab) shows the dropdown next to the chat name for adding a chat to a project, moving it between projects, or removing it; where memory is on, removing a stray chat keeps it out of that project’s memory summary.

Choose knowledge deliberately

Everything in project knowledge is used across every chat in the project. That is its strength and the reason to be selective. Upload the material that nearly every chat will need: the brief, the style guide, the reference data, the current version of the spec.

• One current version of each document. Two drafts of the same spec give Claude two answers to choose from.
• Descriptive file names. “pricing-policy-2026.md” tells Claude what it is before it reads a word; “doc3.pdf” does not.
• Text over screenshots where you have the choice. A pasted table is easier to quote accurately than a picture of one.
• Leave out what only one chat needs. Attach it to that chat instead.

Large projects behave differently on paid plans. The help centre on RAG for projects↗ (opens in a new tab) says that when knowledge approaches the context window limit, Claude switches to searching it with a project knowledge search tool instead of loading all of it, which lets a project hold up to ten times more. Its own advice for those projects: clear, descriptive filenames, related material grouped in the same project, and naming a document in your question when you want Claude to use it.

Writing project instructions that work

Project instructions are applied to every chat in the project. One detail to know first: the help centre notes that Claude does not have access to a project’s name and description. Anything Claude should know goes in the instructions or the knowledge, not the description field.

Anthropic’s prompting best practices↗ (opens in a new tab) apply directly. Think of Claude as a brilliant new colleague with no context on your norms, and test instructions by imagining a colleague with minimal context following them. Give the reason behind a rule, because context helps Claude aim at the goal rather than the wording. Say what to do rather than only what not to do.

This project supports the Acme account: a UK retailer we build and run a web shop for.

- Audience for anything you draft: Acme's operations team, not developers. Plain English, British spelling.
- Prices are always ex VAT, because Acme's contract quotes ex VAT and a mixed figure has caused disputes.
- The spec in "acme-spec-current.md" wins over anything in older chats. If a request contradicts it, say so before answering.
- When you are unsure what Acme agreed, say you are unsure. Do not fill the gap with a plausible guess.
- End any drafted email with a one-line summary of what we are asking them to do.

• Keep them short. Five rules that always apply beat forty that sometimes do.
• Make each one checkable. “Be concise” is a hope; “replies under 150 words unless I ask for detail” is a rule.
• Put the why after the rule, in one clause. It is what lets Claude handle the case you did not foresee.
• Point at knowledge by file name rather than restating it. One source of truth, not two.
• Rewrite, do not append. When a rule changes, change the rule; a later line contradicting an earlier one leaves Claude to pick.

Write conclusions back into the project

The help centre says it plainly: context is not shared across chats within a project unless the information is added to the project knowledge. Memory helps, but it is Claude’s summary, not your record. So when a chat settles something — a decision, a definition, a corrected fact — end it by asking Claude to write that up in a few lines, and add the result to the knowledge.

A single file called something like “decisions.md”, newest first, with the date and who agreed, does more for the next chat than any amount of history. It also answers the question colleagues ask a shared project: what did we agree?

Keep it current, and archive when it is done

• When a document is replaced, remove the old one the same day. Stale knowledge is worse than missing knowledge, because Claude uses it with confidence.
• Reread the instructions once a month. Delete the rules nobody needed and the ones that no longer hold.
• If you find yourself correcting Claude the same way twice, that correction belongs in the instructions.
• When the work ends, archive the project. The help centre says archived projects keep their knowledge, members and permissions, and their conversations stay reachable; you must unarchive one before you can delete it.

When to split a project

Split when the instructions start to fork: “for the mobile app do X, for the website do Y”. Split when the knowledge contains material some chats must not draw on, such as one client’s documents beside another’s. And split when the audience changes, for instance an internal project and a version you intend to share with a wider group. Two focused projects with overlapping reference files are better than one that has to be told, in every chat, which half of itself to ignore.

Sharing has its own rules — who can see what, and why your chats stay private — covered in can Claude Projects be shared. If part of the work belongs in a repository rather than a chat, see Claude Projects vs Claude Code.

When the project turns into a task list

A sign a project has outgrown itself: the knowledge file you update most is a list of open tasks. A file cannot say who is working on what or record who changed it, and other assistants cannot write to it. That list belongs on a board. On fenbs, Claude connects with the Claude connector and reads and updates tasks under your role, and the rules you would otherwise repeat in each tool’s instructions live once, as AI context on the board.