Projects and Project Knowledge

A Project is a workspace inside Claude that bundles three things: a set of reference documents (project knowledge), standing instructions (project instructions) and the conversations that use them. Every chat started inside the Project sees the knowledge and follows the instructions without you having to repeat anything. For business users, Projects are the single biggest step from "chatting with Claude" to "working with Claude", and the exam expects you to know what belongs in one and how its parts interact.

Why Projects exist

Without a Project, each conversation starts from zero. You attach the brand guide again, paste the tone rules again, explain the product again. Projects solve the repetition problem and, as a side effect, make output more consistent, because every chat starts from the same base. They also let Memory (Domain 5) stay scoped: what Claude learns about your work in one Project does not leak into another.

The three components

Project knowledge is the document library. You can upload files (PDFs, Word documents, spreadsheets, text, images), add text snippets directly, and, where connectors are set up, pull in content from workplace tools. Typical contents: a style guide, product documentation, pricing sheets, standard contract clauses, a glossary of internal terms, examples of excellent past work.

Project instructions are a standing prompt applied to every conversation. This is where the role, audience, tone, format rules and rubric live. Anything you would otherwise type at the start of each chat goes here. Domain 5 covers writing good instructions in depth.

Conversations are ordinary chats, except that they inherit the knowledge and instructions. They are listed within the Project, which keeps related work together and easy to find.

How knowledge is used

When the knowledge is small enough, Claude has all of it in view for every message. As a Project grows beyond what fits, the app switches to a retrieval approach: it searches the knowledge for the passages most relevant to your current question and brings only those into view. This allows far larger libraries, but it changes how you should prompt. Instead of assuming Claude has read everything, ask it to search: "Check the project knowledge for any clause about liability caps." If a document is central to every task, say so in the instructions so it is always consulted. The capacity thresholds change over time and depend on plan; check the help centre for current figures.

Setting up a Project well

A practical sequence:

1. Name the purpose narrowly. "Customer success: renewal emails" beats "Customer success". Narrow Projects have cleaner instructions and knowledge.
2. Add only authoritative knowledge. Out-of-date or contradictory documents actively harm output. Prefer one current source per topic.
3. Write instructions that cover role, audience, format, tone, rubric and what to refuse (for example, "never quote prices; refer to the pricing sheet by name").
4. Add examples of great output as knowledge and reference them in the instructions.
5. Test with three real tasks, fix what went wrong by editing instructions or knowledge, and only then invite colleagues.
6. Schedule maintenance. Assign an owner to review knowledge quarterly and after any major change.

Before and after

Before a Project, a sales operations analyst's weekly prompt ran to 400 words: tone rules, the pricing table pasted in, format for the summary, and the request itself. After setting up a Project with the pricing sheet and past summaries as knowledge, and the tone and format rules as instructions, the weekly prompt is:

Here is this week's pipeline export. Produce the Monday summary.

The output is also more consistent, because the format is defined once rather than re-described each time.

Shared Projects

On Team and Enterprise plans a Project can be shared with colleagues. Members work in their own conversations against the common knowledge and instructions, and whoever manages the Project controls its contents. This is how a team standardises: the onboarding Project for new starters, the proposals Project for sales, the policy Q&A Project for HR. Governance matters here: a shared Project's knowledge is visible to all members, so do not put anything in it that some members should not see, and name an owner responsible for keeping it accurate.

Projects versus attachments versus Memory

Need	Use
A document for this one conversation	Attach it to the chat
Documents and rules reused across many conversations	Project knowledge and instructions
Claude to remember your preferences and context over time	Memory, which is scoped per Project where enabled
A shared team standard	Shared Project on a business plan

Common mistakes

Stuffing a Project with every document ever written, so retrieval returns noise. Writing instructions that contradict the knowledge. Letting knowledge go stale. Using one giant Project for unrelated tasks, which dilutes instructions. Assuming colleagues will know the Project exists; shared Projects need an introduction.

Exam focus

• A Project bundles knowledge (documents), instructions (a standing prompt) and the conversations that inherit both.
• Small knowledge sets are fully in view; large ones use retrieval, so prompts should ask Claude to search for relevant passages.
• Instructions carry role, audience, format, tone, rubric and refusals; knowledge carries authoritative reference material and examples.
• Shared Projects on business plans standardise team output; their knowledge is visible to all members and needs an accountable owner.
• Attachments are per chat; Projects persist; Memory is scoped per Project where available.