A solo Claude project is a productivity tool. A shared Claude project is an institution — the place your team goes when "what's our policy on X" comes up. Setting one up well is one of the highest-leverage 20-minute investments a team lead can make.
What you actually share
A Cowork project bundles three things behind a single share link:
- Files — PDFs, Markdown, docs, anything text-extractable. Claude treats them as long-lived knowledge it cites in answers.
- Project instructions — A prompt-like text that runs implicitly on every conversation in the project. Use this for tone, style, format rules, or "always cite the source doc."
- Conversation history — Past chats are visible to anyone with access. New members can read how the team's been using it.
Get all three right and the project becomes self-onboarding.
The setup playbook
Step 1: Pick the project's job
Don't make a generic "team docs" project. Make a focused one. Examples:
- "Customer Support Knowledge" — policies, FAQ, escalation paths
- "Engineering Onboarding" — repo guide, deploy process, decision log
- "Sales Playbook" — talk tracks, objection handling, deal-stage criteria
A focused project produces precise answers. A generic one produces noisy ones.
Step 2: Curate, don't dump
Resist the urge to upload everything in your Drive. Pick the 5–15 documents that, if Claude only had access to those, could answer 90% of the questions the project is supposed to handle.
If you upload 200 documents:
- Cited answers become unreliable (Claude blends sources)
- Stale docs go unnoticed and start contaminating answers
- Anyone reviewing the project gets overwhelmed
5–15 high-signal docs > 200 mid-signal docs. Always.
Step 3: Write project instructions like a system prompt
This is the single most underused feature. The instructions field accepts free text and runs on every chat. Use it to:
You are answering questions for the Customer Support team.
Rules:
- Always cite the document and section you got the answer from.
- If the answer isn't in the project files, say so explicitly.
Do not guess.
- For policy questions, give the policy first, then nuance.
- Keep replies under 200 words unless asked for detail.
Voice: direct, factual, calm. No corporate filler.
That five-paragraph block changes every conversation. Citations become consistent. Hallucinations drop. Tone stays on-brand. Spend 20 minutes here.
Step 4: Seed it with three example conversations
Before you share the link with the team, run three real questions yourself. Examples:
- An obvious one ("what's our refund policy?")
- A nuanced one ("customer hit our hardship policy AND has a refund — which wins?")
- An out-of-scope one ("can you write me a poem?")
These conversations stay in the project history and teach new members how to use it. They're an instruction manual nobody has to write.
Step 5: Designate a maintainer
A project without an owner rots in 90 days. Pick one person responsible for:
- Quarterly review of files (replace anything stale)
- Reading new conversations to spot missing knowledge
- Updating instructions when patterns change
That person gets credit for "made the team 5x faster at X." Worth it.
When to retire a project
When you find yourself asking the same question outside the project because "the project is too noisy now" — that's the signal. Either prune aggressively or archive and start a fresh one.
Where to go next
- Read Cowork: collaborative AI workspaces explained for the broader picture.
- Read Multiplayer Claude.ai chats for the in-the-moment-with-teammates pattern (different from project-as-knowledge-base).
- Inside Waymaker, the Brain serves a similar role for personal context — pair the two for personal + team operating layers.