Claude Projects: What They Are and How to Set One Up
A Project is a workspace where Claude already knows your context — your documents, your house style, your rules — so every conversation inside it starts with Claude up to speed. You set it up once instead of re-pasting the same background every day.
It holds three things: knowledge (files it can always read), instructions (standing directions applied to every chat), and the conversations themselves, grouped so you can find last Tuesday's work. It is among the most useful things Anthropic ships and among the least used.
What a Project actually is
A normal Claude chat is a blank slate. Start a new conversation and it has no idea what you discussed before. A Project changes that: a workspace dedicated to one area of your work — a client, a department, a recurring task — where three things are always available.
| What it holds | Example | |
|---|---|---|
| Knowledge | Files uploaded once, readable in every conversation inside the Project | Brand guidelines, standard contracts, product documentation, last quarter’s reports |
| Instructions | Standing directions applied to every chat automatically | “Write for a B2B audience, use British English, always cite the source document, never invent a number.” |
| Conversations | Every chat inside the Project, grouped together | Finding the analysis you did last Tuesday without scrolling through hundreds of unrelated chats |
The way to picture it: a normal chat is a brilliant freelancer with amnesia who forgets everything the moment they leave. A Project is a brilliant employee who has read the onboarding pack, knows the house style, and remembers what you are working on.
The re-explaining problem it solves
The same pattern shows up in nearly every team we work with. People get good results in a one-off chat, then lose half that value because every new task starts from nothing. They paste the company description again. They re-upload the style guide. They re-explain the audience and the tone. Five minutes of typing context they have typed a hundred times.
The wasted time is the obvious cost. The inconsistency is the expensive one. When context lives in people's heads and gets pasted differently every time, output drifts. One person tells Claude the brand voice is warm and direct. Another says professional. A third forgets to mention it. Then someone concludes the tool is unreliable, when what is actually unreliable is the briefing.
A Project fixes both at once: written once, in one place, applied automatically, so everyone working inside it gets the same baseline.
Setting one up properly
- Scope it narrowly. One client, one department, one recurring deliverable. A Project called “Marketing” is too broad to give useful instructions; “Monthly client reporting” is not.
- Upload what you actually re-paste. Not everything you own — the specific documents you find yourself attaching again and again. Start with three or four.
- Write the instructions as rules, not description. This is the step people skip, and it is where most of the value is. See below.
- Use it for a fortnight, then revise. You will notice yourself correcting the same thing repeatedly. That correction belongs in the instructions.
The instructions field, done well
Most people write a sentence or two here and wonder why the Project does not feel transformative. The instructions field rewards specificity more than almost anything else in Claude. Here is a shape that works — adapt it rather than copying it literally.
Never invent a figure — if it isn't in the documents, say you don't have it. Of everything in that block, this is the instruction that most changes how much you can trust the output, and it is the one almost nobody thinks to write down.
Which Projects to create first
Do not create fifteen. Create two, use them properly, and let the third be a decision you make because the first two earned it.
The two that pay off fastest in most companies: one for your highest-volume recurring deliverable — the report, the proposal type, the client update you produce constantly — and one per major client or account, holding their contracts, history and preferences, so anyone picking up that account starts informed rather than asking a colleague.
That second one has a benefit nobody expects: it doubles as handover documentation. When someone leaves or goes on holiday, the context that used to live in their head is sitting in a Project the next person can open.
Projects vs Skills vs memory
These three get muddled constantly. The distinction is clean once you see it.
| Holds | Scope | |
|---|---|---|
| Project | What Claude should know — your documents and context | One area of work; you choose when you are in it |
| Skill | How Claude should work — your method for a task | Follows you everywhere; applies whenever the task comes up |
| Memory | What Claude has picked up about you over time | Across your conversations, accumulated rather than authored |
A Project is deliberate and scoped; memory is ambient and accumulated; a Skill is a method that travels. Most teams should start with one Project, because it is the one that requires no new habit — you just work inside it.
Building Projects that fit how a team actually works — and writing instructions specific enough to change the output — is one of the things a Deployed Kickstart half-day produces with your real documents. The Partner programme keeps them sharp as the work changes.
Frequently asked questions
What is a Claude Project?
A workspace dedicated to one area of your work where Claude already has your context. It holds three things: knowledge (files uploaded once that Claude can read in every conversation inside the Project), instructions (standing directions applied to every chat automatically), and the conversations themselves, grouped so you can find earlier work without scrolling through unrelated chats.
How do I set up a Claude Project?
Scope it narrowly to one client, department or recurring deliverable — “Marketing” is too broad to instruct usefully, “Monthly client reporting” is not. Upload the three or four documents you find yourself re-attaching. Write the instructions as rules rather than description. Then use it for a fortnight and revise: whatever you keep correcting belongs in the instructions.
What should I write in a Claude Project's instructions?
Be far more specific than feels necessary — this field rewards detail more than almost anything else in Claude. Cover who the audience is, how to write (language, tone, formatting), what good output looks like, and what to never do. The single most valuable line is usually “never invent a figure — if it isn’t in the documents, say you don’t have it,” because it is what makes the output trustworthy.
Which Claude Projects should I create first?
Two, not fifteen. One for your highest-volume recurring deliverable — the report, proposal type or client update you produce constantly — and one per major client or account, holding their contracts, history and preferences. The second has an unexpected benefit: it doubles as handover documentation, so context that used to live in one person’s head is available when they leave or go on holiday.
What is the difference between Claude Projects and Skills?
A Project holds what Claude should know — your documents and context — and applies when you are working inside it. A Skill holds how Claude should work, your method for a specific task, and follows you everywhere the task comes up. Memory is a third thing: what Claude has picked up about you over time, accumulated rather than authored.
Why do teams get inconsistent results without Projects?
Because context lives in people’s heads and gets pasted differently every time. One person says the brand voice is warm and direct, another says professional, a third forgets to mention it — so the output drifts, and someone eventually concludes the tool is unreliable when what is actually unreliable is the briefing. A Project fixes that by writing the context down once, in one place, applied automatically.
Found this useful? Send it to someone who needs it.