Projects
Upload your reference material once, set a system prompt, and every chat inside the Project already knows the context. The single biggest unlock for anyone doing the same kind of work more than twice.
If you have read the Intermediate guide, you already know the basics. This page goes deeper: how to set up a Project properly, what makes a system prompt good, how to curate your reference docs, when to use a Project and when not to, and the patterns that separate a useful Project from one that gathers dust.
What a Project actually is
A Project is a workspace inside Claude. It has a name, a system prompt (a standing instruction that shapes how Claude behaves in every chat), and a set of uploaded reference documents. Every new conversation you start inside the Project can see all of those documents and follows the system prompt automatically.
The practical effect: instead of pasting the same context into every chat, you paste it once. Instead of re-explaining your conventions every time, you explain them once in the system prompt. Every chat starts at full context and full voice, as if you had already briefed a new colleague on everything they need to know.
Upload context once, every chat inside the Project already knows.
How to set one up
Five steps. Under five minutes for the first one.
Create the Project. In the left sidebar of claude.ai, click "Projects" then "New Project". Give it a specific name that describes the job, not a vague category. "Monthly client reports" beats "work stuff".
Set the system prompt. Click the pencil icon at the top of the Project. Write one to three sentences that tell Claude how to behave in every conversation. Voice, audience, constraints, format preferences. This is the standing instruction that shapes every response.
Upload reference docs. Drag in the files Claude should know about. Templates, previous outputs you were happy with, style guides, data schemas, anything you keep having to explain. Quality over quantity: five curated files beat thirty random ones.
Start a conversation inside the Project. Click "New chat" while you are inside the Project. This chat automatically sees all your docs and follows your system prompt. You do not need to paste or remind.
Iterate the system prompt. After a few chats, you will know what the system prompt is missing. Edit it. Add the instruction you keep having to repeat. The second version of your system prompt is always better than the first.
What makes a system prompt good
A system prompt is the standing instruction at the top of every chat in the Project. Most people either leave it blank ("You are a helpful assistant") or write a paragraph that is too long to be useful. Neither works. Here is the difference.
Generic vs curated system prompt
Every chat in this Project behaves like a fresh Claude with no context. The uploaded docs are technically available but Claude has no instruction to prioritise them. Outputs are generic, voice is inconsistent, and you end up re-explaining your preferences in every chat anyway.
Every chat starts knowing the voice, the audience, the constraints, and the format. The first draft is already 80% of the way there. You spend your time on content judgement, not on re-briefing.
A good system prompt is three to five lines, specific to the job, and written as if you were briefing a colleague who will be doing this work for you every week.
Three system prompts to steal
Copy any of these, adapt them to your work, paste them into a new Project.
For a report-writing Project
For a code-review Project
For a customer-support Project
Curating your reference docs
A Project with thirty mediocre documents is worse than one with five great ones. Claude reads everything in the Project on every turn, which means irrelevant context dilutes the useful signal. Every document should earn its place.
- Include: templates, example outputs you were happy with, style guides, data schemas, glossaries, anything you would hand to a new team member on their first day.
- Exclude: stale versions of documents you have already replaced, large reference files you only need occasionally (paste those per-chat instead), anything over 50 pages that Claude will read in full every turn.
- Version clearly: name files with a date or version number. If you update a doc, re-upload the new version and delete the old one. Stale docs in a Project are the equivalent of an out-of-date README: they make everything worse.
- Test by asking. After uploading, start a chat and ask Claude a question that only someone who had read the docs could answer. If it cannot answer well, the docs are either missing the information or the system prompt is not pointing Claude at them.
When to use a Project vs a plain chat
| Use a Project when... | Use a plain chat when... |
|---|---|
| You have pasted the same context into two or more chats | The task is a one-off you will never repeat |
| You want Claude to match a specific voice or template | You do not care about voice consistency |
| You have reference docs that every conversation should know | The context fits in a single paste |
| Multiple team members should have the same setup | Only you will ever use this |
| The task recurs (weekly reports, monthly reviews, ongoing code reviews) | The task is exploratory and you are still figuring out what you want |
Team sharing
On Team and Enterprise plans, Projects can be shared with other members of your organisation. Everyone who has access starts with the same system prompt, the same reference docs, and the same context. New starters can be added to the Project and be productive immediately, rather than building up context from scratch.
One constraint worth knowing: conversations within shared Projects are still private to each user. Sharing a Project shares the setup, not the chat history. This is deliberate: it means people can have frank conversations with Claude inside a shared Project without worrying about visibility.
Four patterns worth stealing
One Project per initiative, not per task
"Cable X monitoring" beats ten one-off chats. The system prompt sets the voice, the references stay fresh, and every chat starts with the full context already loaded. If a Project is so broad it needs different voices or different docs for different kinds of task, it is probably two Projects.
System prompts are where style guides go
"Respond in UK English, use sentence case headings, lead with the headline, flag uncertainty explicitly" once, at the top, and every chat in the Project inherits it. You will never type those instructions again.
Start small, expand as gaps appear
Upload three files, set a two-line system prompt, have one real conversation. Notice what Claude did not know. Add that to the docs or the system prompt. Repeat. The fifth version of your Project is always dramatically better than the first, and you get there fast by iterating rather than planning.
Review the system prompt after every ten chats
Whatever instruction you find yourself repeating in individual chats, that instruction belongs in the system prompt. If you said "keep it under 200 words" in three separate conversations, add it to the system prompt and never type it again.
Projects are the single highest-leverage tool in this section for most people. If you take nothing else from the Tools pages, set up one Project for the task you do most often and use it for a week.
Next: Artifacts covers the side-panel canvas where Claude builds interactive things. Or go back to the Tools hub to pick a different path.