Claude · AI training guide

Claude Projects: How to Set Up Shared Knowledge and Instructions for Your Team

The short answer

A Claude Project is a dedicated workspace that keeps instructions, reference files, and related conversations together, so a team does not have to re-explain context every time. Build one per recurring job, write short and specific instructions, add only current reference material, and assign an owner who keeps it up to date.

What is a Claude Project and why do teams use it?

A Claude Project is a workspace where you keep standing instructions, uploaded reference material, and the conversations that belong to one body of work. Teams use Projects because they solve the most common daily annoyance: re-explaining who you are, what the company does, and what good output looks like, every single time.

Anthropic describes Projects, knowledge bases, and collaboration features as part of the feature set that the Team plan builds on. Plan details change, so check the current Team plan documentation for exactly what your plan includes.

The practical benefit is consistency. When ten people use the same Project to draft customer replies, they start from the same tone guide, the same product facts, and the same do-not-say list.

What should you put in a Claude Project?

Put in the context a smart new colleague would need on day one: the audience, the tone, the definitions, and a few examples of excellent work. Leave out anything outdated, contradictory, or sensitive beyond your data rules.

Instructions

Write the instructions as if briefing a capable contractor. State the role, the audience, the format you expect, and the mistakes to avoid. Keep them short enough that a person can read and maintain them.

You help our customer success team write renewal emails.
Audience: account contacts at mid-sized companies.
Tone: plain, warm, no hype. No exclamation marks.
Always: open with the value delivered this term, then the ask.
Never: promise discounts or dates. Flag those for a human.
Output: a subject line and a body under 180 words.

Reference files

Add the documents the work depends on: a style guide, a product fact sheet, a glossary, two or three model examples. Name files clearly. Remove superseded versions rather than leaving both.

Examples

One strong example teaches more than a paragraph of adjectives. Include a good output and, if you can, a short note on why it is good.

How do you organize Projects so people can find and trust them?

Organize Projects by recurring job, not by department or person. A Project called "Renewal emails" is findable and has an obvious scope. A Project called "Sales stuff" becomes a junk drawer.

Rules that keep a shared library healthy:

  1. One job per Project. If instructions need an "also" section for an unrelated task, split it.
  2. A named owner. One person is responsible for updating instructions and files.
  3. A visible date. Put a "last reviewed" line at the top of the instructions.
  4. A short README. The first lines should say what the Project is for, who it is for, and what it should not be used for.
  5. A retirement rule. Archive Projects nobody has used in a quarter.

How do Projects fit into a Claude training program?

Projects are the bridge between beginner and intermediate skill. A beginner learns to give Claude good context in a single chat. An intermediate user learns that good context can be saved, shared, and reused. That insight is when Claude stops being a toy and starts being infrastructure.

In a workshop, a strong exercise is to have each participant build one Project for a task they do weekly, test it on a real example, then swap with a colleague who tries to break it. People learn what makes instructions fail much faster by watching someone else misuse them.

See also our guide on prompting Claude for work for the request-writing skills that make Project instructions effective.

What are the risks of shared Claude Projects?

The main risks are stale context, accidental inclusion of data that should not be there, and over-trust. A Project full of out-of-date pricing will produce confident out-of-date answers for everyone.

Mitigations are simple. Review files on a schedule. Apply your data rules before upload, not after. Remind people that Project output is still a draft, and that anything customer-facing or contractual needs human review. Treat the Project owner role as real work, with time allocated, not a favor.

How are Projects different from regular chats and from artifacts?

A regular chat is a single conversation. A Project holds standing instructions and files that every conversation inside it can use. An artifact is something different again: a standalone piece of content, such as a document, page, or small app, that Claude creates alongside a conversation so you can view and refine it.

The three work together. You might keep a "Board update" Project with your template, tone guide, and last quarter’s update, run each new draft as a conversation inside it, and iterate on the draft as an artifact.

Product behavior evolves, so check the Projects help article for your plan’s current features.

What is a good starter set of Projects by department?

Start with five to eight Projects built around recurring jobs, one per department, and expand only when people ask.

  • Customer success: renewal emails, QBR prep, escalation summaries.
  • Sales operations: account research briefs, follow-up drafts after calls.
  • HR and people: job description drafts, policy plain-language rewrites, manager one-on-one prep.
  • Finance and operations: variance commentary, process documentation, vendor comparison tables.
  • Marketing: brand-voice editing, campaign brief drafts, repurposing one asset into several formats.
  • Legal and compliance: intake checklists, clause comparison summaries for human review. Keep a named reviewer.
  • Project management: weekly status roll-ups, meeting notes to action items, risk register upkeep.

For each Project, write the one-paragraph README, two example outputs, and the "never do this" list. Assign an owner and a review date. The goal is a library of about a dozen trusted Projects, not hundreds of abandoned ones.

Frequently asked questions

Can a whole team share the same Claude Project?

Collaboration features are part of the Team plan feature set Anthropic documents, so teams can work from shared Projects. Check the current plan documentation for exactly how sharing and permissions work on your plan.

How long should Claude Project instructions be?

As short as possible while still being specific. A useful rule is that a colleague can read them in a minute. Long, rambling instructions tend to contain contradictions.

Should we upload confidential documents to a Project?

Only what your data policy allows on the account you use. Decide the rules first, then upload. When in doubt, summarize or redact rather than upload the original.

What is the difference between a Project and a Skill?

A Project holds context for a body of work. A Skill packages a repeatable procedure that Claude can load when it is relevant. See our guide to Claude Skills.

What is the difference between a Claude Project and a Claude artifact?

A Project is a workspace with standing instructions and files. An artifact is a standalone piece of content Claude creates during a conversation, such as a document or small app.

What should I name my Claude Projects?

Name them for the recurring job, such as "Renewal emails" or "Weekly status report," so people can find the right one and understand its scope.

Product features, plans, and limits change often. This guide reflects the vendor documentation listed above as of November 2026. Check the vendor’s current documentation before you make purchasing or policy decisions. TechStack Consulting is an independent training firm and is not affiliated with Anthropic or OpenAI.

Want your team using Claude well, with governance in place?

Book my free Claude review

Free · 30 minutes

Free 30-Minute Claude Rollout Review

In 30 minutes, we’ll help you identify:

  • Highest-value business use cases
  • Governance and compliance requirements
  • Change-management considerations
  • Adoption risks
  • A practical rollout strategy

30 minutes · No pitch · Written recommendations