Claude Projects: set up a workspace you can return to
Neaptide · September 27, 2026 · 15 min read · Updated: October 3, 2026
Set up Claude Projects with useful files, clear instructions and verifiable answers. Six diagrams, ready-to-use prompts and a downloadable exercise kit.
On this page
Yesterday you told Claude who the website is for and which decisions are settled. Today you open a new chat and explain it all again. Projects give that kind of recurring work one place for its materials and instructions. The first thing to decide is what stays common across tasks and what belongs only to today's conversation.
We will build a project for a fictional pottery studio that needs a class page, an FAQ and replies to customers. You get three small source files, a project instruction and a few questions with known answers. The same approach works for editorial work, launching a service, studying or running a client project.
Quick answer: create a project around one lasting goal, upload current source material, define how to use it and open a chat for the first deliverable. Keep important decisions in a checked document, so you can verify them whatever the model happens to remember.
First, which version of Projects are you using?
As of October 3, 2026, ordinary Claude projects bring together chats, a knowledge base and instructions. Free accounts can create up to five projects. Anthropic is also gradually rolling out a new Projects beta in Claude Code to some Pro and Max users. In that version Claude coordinates separate threads itself.
The main walkthrough covers chat projects at claude.ai/projects. If you see a coordinating conversation, threads and an Overview panel in the Code tab, read the beta section near the end as well. Which version you have changes both the workflow and the settings available.
When a project earns its place
Use a project when one goal produces several related tasks. The studio needs a class description, answers to questions and a message to participants. Duration, group size and booking details are the same in all three. Only the question and the output format change.
| Your situation | Start with | Reason |
|---|---|---|
| Shorten one email | A chat | The whole task fits in one request |
| Regularly create material about one service | A project | Facts and rules recur across conversations |
| Work for two clients with different terms | Two projects | Materials and agreements are easier to keep separate |
| Upload everything about a company without a clear task | Choose a working question first | The answer will tell you which documents matter |
This is how we would choose; the product does not restrict you. Name the project after its outcome: “Launch group classes” is easier to find than “AI work.” If a project is hard to name, it probably holds several unrelated goals.
Separate files, instructions, memory and the current chat
Project files hold the source information and project instructions set the rules for answers. The current chat holds one request and the discussion around it. Claude also has memory and past-chat search, which are separate mechanisms. They carry context forward, but they do not merge every conversation into one shared document.
According to the memory documentation, each project has its own memory space. Past-chat search is a paid-plan feature, and inside a project it is limited to that project's conversations. Both are managed under Settings → Memory. The older line that context does not carry between chats should not be read as saying Claude cannot refer to earlier work at all.
For exact terms, nominate one document that holds current decisions. Here, group size comes from 02-decisions.txt, and discussion of alternatives lives elsewhere. That priority is our working rule and has to be written into the instructions. The product does not establish it for you.
Create a project and upload three useful files
Open Projects, choose + New Project, then enter a name and description. The help page makes a point that is easy to miss: Claude does not get those two fields as context. So repeat the goal in the instructions or in a brief. Add your documents to project knowledge, then open Set project instructions and save the rules.
Start with a small set you can verify yourself. Our studio's looks like this:
The brief describes the audience and the deliverables. The decisions file sets a six-person maximum, a 90-minute class and booking through a form. No price has been set. The notes keep preliminary ideas, including the earlier group of eight.
Do not strip every trace of discussion from the material just to make the answer easy. Sometimes the reason for a change matters. Dates, proposal/approved labels and a note saying which document holds current terms all help. In real work, check who approved a decision. A model writing the word “approved” does not mean a person agreed.
A chat attachment and a project knowledge file are uploaded to different places. Material you want in every conversation goes in the project's files. The current limit for a project file is 30 MB. Non-PDF documents are read as text only, so an image embedded in a DOCX will not be read. PDFs of up to 100 pages get both text and visual analysis; PDFs of 101–1000 pages are processed as text only.
If a key condition appears only in a diagram or a scan, ask about that specific page and compare the answer with the original. A successful upload tells you the file arrived. It does not tell you every important detail was extracted.
Write an instruction you can evaluate
“Be a brilliant marketer” says little about what an acceptable answer looks like. A goal, a source priority, a rule for conflicts and a rule for missing information are easier to check. You can then name the failure: an invented price, an outdated proposal, a missing source.
Use this instruction for the exercise. Replace the goal, filenames and output requirements for your own project.
Help prepare the launch material for group pottery classes:
a class page, an FAQ and customer replies.
The audience is adults with no pottery experience.
Use 01-brief.txt, 02-decisions.txt and 03-notes.txt.
Current approved terms are in 02-decisions.txt.
Do not treat early ideas in 03-notes.txt as current conditions.
If documents conflict, show both statements and explain your choice.
If their status is unclear, ask a question.
Do not invent prices, schedules, guarantees or refund conditions.
If information is missing, state what is needed.
In working notes, cite the file and section for each condition.
Separate customer-facing copy from editorial notes.
Write clearly and calmly, without unsupported promises.Project instructions apply to every chat in the project. A one-off request such as “reduce this to three paragraphs” belongs in the current conversation. Made permanent by accident, it will get in the way of other tasks.
First request: check the foundations before drafting
Start with a short review of the sources. It shows whether you and Claude understand the task the same way, and it surfaces questions before you get copy that is convincing but wrong.
Read the three project files. Do not draft the website copy yet.
Create a table: condition → current status → file and section.
List conflicts and missing information needed to publish the class page.
Do not present proposals as decisions.Open the sources named in the response. For this kit there are three test questions. Put them to Claude first, then expand the expected answers below.
How many people can attend a class?
The answer should cite Approved conditions in 02-decisions.txt: at most six participants. Eight people appears in 03-notes.txt as an early proposal, not the current limit.
Why do the files mention both six and eight?
The September 24 notes proposed eight participants. The September 26 decision set the maximum at six. A useful answer identifies both sources and their status; it should not average the numbers.
How much is a Saturday class?
Neither the price nor a weekend schedule is approved in the kit. The expected answer identifies both gaps and asks for details. It must not assume Saturday classes exist or replace an unknown price with a market estimate.
These are the answers we expect from the exercise documents. They are not results of a Claude test. They give you a check you can repeat. If an answer is wrong, look first at the source, its status and the instruction the model relied on.
Once the basis is sound, open separate “Class page” and “FAQ” chats and give each its own output. For example:
Draft an FAQ for the class page using approved project material.
Give five questions with short answers for a beginner.
Check factual claims against 02-decisions.txt.
Move questions without enough information into a separate
“Needs clarification” list. Do not invent answers for the FAQ.
After the copy, give the editor a list of sources used.The chats now line up with deliverables you review separately. Not every small question needs a new conversation, though. While you are refining the same output, stay in its chat.
What changes when the document collection grows?
On paid plans, Claude automatically enables RAG when project knowledge approaches the context limit. It then searches the documents for relevant passages and answers from those. In practice, “review the whole collection” needs a different completeness check from a targeted factual question.
Make the request specific: “Find the booking terms in 02-decisions.txt and compare them with the early notes.” For a complete review, first ask which materials were examined, then work through the documents in groups. Compare that list with the actual collection too. It records what the model looked at and guarantees nothing about completeness.
Clear names, dates and status labels help in larger collections. 2026-09-26_booking-approved.txt is easier to tell from a draft than final-final-2.txt. A better name does not fix outdated content, though. Mark superseded terms or take them out of the current set.
A company-wide answer system also needs rules for access and for updating sources. See the broader
Pick up the work a week later
After a useful session, ask for a short handover: what is accepted, what is still a draft, which questions are open and where the latest checked result lives. Read the summary yourself, and only then update the shared project document.
Prepare a handover for a new chat:
1. Confirmed decisions with sources.
2. Outputs produced and their status: draft or accepted.
3. Open questions.
4. The next specific action.
Do not promote a proposal to a decision without confirmation.Suppose the price is agreed next week. Add it to the current file with its date and basis, update project knowledge, then ask about the price in a new chat. If the reply uses old information, ask for the source and look for an outdated duplicate. Telling Claude to “remember this forever” does not replace maintaining the source.
The same principle helps with notes and meeting records: trace a conclusion back to a particular entry. See
When a team uses the project
Ordinary projects can be shared on Team and Enterprise plans. Can view lets a member read project material and chat within the project; Can edit also lets them change knowledge and instructions. Organisation settings can affect availability.
Agree who maintains current terms. If an editor and a manager upload two different prices, a shared space will not reconcile them. Give the decisions file an owner and date every change. Others can propose updates in conversation, and the owner confirms them in the shared document.
| Symptom | First check |
|---|---|
| A new chat ignores a file | Was it added to project knowledge or only to one conversation? |
| Claude repeats an old condition confidently | Which source was used, and is an outdated duplicate still present? |
| The tone is right but the price is invented | Is there a missing-information rule and a source check? |
| A diagram label cannot be read | The document format and whether visual content was extracted |
| Team members get different answers | Whether materials, instructions and available settings match |
The new beta: Claude coordinates the threads
In the new Projects beta in Claude Code, you work in one central conversation and Claude assigns tasks to threads. The threads share the project's context, and the files they produce collect in Library. You no longer open and manage separate chats yourself.
Cloud threads keep working after you close your laptop. They draw on your plan's shared limits, and parallel work uses those up faster. The beta is rolling out gradually on Pro and Max, is not yet available on Team or Enterprise, and its projects cannot be shared with another user. None of this applies to ordinary Team and Enterprise projects.
You can practise the kit's basic workflow in an ordinary project. Look into the beta, if your account has it, when you need to hand off related tasks in parallel. Before that, get the source material and the acceptance check working for one deliverable.
Your first session
- Choose one goal that will last beyond a single conversation.
- Gather a small material set and mark current decisions.
- Write rules for sources, conflicts and missing information.
- Test a known fact and a question the files cannot answer.
- Produce one useful result, check it and save the state for later.
A good first result means you can open a new chat, start the next task and see which facts the answer rests on. Start with the exercise kit, then replace it with your own material. Add the methods in our