Projects — where a client's brand context lives

This is the payoff for Form BV-01. Module 3 has you fill in a brand voice and guardrails intake per client; this is what you do with the completed thing so it stops being a document you remember to open.

The intake form puts it plainly, and the mechanism below is exactly what that sentence is describing:

Explain-on-first-use: a Project is a self-contained workspace with its own chat history and its own knowledge base — a set of files that every chat inside that project can see. You make one per client. The brand's rules live in the knowledge base; the chats come and go.

1Verified behaviour, before we build a workflow on it

Checked against support.claude.com on 2026-08-14. Four facts, three of which change how you should work.

1. Project knowledge applies automatically to every chat in that project. Upload documents, text or files to the knowledge base and Claude uses them as context in chats within that project. No per-chat setup. This is the mechanism the intake form is describing, and it works as described.

2. Project instructions apply to all chats in the project. Separate from the knowledge base — behavioural guidance rather than reference material.

3. Context is not shared across chats within a project unless it is in the knowledge base. Quoting the documentation directly:

This is the single most important line on this page and it is the one people get wrong. The knowledge base is the shared part; the conversations are not.

One qualification, added 2026-08-14 after verifying the memory feature. Claude has an opt-in memory that builds a synthesis across your chats, and each project has its own separate memory space. So with memory switched on, something said in one project chat may surface in another.

That does not rescue the trap below, and the reason is worth being exact about:

So: leave memory on if you like. Change nothing about the habit below.

4. The project's name and description are not visible to Claude. "Claude will not have access to these details." Anything you write in the description as context is decorative. Put it in the knowledge base or it does not exist.

2The trap that follows from fact 3

Here is how a good week goes wrong.

You are in a chat with a client's project loaded. Halfway through, the client emails: "we've stopped saying 'artisan', drop it." You tell Claude. It adapts, correctly, for the rest of that conversation. The scripts come out right. You ship them.

Next Tuesday you open a new chat in the same project and write three more scripts. Every one of them says "artisan."

Nothing malfunctioned. The rule lived in a conversation. The knowledge base never changed, so as far as the next chat is reliably concerned, the rule was never made — and if memory happened to catch it, you had no way of knowing in advance whether it would, which is the same problem wearing a hopeful expression.

This is the same discipline as skills/README.md's fill the gap, never delete the constraint, pointed the other way: a guardrail that only exists in a chat is a guardrail that expires when you close the tab.

3One project per client

Yes, this is how it works, and yes, it is what you should do. You can create multiple projects for different purposes, including separate clients.

How many you get

Five active clients is a real working capacity, not a trial. Most people reading this do not have five clients yet, and those who do are rarely running all five in the same week. The free tier covers the entire workflow this module teaches: one project per client, intake in the knowledge base, project instructions set, the skills reading from it.

When you pass five active clients, upgrade. That is the answer and it is a clean one — a sixth paying client covers a subscription several times over, and by then you know exactly what you are buying.

What not to do in the meantime: don't merge two clients into one project. One brand's off-limits list applied to another brand's script is the specific failure this whole system exists to prevent, and it happens quietly rather than loudly.

If you genuinely need to free a slot before upgrading, archive a dormant client, never an active one — and re-create it from the intake file when they come back, which takes about ten minutes, because the intake is the project.

4What goes in a client project

Project instructions are not the intake. The intake is reference material — facts about the brand. Instructions are behavioural. Something like:

Every script in this project is for [CLIENT]. Read intake.md before writing
anything. Never write a claim that isn't in experience.md. If the intake is
silent on something, say so and ask — do not infer the brand's position.
Run claim-guard before presenting any draft as finished.

Short, behavioural, and it repeats the two refusals the skills already enforce, so the standard holds even in a chat where you forgot to invoke them.

5Where the files should physically live

Per 07-connectors-and-plugins.md: if your intake and experience files sit in a connected drive, you have one copy that both the project and the skills read. Otherwise you now maintain two, and the second one is always the stale one.

Uploading a file to project knowledge takes a copy. Editing the original in your drive does not update the copy in the knowledge base. Re-upload after every material change to BV-01. This is the mechanical reason the trap above bites.

6The scale point

Paid plans get RAG mode automatically when project knowledge approaches the context limit — documented as expanding capacity by up to 10x while maintaining response quality.

Explain-on-first-use: RAG (retrieval-augmented generation) means that instead of holding every file at once, the relevant parts get pulled in as needed. You do not configure it and you will not notice it.

What it means practically: you are unlikely to outgrow a client project. A year of scripts, briefs and approved wording is not a problem. This removes the main reason people are tempted to prune knowledge bases, and pruning is how you lose the approved claim wording from eight months ago that you now need.

7Setup, once per client — about ten minutes

1. claude.ai/projects → + New Project. Name it for the client.
2. Upload intake.md to the knowledge base. If BV-01 isn't finished, upload it anyway — a part-filled intake is still information, and mock 4 says as much: a part-filled form is still worth filing, the gaps are information too.
3. Upload experience.md. If it doesn't exist, this is the moment you find out, and it is a much better moment than the one where script-from-intake refuses mid-deadline.
4. Set project instructions — the block above, with the client's name in it.
5. Test it. New chat, in the project: "What may I not say for this client, and what am I contractually required to include?" If the answer is wrong or thin, your intake is thin — fix the file, not the question.
6. Re-upload BV-01 whenever it changes. Put it on the same trigger as updating the form itself.

8When not to use a project

• One-off work for someone who will never come back. A project is a filing system. A single script does not need one.
• Anything with a client's genuinely sensitive material in it, until you have read your agreement with them about where their material may be stored. Uploading a client's unreleased product information anywhere is a decision, and it should be one you made rather than one you drifted into.
• As a substitute for the intake. A project with no BV-01 in it is a folder. The value was never the workspace; it is the completed form sitting inside it.