Most team Projects look great in week one and rot by month three. Someone uploads twenty files, three people each add their own copy of the brand guide, an old strategy doc never gets archived, and by Q2 the team quietly stops using it. This guide is the structure that keeps a shared Claude Project actually answering questions six months in.
TL;DR
- A shared Project needs one named owner, 5-8 dated Knowledge files on day one, and Instructions that say what the Project refuses. Everything else is maintenance.
- You need the Team plan ($25/seat/month, or $20/seat billed annually as of June 2026) or Enterprise to share Projects. Pro and Max are single-user only.
- Set project visibility to Private and grant teammates “Can view” by default; reserve “Can edit” for the owner. Anyone-can-edit is the same failure that killed your wiki.
- The single highest-leverage habit is a
decisions.mdthe owner appends to and re-uploads, plus a 30-minute monthly prune. Projects die from no one pruning, not from bad files.
What this covers
How to scope, populate, and maintain a shared Project so the third hire who joins next quarter can ask it questions and get answers your team would endorse. Covers ownership, file hygiene, instruction discipline, the permission model, and the quarterly review that prevents drift.
Who this is for
Team leads, ops folks, founders past the first five hires, and anyone who has been told “you own knowledge management” without being given a system. Especially useful if your team already pays for Claude Team or Enterprise and the shared Projects feature is sitting idle.
What you need: the plan reality
Sharing Projects across teammates is a Team or Enterprise feature. Personal plans (Pro, Max) keep Projects private to one account. The numbers below are current as of June 2026.
| Plan | Price | Team size | Project sharing | Best for |
|---|---|---|---|---|
| Pro | $20/mo ($17 annual) | 1 | No (single user) | Solo knowledge base |
| Max | $100 (5x) / $200 (20x) | 1 | No (single user) | Heavy solo usage |
| Team (Standard seat) | $25/seat/mo, $20 annual | 5-150 seats | Yes | Most small teams |
| Team (Premium seat) | $125/seat/mo, $100 annual | 5-150 seats | Yes, 6.25x usage | Power users on the team |
| Enterprise | Custom | 70+ typical | Yes + SSO/audit | Compliance-heavy orgs |
A few specifics worth knowing before you commit:
- Minimum five members. Team is not for solo use; you pay for at least five seats.
- Standard seats get 1.25x the Pro usage limit; Premium seats get 6.25x. Mix seat types so your owner and heaviest users get Premium and everyone else gets Standard.
- All seats run Claude Opus 4.7 and Sonnet 4.6 with a 1M-token context window (as of June 2026). For knowledge-base Q&A, Sonnet 4.6 is the workhorse and is plenty.
When to reach for it
Reach for it when at least three teammates ask the same context-heavy question more than twice a month, when onboarding requires “ask Sarah” too often, or when you keep re-pasting the same brand or product context into individual chats. Skip it if your team is under three people; direct messages are still faster.
How Project knowledge actually works
Understanding the retrieval mechanics changes how you load files:
- Small knowledge bases load fully into context. While your files fit inside the 1M-token window, Claude reads all of them on every message.
- Past that, Claude switches to retrieval (RAG). Anthropic documents that RAG can expand effective capacity by up to 10x, and it is available only on paid plans (Pro, Max, Team, Enterprise). The trade: Claude now pulls the most relevant chunks instead of reading everything, so a buried fact in file 19 can get missed.
- Per-file size cap is 30MB. There is no hard cap on file count, but retrieval quality degrades as the pile grows. That is the real reason to keep the set tight, not a quota.
The practical takeaway: every extra low-value file makes the high-value answers slightly worse. Curate like the context window is small even when it is not.
Before you start
- Name a single owner. Shared knowledge with no owner becomes shared rot. The owner does not write everything; they decide what stays.
- List the 5-10 highest-value recurring questions teammates ask. Those questions define which Knowledge files you actually need, not the other way around.
- Decide what is in scope: brand, product, decisions, customer FAQs. Anything else gets its own Project. One mega-Project is the failure mode.
- Get explicit buy-in from the people whose docs you are about to import. Surprise consolidation breeds resentment.
Step by step
- Create the Project with an outcome-shaped name. “Customer-facing answers Q3” beats “Support knowledge.” Outcome names force the owner to define done.
- Set visibility to Private and add teammates as “Can view.” In Claude, projects are Public (whole org) or Private (invited members), and private members get either “Can view” (read and chat) or “Can edit” (change instructions, knowledge, and access). Keep “Can edit” to the owner alone. Note: archiving a Project resets all sharing to Private, so re-grant access if you ever un-archive.
- Seed Knowledge with 5-8 files maximum on day one: the brand voice doc, the current pricing sheet, the top-10 FAQ, the elevator pitch, the latest roadmap one-pager. Resist importing everything from Notion.
- Write Instructions that say what the Project is FOR and what it is NOT. Example: “You answer as our support team voice. Never invent pricing. If asked about unannounced features, refuse and link to the roadmap doc.” Constraint instructions are worth more than role instructions.
- Run a calibration session. Have three teammates ask their real questions and screenshot answers. Where the output is wrong, fix the Knowledge file, not the prompt. Prompt-level fixes do not survive teammates rephrasing.
- Add a
decisions.mdand achangelog.mdto Knowledge. Every time the team makes a call (“we are sunsetting feature X,” “new pricing for Q4”), the owner appends a dated line and re-uploads. This is the single highest-leverage habit. - Schedule a 30-minute monthly review on the owner’s calendar. Open every Knowledge file, check the date, archive anything older than the relevant cycle (quarter for pricing, year for brand voice). Most Projects do not die from bad files; they die from no one pruning.
First-run exercise
- Pick three real questions teammates asked in Slack last week. Do not curate; use whatever was actually asked.
- Ask them inside the Project verbatim and screenshot the answers.
- For each answer, mark “ship as-is to a customer,” “needs editing,” or “wrong.” A new Project is doing well at 50% ship-as-is, 30% editing, 20% wrong.
- For each “wrong” answer, identify whether the fix belongs in Knowledge (missing fact) or Instructions (wrong tone). Apply exactly one fix per question, then rerun. Iterating two variables at once tells you nothing.
Quality check
- Can a new hire get a “good enough to send” answer to the top-5 recurring questions without asking a human? If not, Knowledge is incomplete.
- Are the answers consistent across rephrasing? Ask the same question three different ways. Wide swings mean Instructions are doing too much and Knowledge too little.
- Does the Project refuse the things it should refuse? Pricing, unannounced features, legal opinions. Test these explicitly.
- Is there a date on every Knowledge file’s first line? Undated files rot silently.
How to reuse this workflow
- Template the Instructions block so you can spin up a sister Project (Sales, Recruiting, Eng) in 10 minutes.
- Keep a “Knowledge file starter pack” list: brand voice, glossary, top-10 FAQ, current roadmap, decisions log, changelog. Every Project starts with the same six file slots.
- Log every “wrong” answer in a
lessons.mdwith the date and root cause. After roughly 20 entries you will see patterns, usually missing recency rather than missing facts. - Run a 30-minute audit quarterly across all team Projects. Owners attend. Drift gets named.
Common mistakes
- No owner. Diffuse responsibility means no one prunes and the Project dies by month four.
- Granting “Can edit” to everyone. Same failure mode as anyone-can-edit on Confluence. Funnel changes through the owner.
- Importing all of Notion on day one. Once your files exceed the context window, Claude switches to retrieval and a buried fact gets missed.
- Outcome-free Project name like “Marketing.” Scope creep follows immediately.
- Skipping the refusal instructions. The Project will confidently invent pricing the first time a teammate asks.
- Letting Knowledge files exist without dates. You cannot prune what you cannot age.
- Editing files locally without re-uploading. Chats silently use the old version and contradict the new policy.
- Treating chat history as institutional memory. Sharing a Project does not share chats; each teammate’s chats stay private. The file set is the durable record.
FAQ
- What plan do I need to share a Project?: Team ($25/seat/month, or $20/seat billed annually as of June 2026) or Enterprise. Pro and Max keep Projects private to one account.
- How many files is too many?: Each file caps at 30MB and there is no hard count limit, but once total knowledge exceeds the context window Claude switches to retrieval and accuracy on buried facts drops. Keep the active set to roughly 5-15 files per Project and split by outcome if you need more.
- Can teammates edit Knowledge?: Only members granted “Can edit.” Default everyone to “Can view” and route changes through the owner.
- Do shared Projects share chat history?: No. Sharing a Project shares the Knowledge and Instructions, not the chats. Each teammate has private chats inside the shared Project. If a decision needs to carry, write it into
decisions.md. - What model answers inside a Team Project?: Claude Opus 4.7 and Sonnet 4.6, both with a 1M-token context window as of June 2026. Sonnet 4.6 is the workhorse for knowledge-base Q&A.
Related
For the official rules, see Anthropic’s help center on what the Team plan includes and managing project visibility and sharing.
Tags: #Claude #team #Knowledge base #Tutorial