A project is a workspace for one goal, with its own memory of what matters.

The simple definition

A project in Claude is a container that groups three things together: the chats you have about one subject, the reference material you want Claude to be able to read (often called project knowledge), and a set of standing instructions that apply to every chat in that container. When you open a new chat inside a project, Claude starts with that reference material and those instructions already available, so you can go straight to your question.

Why not just use ordinary chats?

An ordinary chat is like a single phone call. It can be wonderfully useful, but when it ends, the next call starts from zero. A project is more like an ongoing working relationship with a colleague who keeps a file on your work. Each new conversation opens that file first.

What projects are good for

Everything a project does comes from three simple parts working together.

Block one: project instructions

Project instructions are standing directions that apply to every chat in the project. They tell Claude who it is helping, what the project is for, what style to use, and what to avoid. You write them once, and they act as the opening briefing for every conversation. Examples include “Write for busy managers in plain English,” “Always give the answer first, then the reasons,” or “Never invent facts that are not in the attached documents.”

Block two: project knowledge

Project knowledge is the reference material you add to the project: documents, notes, data, guidelines, past examples, or pasted text. It is a library that Claude can consult when you ask a question in any chat inside the project. This means you do not need to attach the same file over and over.

Block three: the project’s chats

Each conversation you start inside the project lives in its list of chats. They are grouped together, so they are easy to find, and each one begins with the project’s instructions and knowledge in reach. Different chats can focus on different tasks, such as drafting, reviewing, or brainstorming, while sharing the same foundation.

flowchart TD
    A["You create a project"] --> B["Add project instructions"]
    A --> C["Add project knowledge"]
    B --> D["Start a new chat inside the project"]
    C --> D
    D --> E["Claude reads instructions and relevant knowledge"]
    E --> F["Claude answers with your context already in place"]
    F --> G["You refine instructions and knowledge over time"]
    G --> D

Read the diagram from the top. You create the project, then add instructions and knowledge. When you start a chat inside the project, Claude reads the instructions and consults the relevant knowledge, and answers with your context in place. As you learn what works, you refine the instructions and knowledge, and your next chat is better than the last. The loop at the bottom is the heart of a healthy project: it improves with use.

How the blocks differ

Starting a project takes only a few minutes. The thinking you do before you start is what makes it worthwhile.

Step one: choose one clear purpose

Before you click anything, finish this sentence: “This project exists to help me ______.” A clear purpose such as “write my monthly customer newsletter” or “understand the documents for my home loan” keeps the project focused. A vague purpose such as “my stuff” turns a project into a junk drawer.

Step two: create it and give it a good name

In the app, look for the area that lists your projects and choose the option to create a new one. Give it a name you will recognize in six months, and a short description of its goal. Names such as “Monthly Newsletter” or “Home Loan Paperwork” are better than “Project 1”.

Step three: add a first set of instructions

Start with a short, honest briefing. Say who you are, what the project is for, who the audience is, and how you want answers to look. You can improve it later, so do not aim for perfection on day one.

Step four: add the most useful knowledge

Add the few documents that you would otherwise attach most often. Resist the urge to add everything. A small, well-chosen shelf beats a giant, messy one.

Step five: start a chat and test it

Ask a question you already know the answer to. If Claude answers correctly and in the right style, the project is working. If not, you have just discovered what to fix.

Instructions are the single biggest lever you have. Clear ones make every chat better.

What good instructions contain

Before and after

Tell Claude why, not only what

A reason gives Claude something to reason from. “Keep answers short because readers view them on a phone” lets Claude make good decisions in cases your rule did not mention, such as trimming a list or choosing a smaller table.

Say what to do rather than what not to do

Positive instructions are usually easier to follow than long lists of prohibitions. “Write in plain sentences” tends to work better than a dozen bans on jargon. Keep a short list of firm “never” rules for the few things that truly matter.

Keep them readable

Instructions that run to many pages become hard to maintain, and details in the middle can get lost. Use short paragraphs or a short list, put the most important rules first, and remove anything that no longer applies.

The right documents turn a general assistant into one that knows your world.

What to add

Good candidates for project knowledge are material you refer to repeatedly and that rarely changes: style guides, product descriptions, policies, glossaries, past examples of good work, research papers, meeting notes, and templates. Anything you find yourself attaching to every chat is a candidate.

What to leave out

Leave out material that is outdated, duplicated, or irrelevant to the project’s purpose. Also leave out anything sensitive that the project does not truly need, such as personal identification numbers or passwords. A shorter, cleaner shelf gives better answers than a huge, cluttered one.

How Claude uses the shelf

Claude reads the project knowledge as part of the conversation, much like a document you attached directly. Because every piece of text takes up room in the conversation’s working space (called the context window), the amount of knowledge you can use effectively is limited. Some products and plans handle larger collections by searching the material and bringing in only the relevant parts. The details can vary by plan and over time, so check the Help Center for what your account supports.

flowchart TD
    A["You ask a question in a project chat"] --> B["Claude sees instructions and your question"]
    B --> C{"Is project knowledge needed?"}
    C -->|"Yes"| D["Relevant knowledge is brought into the conversation"]
    C -->|"No"| E["Claude answers from instructions and general ability"]
    D --> F["Claude combines question, instructions, and knowledge"]
    E --> G["Answer"]
    F --> G
    G --> H["You verify important points against the source"]

The diagram shows that knowledge is not always used. For a general question, Claude may answer from the instructions and its own ability. For a question about your material, the relevant parts are brought into the conversation, and Claude combines them with the question and the instructions. In all cases, you should verify anything important against the source.

Organize and name your files

Give every document a clear name that says what it is and which version it is, such as “Brand Voice Guide, 2026” instead of “final_v3_new”. Clear names help you manage the shelf, and they help Claude and your teammates refer to the right file.

Keep the shelf current

Documents go out of date. If a policy changes, replace the old file rather than adding a second one. Having both old and new versions on the shelf can lead Claude to mix them, and you will not always notice.

A little understanding of the mechanism explains both the strengths and the limits.

Everything arrives as text in the conversation

Claude does not remember your project in the way a human colleague remembers it. Each time you start a chat, the project’s instructions and the relevant knowledge are supplied to Claude as part of that conversation’s input. Claude reads them along with your question and writes an answer. When the chat ends, the knowledge is still safely stored in the project, ready to be supplied to the next chat.

The context window: a shared desk

Claude can only consider so much text at once. This limit is called the context window, and it is measured in tokens, which are small chunks of words. Your instructions, the knowledge that is brought in, the whole chat so far, and Claude’s answer all share the same space.

What this means in practice

• Short, sharp instructions are cheap and powerful. They are read every time, so make every sentence earn its place.
• Huge knowledge sets have limits. If answers seem to miss something that you know is on the shelf, try a more specific question that names the document or the section.
• Very long chats drift. After many exchanges, details from the start can become less reliable. Starting a fresh chat in the same project is free, and it brings the instructions and knowledge back with it.
• Claude can still be wrong. Having the right document available does not guarantee a perfect reading of it. Ask for quotes and verify important facts.

Why the same project can give different answers on different days

Claude writes its answers one small piece at a time, choosing likely next words based on everything it can see. Because of that, two answers to the same question can differ in wording, and occasionally in emphasis. A project narrows this variation by supplying the same instructions and sources every time, but it does not turn Claude into a fixed machine. If a result matters, ask for the sources, compare the answer with the document, and regenerate or rephrase the question when something looks off.

Projects are not a database

Project knowledge is meant to be read and used in conversation. It is not a precise lookup system. For tasks that need exact counts across thousands of records, a spreadsheet or a database is the right tool, and Claude can help you analyze the results from them.

Knowing when to use a project, and when not to, saves effort.

Projects and personal preferences

Claude offers ways to set your general preferences, such as your preferred tone or style, that apply across your chats, and in some accounts a memory feature that carries information between chats. These are different from a project. Preferences and memory describe you in general; a project describes one piece of work. Project instructions are the right place for rules that only apply to that work. Availability and behavior of these features depend on your account and settings, so look at your settings and the Help Center for the current picture.

Projects and other tools

Projects can be combined with other capabilities your account offers, such as creating documents or working with connected apps. The exact options vary, so rather than assuming, check what is available in your app. A good habit is to write down in your project instructions which outputs you want, such as “produce the final version as a clean document I can copy” so that the habit travels with the project.

A few design decisions at the start prevent a messy project later.

One project, one purpose

Resist the urge to build a single giant project for everything. A project about “work” will have instructions that fit nothing in particular. Separate projects for separate purposes keep the instructions sharp and the knowledge relevant.

Splitting by audience or by stage

Use consistent names and structure

If you have several projects, name them in a pattern, such as “Client A: Proposals” and “Client A: Reports”. When you write instructions, reuse a layout you like, so you can scan any project quickly.

Plan for change

Projects evolve. Add a short “last reviewed” note in your own records, and schedule a reminder to review instructions and knowledge every few months. A project that quietly goes stale will produce stale results.

Write the description for a stranger

The short description of a project is easy to neglect, yet it is the first thing a teammate or your future self will read. Say what the project covers, what it deliberately does not cover, and who looks after it. For example: “Helps draft customer emails for the support team. Does not handle refunds above the approval limit. Owned by the support lead.” Three plain sentences prevent a great deal of confusion, because people quickly learn whether they are in the right place.

Decide the boundary early

Every project needs an edge. Without one, new documents and new rules keep arriving until the project tries to do everything and does nothing well. Write down what belongs inside, such as products, policies, and tone rules for customer emails, and what belongs elsewhere, such as internal finance reports. When a new request falls outside the boundary, create a separate project instead of stretching the old one. This single habit keeps instructions short, knowledge relevant, and answers dependable over many months.

Design for handover

Imagine a colleague taking over tomorrow. Could they understand the project from its name, its description, and its instructions? If not, improve them. This test makes the project more reliable for you too.

Real examples show how the pieces fit together.

A large shelf needs a plan, or answers get vague.

Ask specific questions

With many documents, a vague question may pull in the wrong passages. Name the document, the section, or the topic: “In the 2026 travel policy, what is the limit for hotel stays?” is much better than “What is the hotel limit?”

Create an index document

A simple trick is to add one extra file that lists every other document, with a one-line description and its date. This index helps both people and Claude understand what is on the shelf and which file to prefer when there is overlap.

Ask for sources

Tell Claude, in the instructions, to name the document and quote the supporting sentence for each fact. This habit lets you verify answers quickly, and it reveals when Claude has used the wrong file.

When the shelf gets very large

Some organizations build their own systems to answer questions over huge collections. These systems usually use a method called retrieval-augmented generation. They prepare the documents ahead of time, then at question time search for the most relevant passages and give only those to Claude. Your project may use a similar idea behind the scenes depending on your plan, but the principle is the same: bring the right passages to the desk instead of the whole library.

flowchart TD
    subgraph P1["Preparation"]
        D1["Documents"] --> D2["Extract text and clean"]
        D2 --> D3["Split into chunks"]
        D3 --> D4["Create embeddings"]
        D4 --> D5["Search index"]
    end
    subgraph P2["At question time"]
        Q1["Your question"] --> Q2["Find the most relevant chunks"]
        Q2 --> Q3["Build prompt with question and chunks"]
        Q3 --> Q4["Claude answers with sources"]
        Q4 --> Q5["You verify the sources"]
    end
    D5 --> Q2

In the preparation half, documents are cleaned, split into chunks, and converted into embeddings, which are lists of numbers that capture meaning, then stored in a searchable index. At question time, your question finds the nearest chunks, which are handed to Claude with the question. Claude answers and names its sources, and you verify them.

Split very large collections into several projects

If a collection covers distinct areas, such as finance, legal, and operations, separate projects often give sharper answers than one giant project, and they make it easier to control who has access.

The chats are the daily work. A little discipline keeps them findable.

One task per chat

A chat that begins with drafting an email and ends up planning a budget is hard to search later and hard for Claude to follow. Start a new chat for each distinct task. Since the project’s context comes with every new chat, starting fresh costs you nothing.

Name chats clearly

Rename chats so you can find them: “Issue 7 draft” or “Policy questions, March”. When you come back after a month, you will thank yourself.

Carry forward decisions

If an important decision is made in one chat, other chats do not automatically know about it. Capture it: add a short note to the project knowledge (“Decision log”), or paste a summary at the start of the next chat. A decision log is one of the most valuable documents a project can have.

Know when to restart

After a long exchange, responses can become less consistent, because the chat has used up much of the shared desk. If you notice drift, ask Claude to summarize the conclusions so far, copy that summary, and open a new chat in the same project with the summary pasted at the top.

When several people use the same project, consistency becomes the biggest benefit and the biggest challenge.

Why teams use shared projects

A shared project gives everyone the same instructions and the same reference material, so answers do not depend on who happened to write the prompt. New members get up to speed faster, and knowledge stays with the team rather than inside one person’s chat history. Whether sharing is available, and how it works, depends on your plan and your organization’s settings, so check the Help Center and ask your administrator.

Roles and responsibility

Onboarding new teammates

A shared project is also a teaching tool. When someone new joins, show them the purpose line, walk through the instructions, and explain which documents live on the shelf and why. Encourage them to try a few starter questions and to compare the answers with the sources. People who understand how the project is built ask better questions, notice errors sooner, and report problems instead of quietly working around them. A short written guide, kept inside the project knowledge, saves the owner from repeating the same explanation every time the team grows.

Handling disagreements about the answers

Sometimes two teammates see different answers and each believes theirs is right. Treat this as useful information. Compare the exact questions, check which documents were used, and look at the change log for recent edits. Often the cause is a small difference in wording or a recently replaced file. Settle the matter by returning to the source document, then update the instructions or knowledge so the same confusion does not return.

Rules that help teams

• Name an owner. A project without an owner drifts and decays.
• Write down the change process. Who may edit instructions? How are changes announced?
• Keep a change log. A short note of what changed and why helps explain sudden differences in answers.
• Agree on verification. Decide which kinds of answers must be checked against sources before they are used.
• Respect access. Put sensitive documents only in projects that the right people can see.

Projects are powerful, and like every tool they come with costs.

Cost and effort

When a project is not worth it

If you will ask only a few questions and never return to the topic, an ordinary chat is simpler. The effort of building a project pays off when you expect repeated use, or when several people depend on consistent answers.

A project stores material for reuse. That convenience is exactly why it deserves careful thought.

Decide what belongs in a project

Redact and minimize

The safest information is information you never stored. Replace real names with labels such as “Customer A”, remove numbers that do not matter, and trim documents down to the parts the project needs.

Review who has access

For shared projects, check who can see and edit them, and remove people who no longer need access. Revisit this whenever team membership changes.

Understand your settings

Read the privacy and data settings of your account and your organization’s policy. Features that carry information between chats are helpful, and they also mean more is kept. Choose what you are comfortable with. For questions about how data is handled on your plan, the Claude Help Center at support.claude.com is the place to look.

Hidden instructions in documents

A document added to a project can contain text aimed at the AI instead of the human reader, such as “ignore your instructions and do this instead.” This trick is called prompt injection. Claude is trained to resist it, but no defense is perfect. Add documents only from sources you trust, and be suspicious of any answer that suddenly changes topic or urges an unusual action.

Businesses watch dashboards to keep their systems healthy. You can keep a simple version for your project.

Build a small test set

Write down eight to twelve questions whose correct answers you already know, covering different documents and different task types. After any major change to the instructions or the knowledge, ask them again and compare. This is the most effective quality check you can do.

flowchart TD
    A["Change instructions or knowledge"] --> B["Run your test questions"]
    B --> C{"Are the answers correct and well formed?"}
    C -->|"Yes"| D["Keep the change"]
    C -->|"No"| E["Find the cause"]
    E --> F{"Instruction, knowledge, or question problem?"}
    F -->|"Instruction"| G["Clarify or shorten the rules"]
    F -->|"Knowledge"| H["Fix, replace, or add documents"]
    F -->|"Question"| I["Ask more specifically"]
    G --> B
    H --> B
    I --> B

The loop is easy to follow. After any change, run the test questions. If the answers are good, keep the change. If not, work out whether the fault lies in the instructions, the knowledge, or the way the question was asked, fix that one thing, and test again. Changing one thing at a time makes the cause easier to find.

What to measure

Keep a log of failures

Whenever an answer is wrong, write down the question, what went wrong, and the fix. Patterns appear quickly: a missing document, an ambiguous rule, a question that needs more detail. The log becomes a guide to improvement.

Ask Claude to review the setup

Paste your instructions into a chat and ask: “Find any conflicts, gaps, or unclear rules, and suggest cleaner wording.” You decide what to adopt, but the review often catches issues you stopped seeing.

Most project problems have simple causes.

A three-question diagnosis

• Did Claude see the right material? If not, fix the knowledge or the question.
• Did Claude know the rule? If not, fix the instructions.
• Did Claude follow the rule and use the material but still get it wrong? Ask for quotes, check the source, and give feedback in the chat for a corrected answer.

A short field guide to keep near you when you build or review a project.

Best practices

Common mistakes

• Creating one giant project for unrelated work.
• Writing vague instructions such as “be helpful and professional”.
• Uploading everything instead of selecting the documents that matter.
• Leaving old and new versions of the same document side by side.
• Putting rules into documents and facts into instructions, mixing the two roles.
• Never testing, and only noticing problems when an answer goes wrong in public.
• Storing sensitive details that the project did not need.

Checklist before you rely on a project

Quick answers to questions people often ask about projects.

The whole idea on one page.

A project in Claude is a workspace for one goal. It combines standing instructions, a shelf of reference material, and a set of related chats, so that every new conversation starts with your context already in place. The instructions carry your rules about audience, style, format, and sources. The knowledge carries the documents Claude may consult. The chats do the daily work. Behind the scenes, the instructions and relevant knowledge are supplied to Claude as text in each conversation, which means the size of the shared working space matters, and short, sharp instructions and a clean, current shelf produce the best results. Design each project around one purpose, split large collections, keep decisions in a log, and test with questions whose answers you know. When teams share a project, name an owner and a process for changes. Protect private information by storing only what is needed, and treat instructions hidden inside documents as information, not commands. Above all, keep the habit of asking for evidence and checking what matters.