How to Actually Get Real Work Out of Claude Projects (Not Just a Prettier Chat History)

1. One Project per real thing you’re working on, not one Project for “work”

This is the first mistake, and it’s the one that dooms everything downstream.

The temptation is to create one big Project called “Consulting” or “Writing” or “Side Project” and dump everything into it. Don’t. If the work has its own set of files, its own tone, or its own deadline, it deserves its own workspace. Don’t jam your personal finances into the same project as your startup pitch deck. The entire point of Projects is to keep Claude focused on one topic at a time.

You get five Projects on the free plan and effectively unlimited on paid, so Projects are available to all users, including those with free Claude accounts, and free users can create a maximum of five projects . Spend them deliberately. My rule: one client, one book, one product launch, one recurring workflow (like the weekly newsletter) each get their own Project. General “ask Claude anything” chats stay out of Projects entirely. That’s what the main chat is for.

If you’re on a paid plan and you’re on the fence about whether something deserves its own Project, err toward yes. A redundant Project costs you nothing. Muddled context costs you every chat you start from now until you clean it up.

2. Write project instructions like rules, not like a memo

Custom instructions is where the leverage lives, and it’s where almost everyone writes the wrong kind of thing.

Writing an essay instead of rules is the common mistake. Claude responds better to short, specific directives than to long paragraphs of context. “Use TypeScript strict mode” beats a paragraph explaining why TypeScript strict mode matters to your team.

Write your instructions as a punch list. Who you are, one line. What the project is, one line. Then a bulleted set of rules: the format you want, the tone, the length, the things to always do, and (this one matters) a “Do NOT” list. Telling Claude what to avoid is often more effective than telling it what to do. “Do not suggest switching frameworks” prevents a common annoyance that positive instructions miss.

Concretely, a newsletter-drafting Project’s instructions might read: “I’m a tech analyst writing a weekly newsletter for product managers. Default to ~1,200 words. Use H2 and H3 only. Contractions on, casual register, first person. Do NOT open with ‘In today’s fast-paced world.’ Do NOT use em dashes. Do NOT hedge, commit to a take.” That’s it. Four sentences of rules will out-perform four paragraphs of vibe every time.

Also, don’t waste tokens repeating your account-wide preferences. Your profile preferences load first, then project instructions add context on top. You don’t need to repeat “be concise” or “challenge my reasoning” in every project if that’s already in your profile preferences.

3. Treat the knowledge base like a working library, not a junk drawer

This is where the compound interest is, and it’s where most Projects rot.

Every project has a knowledge base, which you’ll find right below the instructions, labeled Files, on the project’s main page. You can add PDFs, Word docs, spreadsheets, code, plain text, and more. Whatever you upload becomes available to every chat inside that project, so you can add your brand style guide, research notes, or codebase once, not at the start of every conversation. This is where Projects pulls ahead of plain chats: Claude can quote, cite, and reason over your uploaded material instead of guessing.

Two rules for keeping the library sharp:

Curate, don’t hoard. Free users don’t get RAG, so on a free account, keep the knowledge base small. Upload only what’s relevant right now. Outdated versions of your files will only confuse Claude. If a document has been superseded, replace it rather than piling the new one on top. This applies on paid plans too. RAG doesn’t save you from stale context, it just retrieves your stale context more efficiently.

Name files like you want them cited. Use clear filenames so you can find them when Claude cites them. A PDF named Q3-pricing-final.pdf is much easier to reference in a prompt than pricing_v7_REAL_final.pdf. If you want Claude to say “according to your brand guidelines,” name the file brand-guidelines.pdf. Not Untitled (3).pdf.

If you’re on Pro, Max, Team, or Enterprise, there’s one more thing worth knowing: Enhanced project knowledge with RAG is only available to users with paid Claude plans. When using a paid plan, your projects automatically scale to handle large amounts of content through Retrieval Augmented Generation. That means on paid plans you can load in a whole codebase or a book-length reference and Claude will retrieve against it instead of stuffing the whole thing in context. Use that.

4. Understand what does and doesn’t carry across chats

Here’s the single most misunderstood thing about Projects, and it’ll save you real pain.

Two chats inside the same Project do not share memory with each other. They share the setup, the instructions and the knowledge base, but they don’t share what you said in the other chat. Claude will use the project instructions for all the chats within the project. Context is not shared across chats within a project unless the information is added into the project knowledge base.

Read that twice. It’s the rule that makes Projects actually make sense.

Practical consequence: if you figure something important out in a chat, a decision, a spec, a style call, and you want future chats to know about it, put it in the knowledge base. Ask Claude to summarize the decision in a paragraph, copy it into a text file, and upload it. Now every chat from now on inherits it. If you leave it in the chat, it dies with the chat.

I keep a decisions.md file in most of my Projects for exactly this. Every time we settle something material (“we’re calling this feature X, not Y,” “the audience is founders not engineers,” “the deadline is the 15th”), I have Claude append a one-liner to the file and I re-upload it. That file is the memory Claude doesn’t otherwise have.

Also: you can define project instructions for each project to further tailor Claude’s responses. For example, instructing Claude to use a more formal tone or answer questions from the perspective of a specific role or industry. If a decision affects how Claude should behave going forward, not just what it should know, put it in the instructions, not the knowledge base. Behavior lives in instructions. Facts live in files.

5. Iterate the instructions after every few chats, the hidden multiplier

Nobody’s first set of project instructions is any good. Mine weren’t. Yours won’t be either. That’s fine, the point is to fix them.

Iterate after a few conversations. Your first set of project instructions won’t be perfect. After 3-5 conversations in the project, you’ll notice patterns: Claude keeps making the same mistake, or keeps asking for context you could have included. Update the instructions each time. This compounds fast.

The pattern to watch for: any time you find yourself correcting Claude with the same correction twice, that correction belongs in the instructions. “Stop using em dashes.” “Cite the brand guide when we’re talking about copy.” “Assume I’m on a Mac.” Each one of those, moved from chat into instructions, saves you thirty seconds a day forever. Once you save these instructions, you won’t need to repeat them. Every new chat in that project will start with the same rules. If Claude makes the same mistake twice, the solution is to update your instructions instead of correcting it every time in new chats.

Same discipline for the knowledge base. If Claude keeps asking for a piece of context, that context wants to be a file. If a file keeps being wrong, replace it. Project instructions go stale. If your stack changes, your conventions evolve, or you switch from one project phase to another, update the instructions. A five-minute review every couple of weeks keeps them current.

Put a fifteen-minute weekly hygiene appointment on your calendar for your top two or three Projects. That’s the whole habit. It compounds harder than any prompt trick you’ll ever learn.

6. Use Team/Enterprise sharing when the Project is the deliverable

If you’re on a paid team plan, this is the part most people never touch, and it’s genuinely one of the best features in the whole product.

For users on Claude for Work (Team and Enterprise) plans, projects can be shared with other members of your organization, enabling powerful collaboration and knowledge sharing capabilities. Members with “Can use” access can see project contents, knowledge, and instructions, and chat within the project, but cannot edit it. Members with “Can edit” access can modify project instructions and knowledge, add/remove members, update member settings, and actively contribute to the project.

The play: when a Project represents something the whole team benefits from (a client’s brand voice, an ongoing product line, a support playbook), build it once, share it read-only (“Can use”) to the team, and keep edit rights on the two or three people who actually maintain it. Now everyone on the team gets identical Claude behavior on that topic. No more “well, mine said…” divergence.

You can share projects with specific team members by email, add multiple users at once using email lists, or make projects available to everyone in your organization either when creating the project or afterward. Start narrow, expand once it’s clearly working.

The best Projects I’ve seen inside companies aren’t personal, they’re shared. A “House Style” Project maintained by the head of content. A “Sales Objections” Project owned by the RevOps lead. A “Codebase Conventions” Project owned by the platform team. Every rep, writer, and engineer inherits the same setup the moment they open a chat inside. That’s not a chatbot. That’s an org asset.

The habit that ties it all together

Stop thinking of a Project as a place to put chats. Start thinking of it as a system that starts every chat with your role, your rules, and your reference material already loaded. The reason your Projects feel underwhelming isn’t the model, it’s that you never actually taught the workspace anything. Give it fifteen minutes a week of real maintenance and it’ll quietly become the most valuable tool in your stack. Give it nothing and it stays a folder.