What this covers
Most people use Claude Projects as a glorified file folder, then wonder why answers drift when they open a new chat. This guide walks through how Projects actually share state, what belongs in Knowledge vs Instructions, and a setup pattern that survives months of recurring work without becoming a graveyard of stale drafts.
Who this is for
Anyone who keeps re-pasting the same context into Claude. If you run a book project, a long research thread, a recurring client engagement, or any codebase where you keep saying “here is the spec again,” Projects pay off the first week. One-off questioners can skip the setup overhead.
When to reach for it
Reach for a Project the second time you open a new chat and re-explain the same background. Long-running work — a book project, a codebase, a research thread — is the sweet spot. For a book or article series specifically, pair Projects with a real Claude writing workflow so each chat starts from a fixed voice and outline rather than a blank slate.
Three concrete examples where Projects beat plain chats:
- A novel with a 12-character cast: load
characters.md,worldbuilding.md, and the latest outline once; every chapter draft inherits voice rules. - A consulting engagement: brand guidelines, last month’s deliverables, and a running
decisions.mdgive every email and deck the same tone. - A side codebase: README, architecture notes, and a
coding-conventions.mdkeep code-review chats consistent across weeks.
Before you start
- Define the exact outcome you want: a draft, a fix, a summary, a comparison. “Help me think” is not a Project goal.
- Collect 3-7 grounding files. More than ten dilutes retrieval; fewer than three leaves Claude guessing.
- Decide what stays out: outdated drafts, exploratory notes, anything you would not want quoted back at you mid-chat.
- Run the workflow on one chapter, one section, or one ticket before scaling up.
Step by step
- Create a Project with a name that describes the outcome (“Q3 launch plan”), not the topic (“marketing”). Outcome names force you to define done.
- Add Project Knowledge: docs, transcripts, references. Treat each file like a citation — if you would not link to it in the final deliverable, it does not belong here.
- Set Custom Instructions for the Project: role (“you are my book editor”), audience, voice (“plain English, no marketing copy”), constraints (“never invent statistics; ask for sources”), and one or two success markers.
- Open a chat inside the Project. Lead with the sub-goal in the first message: “Today: outline chapter 4 using the existing voice from
chapter-3.md.” Combine Projects with a deep Claude Artifacts workflow when your recurring output is a single iterable document or small app. - When a chat reaches a decision (a thesis, a chosen direction, a kill-list), summarize it in a paragraph and append to a
decisions.mdfile. Re-upload the file so future chats can read it.
First-run exercise
- Pick one low-stakes deliverable: a single blog post, one section of a report, one bug fix.
- Run the Project once end-to-end without changing the prompt, files, or model halfway through.
- Save the first output and mark each paragraph as “ship as-is,” “needs editing,” or “wrong.” A 60/30/10 split is normal on a first try.
- Change exactly one variable for the second run — usually the Instructions, not the files. Re-running with new Instructions but the same Knowledge tells you whether the system prompt or the source material is the bottleneck.
Quality check
- Did the output solve the original outcome named in the Project title? Length and polish are not the test.
- Verify any facts, links, page numbers, file paths, or commands independently. Claude will paraphrase your uploaded files confidently even when it loses precision.
- Flag the human-judgment risks: client confidentiality, copyright on uploaded books, cost of a wrong direction.
How to reuse this workflow
- Save the Custom Instructions text as a snippet so you can clone a Project structure in 60 seconds.
- Build a “starter file set” template for each Project type: writing Projects always include
voice.mdandoutline.md; coding Projects always includeREADME.mdandconventions.md. - Keep a
lessons.mdfile in each Project where you log every time Claude misread a file, drifted in tone, or made up a fact. Patterns appear after the third or fourth entry. - Re-run a small sample monthly — Claude model versions, file limits, and Project UI all shift.
Recommended workflow
Spin up Project → load 3-7 grounding files → write Instructions in under 1000 words → open the first chat with a sub-goal → copy decisions back into decisions.md → prune Knowledge every two weeks.
Common mistakes
- Loading 30 files because storage is cheap — retrieval gets noisier as the file set grows.
- Naming the Project after a topic (“client X”) instead of an outcome (“client X Q3 deliverables”). Topic names invite scope creep.
- Skipping Project Instructions entirely. Without them, every chat starts from Anthropic’s defaults instead of your context.
- Treating Knowledge files as live documents. They are snapshots. Editing locally without re-uploading silently desyncs your chats.
- Mixing personal experiments with billable client work in the same Project. Voice and tone drift, and so does your trust in the output.
- Never pruning. After two months a healthy Project has 30% less Knowledge than when it started.
FAQ
- Do Projects share chat history?: No. Projects share Knowledge files and Instructions, not chats. If a decision needs to carry over, write it into a file.
- What is the practical Knowledge limit?: Generous but not infinite. Past roughly 100k tokens of files, retrieval gets sloppier and replies slow down. Stay lean.
- Can I share a Project with my team?: On Team and Enterprise plans, yes. Personal plans keep Projects private.
- Should I keep one mega-Project or many?: Many, scoped by outcome. One Project per deliverable is easier to prune than one Project for “all my work.”