AI Tools Academy
Claude 0/20

Phase 3 · Claude · Level 2 · Practitioner

Projects: give Claude a workspace that remembers

Walkthrough · 12 minLast checked against the live product: 13 July 2026

By the end, you'll be able to…

  • Create a Project and add reference files as project knowledge Claude can draw on in every chat
  • Write project instructions that shape the tone and rules for a whole strand of work
  • Decide when a Project is worth setting up versus a one-off chat

Why it matters

Most people use Claude as a series of disposable chats, re-pasting the same background every single time. Projects fix that. They give one strand of work a permanent home: its own reference files, standing instructions and chat history, so Claude starts each conversation already knowing the context. This lesson builds a real Fernway onboarding Project you could reuse for weeks.

What a Project actually is

A project is a workspace inside Claude that keeps one strand of work together: a set of reference files, a set of standing instructions, and its own list of chats. Everything you do inside a Project draws on that shared background automatically, so you stop re-explaining yourself at the top of every conversation.

Think of the difference between a fresh notepad and a well-stocked desk. An ordinary chat is a fresh notepad. Claude knows only what you type in that one conversation, and when you start a new chat it knows nothing again. A Project is the desk: the policy, the brief and the house style are already sitting there, and every chat you open reaches for them without being asked.

Projects have three parts worth naming precisely, because they do different jobs:

  • Project knowledge: the reference files and text you add to the Project. Documents, notes, a spreadsheet, a policy. Claude can draw on these in any chat inside the Project.
  • Project instructions: standing guidance that shapes how Claude responds throughout the Project. Tone, audience, and the rules it should always or never follow.
  • The Project's chats: a conversation history that lives inside the Project, separate from your general chats, so a month of related work stays in one tidy place.

Projects are available on every plan, including the free one, though free accounts are capped at a small number of Projects at a time, and paid plans expand how much reference material a Project can hold. Treat the exact figures as the kind of thing that shifts; the official Projects help article has today's numbers.

Building the Fernway onboarding Project

Let's build something real: a Project to run Fernway's new-starter onboarding, a task that spreads over weeks and keeps needing the same background. Maya Roberts, the Office Manager, is coordinating it.

Step one: create it. In the left-hand sidebar, find Projects and choose to create a new one. Give it a clear name ("New-starter onboarding, Aug 2026") and a one-line description. You now have an empty workspace.

Step two: add the knowledge. Open the Project's knowledge area and add the reference material every onboarding chat will need: the onboarding checklist, the remote-working policy, the org chart so Claude knows who reports to whom. These files now sit in the Project. You will never paste them into a chat again.

Step three: write the instructions. This is the part people skip, and it is where most of the value is. The project instructions tell Claude how to behave across every chat here.

Project instructions for the onboarding ProjectClaude
You are helping Maya, Fernway's Office Manager, run new-starter onboarding. Audience: busy managers and new joiners, non-technical. Always write in plain UK English, warm but efficient. When you rely on a fact, name which uploaded file it came from. Use the org chart for who-does-what. If something isn't covered in the project files, say so plainly rather than inventing a Fernway detail. Default to short, scannable output with clear headings.

Why this works: Standing instructions set the audience, tone and hard rules once, so every chat inside the Project inherits them. Naming the source files and a 'don't invent' rule keeps Claude anchored to the real material rather than plausible-sounding guesses.

Open in Claude

Step four: work. Now open a new chat inside the Project and just ask. Notice what you no longer have to do: no pasting, no re-explaining who the audience is, no restating the house style.

A first task inside the ProjectClaude
Draft a first-week schedule for a new operations assistant joining on Monday 18 August. Base it on the onboarding checklist and the remote-working policy in the project. Flag anything the checklist expects that our policy doesn't actually cover.

Why this works: Because the checklist and policy are already project knowledge, Claude answers from them without an attachment. Asking it to flag anything missing turns the reference files into a working check, not just background.

Open in Claude

Claude produces a schedule drawn from the actual files, cites which file each part came from, and points out a gap, such as the checklist assuming a first-day office induction while the policy makes the first week remote. That contradiction is exactly the kind of thing a shared workspace surfaces and a scatter of separate chats hides.

Step five: iterate, and let it compound. A follow-up stays inside the Project, so it keeps all that context: "Now write the welcome email the new starter gets the Friday before, matching our house style." Every chat you add makes the Project more useful, because the knowledge and instructions are working the whole time.

When a Project is worth it

Not everything needs one. A Project earns its keep when the same background shows up again and again. Set one up when you will have several chats on one topic, when they share reference files, or when you want a consistent voice across all of them. For a single quick summary, an ordinary chat is faster. The test is simple: if you have pasted the same document into Claude twice, the third time belongs in a Project.

Using project knowledge for a fresh taskClaude
A manager asked what onboarding involves for their team. Using the project files, give them a one-page briefing: what happens in week one, what the manager needs to do, and who to contact for IT setup. Keep it to plain English and name your sources.

Why this works: Shows the Project paying off later: a new job (a manager briefing) reuses the same knowledge base with no re-pasting, and the standing instructions keep it on-voice automatically.

Open in Claude

Try it now

Common mistakes

  • Skipping the instructions. An empty instructions box wastes half the feature. Thirty seconds setting audience, tone and one hard rule changes every answer the Project ever gives.
  • Hoarding a Project into a junk drawer. A Project stuffed with forty loosely related files gets vague. Keep each Project to one genuine strand of work; start a second Project rather than overloading the first.
  • Assuming the files update themselves. Project knowledge is a snapshot of what you added. If the policy changes, you must replace the file. Claude won't magically know the new version.
  • Over-trusting because the context feels rich. A well-stocked Project makes answers feel authoritative, which is precisely when it's easiest to stop checking. Claude can still misread a file or blur two of them together. The "name your source file" rule exists so you can verify the load-bearing facts against the original in seconds. Use it, especially before anything goes to a manager or a new starter.

Keeping current

Projects gain features regularly: more knowledge capacity, better retrieval, sharing controls on Team and Enterprise plans. The core idea (knowledge plus instructions plus a shared history) is durable; the limits and extras aren't. Check the official Projects help article and the Claude release notes when something looks different. Accurate as of 13 July 2026.