Plain-English Explainer
How to Use Claude Projects to Organize Ongoing Work
The difference between a project and a chat is memory you don't have to re-type.
Claude Projects is the workspace inside Claude.ai for work that spans more than one conversation. This page covers what a project actually is, when it beats starting a fresh chat, how to load it with reference material, and the habits that keep a project useful instead of turning into a junk drawer.
A Claude Project is a container in Claude.ai that bundles a set of reference files, a standing instruction, and every conversation you have within it, so Claude starts each new chat already knowing the context instead of you re-explaining it. You create one from the sidebar, add files or pasted text to its project knowledge, write custom instructions once, and then every chat inside that project can reference that material automatically.
Published
Key Takeaways
- A project bundles project knowledge (files and text), custom instructions, and a shared chat history under one roof, something a regular chat has none of.
- Start a project the moment work will span more than one or two conversations: a client, a course, a codebase, a recurring report.
- Project knowledge is read at the start of every chat in that project, so Claude doesn't need the same background pasted in each time.
- Custom instructions set once in a project apply to every conversation inside it, which is where tone, format, and recurring constraints belong.
- Projects decay the same way folders do: stale files and vague instructions quietly make answers worse, so they need occasional pruning.
- A project is not a database or a search index. It works best with a modest, curated set of files rather than everything you own on a topic.
A single chat vs. a Claude Project
| Regular chat | Claude Project | |
|---|---|---|
| Memory between sessions | None. Each new chat starts cold | Project knowledge and custom instructions carry into every new chat inside it |
| Reference files | Attached per chat, forgotten once the chat ends | Attached once to project knowledge, available to all chats in the project |
| Instructions and tone | Re-stated at the top of every chat if you want consistency | Set once as custom instructions, applied automatically |
| Best for | A single question or a short, self-contained task | Work that recurs: a client, a course, a long document, a codebase you keep coming back to |
| Cleanup needed | None. The chat is disposable | Yes. Stale files and instructions should be pruned periodically |
Copy and Paste
Prompts You Can Use Today
Draft custom instructions for a new project
I'm setting up a Claude Project for ongoing freelance copywriting work with one client, a mid-size SaaS company selling project management software. Write a set of custom instructions for this project that tells you to write in their brand voice (direct, a little dry, no exclamation points), always ask who the target reader is before drafting, and flag any claim about the product that isn't backed by the reference files I've uploaded.
Replace the client description and voice notes with your own.
Summarize what's in a project's knowledge before adding more
Before I add three more files to this project, give me a short summary of what's currently in the project knowledge: what each existing file covers, where they overlap, and whether anything looks outdated or contradicted by a newer file.
Run this periodically so you know what Claude is actually drawing on.
Decide whether something needs its own project
I have a new piece of work: writing a quarterly board update for my startup, using data from three spreadsheets and a running list of decisions from the last board meeting. Tell me whether this should be its own Claude Project or just a chat inside an existing project, and explain the reasoning so I can apply it to similar decisions later.
Useful as a repeatable test for new work before you create yet another project.
Write a project knowledge file from scratch
Write a single reference document I can upload to my Claude Project for managing our product's customer support macros. Include our current refund policy, the three most common complaint categories, and a short style guide for how we want support replies to sound: warm, specific, and never defensive.
Turn your own policies and notes into one clean file instead of several scattered pastes.
Audit a project for staleness
Review the custom instructions and project knowledge in this project and tell me which parts reference information that's more than a few months old, which instructions seem to conflict with each other, and what you'd remove or rewrite if this project needed to serve someone picking it up today for the first time.
Run this every few weeks on long-running projects.
Migrate a one-off chat into a project
I've been having a long back-and-forth chat about restructuring our onboarding email sequence and it's gotten unwieldy. Help me extract the key decisions we've made so far into a short reference document I can upload to a new Claude Project, so I can continue this work there instead of in this single chat.
Good for rescuing a chat that outgrew itself before project history existed.
The Basics
What a Claude Project actually is
Three parts, all living under one project in the Claude.ai sidebar.
Project knowledge
Files and pasted text you add once. Claude treats this as background it can read at the start of any chat inside the project, so you stop re-uploading the same brief or dataset.
Custom instructions
A standing instruction for the whole project: tone, format, constraints, or a role Claude should hold ('you are reviewing these as a skeptical editor'). Written once, applied to every chat.
Project chat history
Every conversation you start inside the project lives together, separate from your general chats, so the project becomes a running record of the work rather than scattered threads.
Shared projects (paid plans)
On team and business plans, a project's knowledge and instructions can be shared with teammates, so everyone drafting against the same brief or dataset is working from the same source instead of their own copy.
Decision Point
New project or new chat? A quick test
The test is simple: will you need this same background information again in a week? If the answer is no, because you're asking a one-off question, debugging a single error message, or drafting one email, a regular chat is faster and leaves nothing to maintain. If the answer is yes, a project pays for itself the second or third time you'd otherwise re-paste the same context.
A useful signal is repetition you've already done once by hand. If you've copied the same brand guidelines into three different chats this month, that's the project knowledge for a project you haven't created yet. If you keep typing a variant of 'respond as if you're a cautious compliance reviewer' at the top of every message, that's a custom instruction waiting to be set once.
Scope matters too. A project works best around one coherent thing, one client, one course, one codebase, one recurring report, rather than 'everything I'm working on.' A project that tries to hold unrelated work ends up with project knowledge that contradicts itself, which degrades answers rather than improving them.
Setting It Up
Adding reference files well
The project knowledge panel rewards curation more than volume.
Upload the source, not your notes about the source
If you have the original contract, style guide, or dataset, upload that rather than a summary you wrote from memory. Claude can summarize for you; it can't recover detail you left out of your own notes.
One current version per document
If you upload a revised brief, remove or clearly supersede the old one. Two versions of the same document sitting in project knowledge is the single most common cause of a project giving inconsistent answers.
Prefer a few dense files over many thin ones
A single well-organized reference document is easier for Claude to use well than a dozen fragments, and easier for you to keep accurate over time.
Treat project knowledge as a place Claude reads, not writes
Projects don't update their own knowledge files as you chat. If a conversation produces a decision worth keeping, add it back to project knowledge yourself. It won't persist on its own.
Writing Them
What makes custom instructions actually work
Custom instructions are most effective when they're specific and durable, not a wishlist. 'Write professionally' tells Claude almost nothing it can act on. 'Write in short paragraphs, avoid exclamation points, and always name the specific metric a claim is based on' is something Claude can actually follow in every response.
Durable is the operative word. Put things in custom instructions that will still be true in a month, a client's brand voice, a recurring format requirement, a standing role for Claude to hold. Put things that change often, like this week's priority or today's specific question, in the chat itself, not the project-wide instructions, or you'll be editing them constantly.
It's worth revisiting custom instructions the way you'd revisit a style guide: periodically, and especially after the project's scope shifts. An instruction written for a project's first month of exploratory drafts can actively work against it once the project has settled into a production rhythm.
Staying Useful
Habits that keep a project from rotting
Schedule a periodic review
Long-running projects accumulate outdated files the same way a shared drive does. A short monthly pass, checking what's stale, what's duplicated, what no longer applies, keeps answers sharp.
Ask Claude to audit itself
You can ask Claude, inside the project, to summarize what it currently has in project knowledge and flag anything that looks outdated or contradictory. It's a fast way to catch drift before it affects a real answer.
Keep one project per boundary that matters
If two clients, two codebases, or two confidential contexts would ever need to stay separate, give them separate projects. Mixing them means every chat in that project can see everything in it.
Name the project for what it does, not when you made it
'Acme Q3 Onboarding Rewrite' survives being found again in six months. 'New Project (3)' doesn't. A clear name is a small thing that pays off every time you have to find it again.
Honest Limits
What projects don't do
A project is not a database Claude queries selectively. It's closer to background reading Claude has in front of it. That means it works best with a curated, moderate set of material rather than an attempt to dump an entire shared drive into it and hope Claude finds the relevant parts. If a project's knowledge grows large and unfocused, trimming it usually improves answers more than adding more context would.
A project also doesn't replace version control, a CMS, or a shared drive as the source of truth for a document. Treat the files in a project as working copies for Claude's reference, not the canonical, always-current version of anything. If the real document changes, you still have to update the copy in the project yourself.
And a project's shared history is a record of your conversations, not a project management tool. It won't track deadlines or assign tasks. It's a memory layer for context, which is a narrower and more useful job than trying to make it do everything at once.
Reading about Claude Projects and actually running one well are different things
Setting up a project is easy. Writing custom instructions that actually change Claude's output, and knowing when a project's knowledge has gone stale, takes practice. The free Nightschool AI curriculum is hands-on from the first lesson, so you build that instinct on real work instead of a tutorial.
Frequently Asked Questions
What is a Claude Project?
A Claude Project is a workspace in Claude.ai that bundles project knowledge (files and text you upload), custom instructions (a standing instruction for the whole project), and a shared history of every conversation started inside it. Starting a chat within a project gives Claude that background automatically, instead of you re-explaining it each time.
When should I create a new project instead of just starting a new chat?
Create a project when you'll need the same background information more than once: a client relationship, a course you're building, a codebase you return to, a recurring report. If a task is self-contained and you won't need its context again, a regular chat is simpler and leaves nothing to maintain.
What should I put in project knowledge?
Upload the actual source documents, not summaries you wrote from memory: contracts, style guides, datasets, specs. Keep it to one current version of each document, and prefer a few well-organized files over many fragments. Remove or replace outdated versions so Claude isn't reading two conflicting copies of the same thing.
Do custom instructions apply to every chat in the project?
Yes. Custom instructions are set once at the project level and apply automatically to every conversation started inside that project. They're the right place for durable things like brand voice, standing constraints, or a role Claude should hold, rather than anything that changes week to week.
Does a project update its own knowledge as I chat?
No. Decisions, conclusions, or new information that come out of a conversation stay in that conversation unless you deliberately add them back to project knowledge. Treat project knowledge as material Claude reads, not a log that writes itself.
Can I share a Claude Project with teammates?
On team and business plans, a project's knowledge and instructions can be shared so a team works from the same reference material and standing instructions rather than each person keeping their own copy. The sharing scope depends on your plan, so check your workspace settings for what's available.
How much should I upload to one project?
Less than you might think. A project works best as a curated set of current, relevant material rather than an attempt to include everything you own on a topic. A bloated, unfocused project tends to produce worse answers than a smaller, well-maintained one.
How do I keep a long-running project from getting messy?
Review it periodically: remove outdated files, resolve instructions that have started to contradict each other, and rename the project clearly if its scope has shifted. You can also ask Claude, inside the project, to summarize what's currently in its knowledge and flag anything that looks stale or duplicated.
Is a Claude Project the same as a project management tool?
No. A project doesn't track deadlines, assign tasks, or manage a workflow. It's a memory layer that keeps relevant files, instructions, and conversation history together so Claude has consistent context, not a substitute for the tools you already use to run the work itself.
Should I use one project for multiple clients or topics?
Keep separate things separate, especially if confidentiality matters. Every chat inside a project can see everything in its project knowledge, so mixing two clients or two unrelated topics into one project risks cross-contamination in both the context Claude uses and the answers it gives.
Projects are a habit, not a feature you turn on once
The skill is knowing what belongs in the background and what doesn't.