How to Set Up a Claude Project Knowledge Base That Helps

What a Project Knowledge Base Actually Does

A Claude project is a workspace with its own chats, its own instructions, and a shared knowledge base. Every new chat inside the project starts with the instructions applied and the knowledge available, so you stop re-explaining the same background. Anthropic's help center says projects are available on every plan, with free accounts limited to five projects.

What a project does not do is remember your previous project chats word for word. The knowledge base is what you put there on purpose. If a decision was made in chat three and never written into a file, chat seven will not reliably know about it. That single fact drives most of the setup advice below: the knowledge base is a maintained document set, not an archive.

Two mechanics matter for how big it can get. First, when project knowledge approaches the model's context window on a paid plan, Claude automatically switches to retrieval (RAG) mode, searching your files for relevant passages instead of loading everything. Anthropic says this can expand capacity by up to 10x. Second, project content is cached and, per the usage best-practices article, counts less against your limits when reused, though caches expire after a period of inactivity.

What To Put In (and What To Leave Out)

The test for any file is simple: would you paste this into more than a third of the chats in this project? If yes, it belongs. If you need it once, attach it to that one chat instead.

The biggest failure mode is conflicting sources. If the knowledge base has a pricing doc from March and another from September, Claude may quote either. Delete the old one or rename it clearly (for example, ARCHIVED-pricing-march.md) and say in the instructions that archived files are history only.

A Setup Sequence That Works

1. Name the job. One project per recurring body of work (a product launch, a client, a course), not one per topic you find interesting.
2. Collect three to eight core files. Convert slide decks and PDFs with heavy layout into clean text or Markdown when you can; plain structure retrieves more predictably.
3. Give every file a descriptive name and a top line. A first line like "Source of truth for 2026 pricing. Updated 2026-10-28." helps both you and retrieval.
4. Write an index file. A short 00-index.md listing each file, what it covers, and which one wins on conflicts.
5. Write project instructions (next section). Keep them shorter than any single knowledge file.
6. Run three test questions whose answers you already know, including one that requires combining two files. If an answer is wrong, fix the file, not the chat.

Writing Project Instructions

Instructions tell Claude how to behave; knowledge tells it what is true. Mixing the two is a common mistake: people paste a style guide into the instructions field and a list of rules into a file, then wonder why both get applied loosely. Keep instructions about role, priorities, output format, and how to treat the files.

You are helping run the Q1 launch for Acme's analytics product.

How to use the knowledge files:
- 00-index.md lists every file and which one wins on conflicts.
- Treat files starting with ARCHIVED- as history, never as current fact.
- If the files don't answer a question, say so before using general knowledge.

Defaults:
- Audience is B2B ops leads; plain language, no hype words.
- When drafting, give one recommended version, then at most two alternatives.
- Quote the file name when you rely on a specific number or decision.

The last line is the most useful one. Asking Claude to name the file it relied on makes stale sources visible within a few chats, which is exactly when you want to catch them.

Keeping the Knowledge Base Fresh

A project that worked well in week one often drifts by week six because the work moved and the files did not. Build a small maintenance habit instead of a big cleanup later.

• After any chat that changes a decision, update the decisions log before you close the tab.
• Once a week, skim the index and delete or archive anything superseded.
• Put a date in the first line of every file so drift is visible at a glance.
• If you return after a long break, expect the first message to cost more, since caches expire after inactivity.
• Check the project's memory too. Each project keeps its own memory, and you can stop it from using your account memory with the "Use account memory" toggle on the project page.

A worked example: a consultant runs one project per client with six files (scope, stakeholder map, glossary, decisions log, latest status report, style notes). Each Friday she replaces the status report and appends two or three lines to the decisions log. The project stays small enough to load in context, answers cite current numbers, and nothing from a cancelled workstream leaks into new drafts.

Troubleshooting Bad Project Answers

When a project gives a wrong or vague answer, the instinct is to argue with Claude in the chat. That fixes one answer and leaves the cause in place for the next chat. Diagnose the knowledge base instead.

A good diagnostic prompt is to ask Claude which files it would use for a given question before it answers. If it names the wrong file, or none, you have found the problem without spending a full answer on it. Retrieval also rewards specificity in your questions: "Using the pricing file, what is the annual discount?" is more reliable than "what discounts do we offer?" once a project is large enough to be in RAG mode.

When Not To Use a Project

Projects add overhead. Skip them for one-off questions, quick rewrites, or exploration where you do not yet know what the reference material is. They are also the wrong place for reusable procedures (a code review checklist you want in every context); a Claude Skill or saved prompt fits that better. See Claude Projects vs Claude Skills for that decision.

Also be careful on Team and Enterprise plans, where projects can be shared with "Can view" or "Can edit" permissions. A shared knowledge base needs one owner, or it fills with duplicates within a month.

Where ClaudeKit Fits

The hard part of a project is moving conclusions out of chats and into files. ClaudeKit helps with that step. You can pin the specific Claude answers that settled a question into the Workspace panel, then copy them into your decisions log at the end of the session. When a project chat gets long, the Handoff Brief turns it into a compact summary you can paste into a fresh chat or save as a knowledge file.

If you reuse the same test questions or kickoff prompts across projects, store them in the prompt library. For wider context on carrying work between chats, read how to move a Claude conversation to a new chat.