How to set up Claude Projects properly

The difference between Claude as a chat partner and Claude as a work partner starts with Projects.

---

Without Projects, Claude starts from zero in every conversation. It has generic memory, but no idea what you're working on, what you've done before, or how you like things done. It's like onboarding a new colleague over and over again.

With Projects, you give Claude lasting context. Documents, instructions, preferences. Everything that stops Claude from guessing and stops you from repeating yourself. Projects works well for actual projects, but it also works surprisingly well for recurring tasks that aren't really "projects" in the traditional sense.

Most people who try Projects set them up wrong. Instructions that are way too long, the wrong files, everything dumped into one project. This guide shows you how to do it right.

What a project is made of

A Claude project has three parts:

Instructions. Rules Claude follows in every conversation inside the project. Who you are, what tone you prefer, what Claude should and shouldn't do.

Knowledge base. Files you upload: documents, templates, reports, style guides. Claude has access to them in every conversation without you having to upload them again.

Memory. Claude learns over time. It picks up patterns from your conversations and remembers preferences, decisions, and context between sessions. Memory is separate for each project. General Claude memory does not carry over into a project (unlike Projects in ChatGPT). You start from scratch in a new Claude project.

All three parts share the same 200,000 token context window (roughly 500 pages of text). So the more you fill up with files and instructions, the less room there is for the actual conversation. On paid plans, Claude automatically switches on intelligent retrieval (RAG) when you get close to the limit.

Step 1: Pick the right scope for the project

The most common mistake is making one giant project for everything. If it's genuinely a project where Claude is helping as a kind of project coordinator, then yes, one project usually makes sense. But for other kinds of work, it's not always obvious.

Ask yourself three questions about the task:

1. Does it always produce the same type of output?
2. Does it always follow the same process, guidelines, or rules?
3. Do you have relevant supporting documents or knowledge files for the task?

If the answer is yes to all three, it's one project. If not, split it up.

Examples:

• Email and communication: one project. Same tone, same recipients, same context.
• Quarterly reports: one project. Same template, same KPIs, same format.
• Blog posts: one project. Same writing style, same audience, same guidelines.
• Client work: one project per client. Each client has its own context, documents, and rules.