Most team Projects look great in week one and rot by month three. Someone uploads twenty files, three people each add their own duplicate 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.
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, and the quarterly review that prevents drift.
Who this is for
Team leads, ops folks, founders past the first 5 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.
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.
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 what 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.
- 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 the urge to import everything from Notion.
- Write Instructions that say what the Project is FOR and what it is NOT. “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 ~20 entries you will see patterns — usually missing recency, not missing facts. - Run a 30-minute audit quarterly across all team Projects. Owners attend. Drift gets named.
Recommended workflow
Owner spins up Project with outcome name → seeds 5-8 Knowledge files dated on line 1 → writes Instructions with explicit refusals → runs calibration with 3 teammates on real questions → fixes Knowledge until 50%+ ship-as-is → adds decisions.md and changelog.md → puts a recurring monthly prune on calendar → audits quarterly with all owners.
Common mistakes
- No owner. Diffuse responsibility means no one prunes and the Project dies by month four.
- Importing all of Notion on day one. Retrieval gets noisier with every file past the first ten.
- 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. Chats are private and ephemeral; the file set is the durable record.
FAQ
- What plan do I need?: Team or Enterprise. Personal plans cannot share Projects across teammates.
- How many files is too many?: Past 15-20 active files, retrieval degrades. If you need more, split into multiple Projects by outcome.
- Can teammates edit Knowledge?: Yes on Team plans, but anyone-can-edit is the same failure mode as anyone-can-edit on Confluence. Funnel changes through the owner.
- Do shared Projects share chat history?: No. Each teammate has their own chats inside the shared Project. If a decision needs to carry, write it into
decisions.md.
Related
Tags: #Claude #team #Knowledge base #Tutorial