What you’ll know by the end of this check

When a project is the right container versus just a chat
How to set up a project that actually helps Claude — instructions, knowledge base, naming
What RAG mode means and why it’s the answer to “how much can I upload?”

The real problem projects solve

Without projects, you’re re-explaining yourself every single conversation. Claude doesn’t know what team you’re on, what your writing style is, what the background is on the work you’re doing. You spend the first five messages getting it up to speed.

Projects fix this. A project is a workspace with its own persistent memory: instructions Claude follows in every chat, a knowledge base of documents it can reference, and a shared context for your whole team if you need it.

When to create a project instead of starting a new chat:

You’ll have multiple conversations about the same work stream
You have documents you’d otherwise upload again and again
You want Claude to always respond in a particular way (tone, format, structure)
You’re sharing the work with teammates who need the same starting point

Three things to get right when setting up a project

1. Instructions that actually constrain behavior

Project instructions aren’t a description of the project — they’re directions for how Claude should behave. Think of them as a standing prompt that runs before every conversation.

Concrete things to specify: What’s the context? What should Claude always do (cite sources, use a template, check for X)? What should it never do? What tone?

Vague instructions produce inconsistent results. “Always include an executive summary” is useful. “Be professional” is not.

2. A knowledge base that earns its weight

Upload documents Claude will actually need: brand guidelines, templates you want it to follow, reference reports, meeting notes, specs. Don’t upload everything — start focused and add as you learn what gaps come up.

Name your files descriptively. Claude uses filenames to find relevant content. Q4-2025-Sales-Report.pdf is more useful to Claude than report.pdf.

3. The right permission structure

On Team and Enterprise plans, projects have three permission levels:

Owner — full control, sets access
Can edit — modify instructions, update knowledge, add members
Can view — read-only plus the ability to chat

For org rollouts: team leads are owners, active collaborators are editors, cross-functional consumers are viewers.

The RAG scaling thing (and why it matters)

There’s a practical ceiling on how much context Claude can hold in memory at once — the context window. Projects handle this automatically: when your knowledge base gets large, Claude switches to RAG mode, which means it retrieves the most relevant chunks of your documents rather than loading everything at once.

The net effect: you can upload 10x more than would otherwise fit, and the experience feels the same. You’ll see a small indicator when RAG is active. You don’t need to do anything differently.

This is the answer to “how do we give Claude our team’s docs” — not just a folder dump, but a properly structured project where Claude can find what it needs.

Things to try right now (5 minutes)

Create a project for the work stream you spend the most time on right now. Write a 3-sentence instruction block: one sentence of context, one sentence of style/tone, one standing rule you want Claude to follow. Drop in 2-3 docs you’d otherwise upload repeatedly. Start a chat inside the project. Notice what you don’t have to explain.

The canonical version

Full official lesson at anthropic.skilljar.com/claude-101/383393 — includes step-by-step setup guide, example projects, and the full RAG explainer.

Ready to verify this check?

Finish the official lesson, then come back and mark this check verified on your flight log.