Claude Projects: Persistent Workspaces for Real Work

You've had this conversation before. Not the topic — the setup. You open a new chat, paste in the same background you pasted in three days ago, restate the same formatting preferences you've stated a dozen times, and only then get to the actual question. By the time you're five chats deep into the same recurring piece of work, you've spent more tokens re-establishing context than you have on the work itself.

A Claude Project exists to kill that tax. It's the single highest-leverage habit in this track, and it's also the one most power users under-use — not because it's hard, but because "just open a new chat" is the path of least resistance right up until it isn't.

A Project Is a Container, Not a Conversation

The mental model that trips people up is treating a Project like a folder of chats. It's closer to a standing workspace: a container that holds knowledge and instructions above the level of any single conversation, plus the threads and artifacts you generate while working inside it.

Two of those four layers — custom instructions and Project knowledge — persist across every chat you open inside the Project, forever, until you edit them. The other two — individual conversation threads and the artifacts they produce — are scoped lower. A thread starts fresh each time, the way any new chat does. But it starts fresh with the Project's context already loaded, which is the whole point.

This is the layer most people miss the first time they try Projects: they upload one document, ask one question, and conclude "this isn't that different from just attaching a file to a chat." It isn't, for one question. It becomes different on question fifty, three weeks later, when you still haven't had to re-explain what the document says or what tone you want.

When a Project Earns Its Setup Cost

Setting up a Project — naming it, uploading knowledge, writing custom instructions — takes a few real minutes. That cost is trivial if you'll use it fifty times and wasted if you'll use it once. The decision isn't complicated once you frame it around one question: will I need this exact context again?

Notice the pattern across every row that resolves to "project": it's always about recurrence or shared context, never about complexity. A genuinely hard one-off question doesn't need a Project — it needs a good prompt. A trivially simple question you'll ask every single day does need one, because the cost isn't the question, it's the setup you'd otherwise repeat.

The inverse mistake is just as common: building a Project for something you'll actually use once, out of a vague sense that "this seems important enough to deserve one." A Project you set up and never return to isn't organized — it's just knowledge you uploaded and then forgot to use, sitting there doing nothing.

Building Your First Project

The mechanics are simple on purpose. You name the Project, write a short set of custom instructions, and optionally upload the first pieces of knowledge it should have on hand. What matters is what goes into those first two steps, because they're the ones that persist.

Naming it around the job, not the topic. "Marketing stuff" is a topic. "Drafting monthly newsletter copy from raw campaign notes" is a job. The second version tells you — and tells Claude, when the name shows up as context — exactly what this Project is for, which keeps you from slowly dumping unrelated work into it over time.

Writing instructions that are checkable, not aspirational. The same standard that applies to any standing configuration applies here: could Claude act on the instruction without asking you a follow-up question? "Keep the tone professional" fails that test — professional compared to what? "Use full sentences, no emoji, sign off with my first name only" passes it. Concrete beats aspirational every time you're writing something that has to work without you in the room to clarify it.

Uploading what a new collaborator would need on day one. Not everything you own — just the reference material someone joining this work cold would actually read first. A style guide, a glossary of terms specific to this work, the last few examples of the output you're aiming for. (We go deep on exactly what belongs in Project knowledge — and what doesn't — in the next lesson.)

The Mistake That Undoes All of This

The most common way Projects go stale is scope creep. You build one for "client work," and it's fine for the first client. Then a second client shows up, and rather than starting a second Project, you add their notes to the same one because it's already set up. Six months later, your custom instructions have accumulated caveats for three different clients, contradicting each other depending on which one you're currently working on, and Claude is guessing which set of rules applies.

The fix isn't complicated — it's the discipline of noticing the signal when it happens, not six months later. If you catch yourself writing "unless it's for Client B, in which case..." inside a Project's custom instructions, that's not a footnote. That's a second Project asking to be born. We'll build the actual decision framework for exactly this in the next lesson, because "when do I split" is a real enough question that it deserves more than a rule of thumb.

For now, the habit to build is smaller: before you open your next recurring chat — the one you know you'll be having again next week — stop and ask whether it should be a Project instead. That single pause, repeated enough times, is most of what separates a power user's setup from everyone else's blank-chat-every-time default.