Claude Projects: shared context your team stops explaining over and over
Claude Projects lets you set up a shared workspace with standing instructions, uploaded documents, and organisational context your whole team can use.
Claude Projects lets you create a shared workspace for your team: with standing instructions, uploaded documents, and organisation-specific context. In every conversation, Claude immediately knows how your team operates, what your tone is, and what information is relevant. You explain it once — not at the start of every new chat.
Most teams using Claude work with standalone conversations. Every morning, each person starts a blank chat and explains again who they are, how the organisation works, and what writing style to use. It works — but it is wasteful. Every new conversation discards the context built before it. Projects solves this.
What are Projects?
Projects are centralised workspaces in Claude. You create a Project for a team, department, or specific workflow. In that Project you define: which instructions Claude always follows, which documents or files Claude can consult, and which tone and approach apply.
Every conversation a team member opens within that Project starts with that context already loaded. Claude does not need warming up. The context is there from the first message — for every conversation, for every team member with access.
Projects are available in Claude Pro (personal use) and Claude Teams/Enterprise (shared team use). The critical difference: with Teams and Enterprise, you share the Project environment — including instructions and documents — with colleagues. Everyone in the Project works from the same knowledge base.
Personal vs. shared.
Not every Project needs to be shared. Personal Projects are already valuable for individuals — shared Projects are where the real organisational impact happens. Here is the difference:
| Feature | Personal Project | Shared Project (Teams/Enterprise) |
|---|---|---|
| Users | One person | Multiple team members |
| Instructions | Personal workflow | Team or organisation standard |
| Documents | Personal files | Shared knowledge base |
| Conversations | Private per user | Private per user, shared context |
| Administration | Self-managed | Designated owner |
Personal Projects work well for individuals with fixed workflows: an analyst who always produces the same type of reports, a marketer who always writes in the same style. Shared Projects are what most organisations are looking for: consistency across the whole team, without everyone reinventing the wheel.
Writing Project instructions.
Project instructions are the foundation of every Project. This is the text Claude receives as its starting point for every conversation in that Project. Do not write them as a list of rules — write them as an introduction to your organisation and its expectations.
Effective Project instructions contain four elements:
- Who you are as an organisation. Not a full company description — the essence: type of business, sector, target audience, core activity.
- How you communicate. Formal or informal? Direct or diplomatic? What terminology do you use? What words do you avoid?
- What Claude knows about the team. Which roles work in this Project? What tasks do they perform most often? What are the most common requests?
- What Claude never does. Exclusions, boundaries, sensitive areas. What is off-limits for this Project?
A concrete example for a legal team:
You work as an assistant for the legal team at [Organisation].
Communication style: formal, precise, free of jargon for non-lawyers.
Team: contract lawyers, paralegal staff, and the compliance officer.
Most common tasks: contract review, clause analysis, internal advisory notes.
Always use "client" for the customer and "we" or "the firm" for our organisation.
Never cite external legal sources without explicitly stating you are doing so.
Do not make substantive legal judgements — flag and describe. The judgement belongs to the lawyer.Good instructions are specific without being rigid. They give Claude enough direction to make the right calls independently — without requiring a separate rule for every edge case.
Adding documents.
The second pillar of a Project is the knowledge base: documents you upload that remain available for all conversations in that Project. Claude can consult the content without team members needing to re-attach files every time.
What works well as a Project document:
- Brand voice guide or style sheet — so tone and word choice are always consistent
- Product or service descriptions — as raw material for customer communications
- Contract templates or standard clauses — for legal workflows
- Process descriptions or work instructions — for operations and support
- Frequently asked questions — internal or external, as a reference frame
- Existing reports as format references — so new reports follow the right structure
What you do not need to upload: documents that change per conversation. Project-specific data, current figures, or client-specific information you add per conversation. The Project documents are the stable background — the things that are always true for this team.
“Every new hire we bring on has access within ten minutes to a Claude environment that already knows how we write, what our products are, and what tone of voice we use. That is onboarding we used to do manually.”— Head of Marketing, professional services firm, 85 employees
Examples by department.
How Projects are set up in practice varies by team. These are four configurations we regularly implement:
Marketing and communications.
Project instructions: writing style, tone of voice, brand values, audience description, preferred forms of address. Documents: content strategy, style guide, existing content as reference. Typical tasks: blog drafts, social media posts, newsletters, campaign copy, press releases.
Legal and compliance.
Project instructions: formality level, fixed terminology, exclusions for substantive judgements. Documents: standard contracts, GDPR policy, internal compliance guidelines. Typical tasks: contract review, advisory notes, summarising new legislation, compliance checklists.
Operations and project management.
Project instructions: internal process terminology, reporting format, escalation procedures. Documents: process manuals, SLA agreements, project templates. Typical tasks: drafting status reports, incident summaries, refining work instructions, reviewing project plans.
IT and development.
Project instructions: technical standards, coding style, architecture principles, naming conventions. Documents: API documentation, technical specifications, architecture documents. Typical tasks: code review, writing documentation, explaining technical decisions to stakeholders, impact analysis of changes.
Best practices.
Setting up a Project takes ten minutes. Building a good Project takes more care — but the investment pays off with every use that follows.
- Start narrow. Set up your first Project for one team or one clearly bounded workflow. Not a catch-all organisation Project as your starting point.
- Test before you roll out. Run ten representative conversations in the Project. Is the output consistent? Are there blind spots in the instructions?
- Assign an owner. One person is responsible for maintaining instructions and updating documents. Without an owner, a Project goes stale fast.
- Review quarterly. Which instructions are still relevant? Are there new documents that belong? What do team members ask most often?
- Combine with Skills. Projects deliver context — Skills deliver structure for recurring tasks. Together they are stronger than either alone.
Teams using Claude Projects with shared instructions and documents work 30 to 40 percent more efficiently per AI task than teams using standalone conversations. The difference is not in the model's capabilities — it is in the context the model receives.
Want to know how to set up Projects for your team? We guide the initial configuration and help write instructions that make Claude immediately useful. Thirty minutes, no strings attached.