Claude offers two different ways to make its answers more consistent and more grounded in your business: Skills and Projects. They look similar on the surface — both let you attach context Claude uses across conversations — but they solve different problems. Projects give Claude standing background knowledge for a workspace. Skills give Claude a repeatable procedure it loads only when a task calls for it. Mixing the two up leads to bloated projects that slow Claude down, or scattered one-off instructions that never get reused. This guide explains what each feature actually does, how they work together, what data and governance each one needs, and how a business should decide which to build first.
Quick Answer
Claude Projects are self-contained workspaces that hold standing background knowledge — documents, instructions, and context — that Claude loads every time you start a chat inside that project. Claude Skills are folders of instructions, scripts, and resources that Claude loads dynamically, only when a specific task calls for them, whether that's applying a brand style guide, running a specific data-analysis method, or following a company's meeting-notes format. Projects matter to any team that repeatedly asks Claude questions grounded in the same background material — a client account, a product area, a compliance framework. Skills matter to any team that wants Claude to complete a specific, repeatable task the same way every time, across any conversation, not just inside one project. Most organizations end up using both: Projects for what Claude should always know in a given context, Skills for how Claude should do a specific job whenever it comes up. Vantage Point helps CRM-driven teams decide which combination fits their workflow and builds the underlying data and governance to support it.
TL;DR
- What it is: Projects are standing-knowledge workspaces; Skills are dynamically loaded, reusable procedures.
- Why it matters: Using the wrong one causes real problems — overloaded projects that slow responses, or one-off prompts that never scale into a repeatable process.
- Best for: Projects suit ongoing work tied to a specific account, product, or knowledge base. Skills suit a specific task Claude should perform the same way every time, anywhere in Claude.
- Decision point: Ask whether the need is "Claude should always know this" (Project) or "Claude should always do it this way" (Skill) — many workflows need both together.
- How Vantage Point helps: We help teams scope Projects and Skills around clean CRM data and governed workflows through CRM and marketing automation and advisory and change management.
What Are Claude Skills and Projects?
Projects are self-contained Claude workspaces with their own chat history and knowledge base. Inside a project, you upload documents, add project instructions, and every chat started within that project automatically has access to that background. Projects are available to all Claude users, including free accounts, though free users are capped at five projects. On paid plans (Pro, Max, Team, or Enterprise), project knowledge automatically scales through Retrieval Augmented Generation (RAG) as the material grows, expanding capacity by up to 10x without a person managing the overflow. On Team and Enterprise plans, projects can also be shared across an organization with tiered permissions — "can use" for members who chat within a project, and "can edit" for members who can update its instructions and knowledge.
Skills are folders of instructions, scripts, and resources that Claude loads dynamically to improve performance on a specific, specialized task. Rather than staying loaded in the background the way project knowledge does, a skill activates through "progressive disclosure" — Claude reviews which skills are available, decides which are relevant to the current request, and loads only what it needs. That keeps the context window from filling up with instructions that do not apply to the task at hand. Skills are available on every plan tier — Free, Pro, Max, Team, and Enterprise — provided code execution is enabled in the account, and they are also available in beta for Claude Code and API users using the code execution tool.
Anthropic maintains its own built-in skills (for example, enhanced document creation for Excel, Word, PowerPoint, and PDF files) that apply automatically for all users. Organizations can also build custom skills for things like applying brand guidelines, following a specific data-analysis method, creating tickets in a project-management tool according to team conventions, or structuring meeting notes in a consistent format. On Team and Enterprise plans, an organization Owner can provision skills centrally so they show up automatically in every team member's skills list, rather than requiring each person to build or upload their own.
Skills vs. Projects: The Core Difference
| Dimension | Projects | Skills |
|---|---|---|
| What it holds | Standing background knowledge and instructions for a workspace | A reusable, specific procedure Claude follows for a task |
| When it loads | Always, for every chat started inside that project | Dynamically, only when Claude judges the task calls for it |
| Where it applies | Inside that specific project only | Everywhere across Claude, in any project or chat |
| Best for | Ongoing work tied to a client, product, or knowledge base | A repeatable task performed the same way every time |
| Plan availability | All plans (free capped at 5 projects; paid plans get RAG-scaled capacity) | All plans, with code execution enabled; beta for Claude Code/API |
| Team sharing | Team/Enterprise: shareable with "can use" / "can edit" permissions | Team/Enterprise: Owners can provision skills org-wide |
| Typical failure mode | Overloaded knowledge base slows and confuses responses | A one-off instruction that never gets reused or standardized |
The clearest way to decide: if the requirement is "Claude should always know this background when we work in this area," build a Project. If the requirement is "Claude should always perform this task the same specific way, no matter which conversation it comes up in," build a Skill. Many real workflows need both — a project holding the account or product context, and a skill defining the exact procedure for a recurring task performed within it.
How Skills and Projects Work Together
A common pattern for CRM-driven teams:
- Set up a Project for a defined area of work — a specific account team, a product line, a quarterly initiative — and upload the documents, notes, and instructions Claude should treat as background for every chat in that space.
- Attach or reference Skills for the recurring tasks that come up inside that project — generating a status update in a specific format, applying a data-analysis method, following a company's brand style for a document.
- Let Claude combine them automatically. The project supplies the "what we're working on" context; the skill supplies the "how we always do this specific thing" procedure. Neither replaces the other.
This mirrors how the Model Context Protocol (MCP) fits alongside both: MCP connects Claude to your live systems of record — a CRM, a document repository, a support platform — while skills teach Claude how to work with what those connections return, and projects hold the standing context around a specific area of work. Teams building MCP connections to systems of record should think about all three layers together rather than treating them as competing features.
What Data Does Each One Need?
For Projects: upload only what genuinely needs to be standing background — client documents, product specs, style guides, prior decisions. Avoid dumping an entire shared drive into a project's knowledge base; on paid plans RAG will handle scale gracefully, but a bloated, disorganized knowledge base still produces worse answers than a curated one, and it takes longer for anyone to audit what Claude actually has access to.
For Skills: a skill is fundamentally an instruction set, often paired with example files or scripts. The data it needs is whatever a person would need to perform the task correctly and consistently — a brand style guide for document creation, a specific analysis method for a recurring report, a template for a specific type of customer communication. Custom skills that touch business systems (creating tickets, generating client-facing documents, running data workflows) should be built and reviewed by someone who understands both the underlying process and the platform it touches.
What Governance Is Required?
- Review before organization-wide provisioning. On Team and Enterprise plans, Owners can push skills to every team member automatically. Review a custom skill's instructions and any attached scripts before provisioning it broadly — a flawed procedure now runs consistently across the whole organization instead of just one person's workflow.
- Control project sharing deliberately. Team and Enterprise plans allow project sharing at the individual, bulk, or organization-wide level. Decide who can edit a project's knowledge and instructions versus who can only use it, and confirm whether organization-wide sharing is appropriate for the content inside — client-specific or confidential material generally should not default to org-wide visibility.
- Keep sensitive data out of shared projects unless access controls match its classification. A shared project's knowledge base is visible to everyone with "can use" permission. Treat it the same way you would treat a shared drive folder — with deliberate access decisions, not defaults.
- Audit custom skills that execute scripts. Skills can include executable scripts for more advanced functionality. Any skill that runs code or interacts with an external system should go through the same review a script or integration would get anywhere else in the business.
- Revisit periodically. Both projects and skills accumulate over time. Stale project knowledge (outdated pricing, a closed initiative) and outdated skills (a process that changed) should be retired, not left active indefinitely.
What Can Go Wrong?
- Overloaded projects. Uploading everything "just in case" into a project's knowledge base makes it harder for Claude — and for people — to tell what is actually relevant, even with RAG scaling capacity on paid plans.
- One-off instructions that never scale. Re-typing the same instructions into every new chat, instead of packaging them as a skill, means the procedure never gets standardized and inconsistencies creep back in.
- Confidential material in a shared project. Organization-wide project sharing is convenient, but it is easy to default into it for something that should have stayed restricted to a smaller group.
- Unreviewed skills going organization-wide. A skill provisioned to every team member without review can propagate an error or outdated process at scale.
- Treating either feature as a substitute for clean underlying data. Both Projects and Skills work with whatever documents, records, or instructions you give them. If the CRM data or source documents behind a project or skill are inconsistent or out of date, Claude will faithfully reflect that inconsistency back.
How to Start
- Pick one real workflow, not a hypothetical one. Choose a recurring task or an active area of work — not a broad "let's use AI" mandate — and decide whether it needs a project, a skill, or both.
- Start with a Project if the need is background knowledge. Upload the specific documents and instructions relevant to that area of work, and keep the knowledge base curated rather than exhaustive.
- Start with a Skill if the need is a repeatable procedure. Write the instructions in plain Markdown — no coding required for simple skills — and test that Claude applies it consistently before relying on it.
- Review before scaling either one. Have someone who understands the underlying process check a skill's instructions, or a project's sharing settings, before provisioning it broadly on a Team or Enterprise plan.
- Connect to live systems only where it earns its keep. If the workflow depends on current CRM records rather than static documents, that is an MCP connector question, not a project-knowledge question — evaluate the two together.
What Businesses Should Do Next
Most organizations do not need to choose between Skills and Projects — they need a plan for which problem each one solves inside their actual workflows. Start by mapping your recurring Claude use cases into two buckets: things Claude should always know for a given area of work, and things Claude should always do the same specific way regardless of context. That mapping, done against real CRM and business workflows rather than in the abstract, is what turns Skills and Projects from interesting features into a durable part of how a team works.
How Vantage Point Helps
Vantage Point helps CRM-driven teams figure out where Claude Projects and Skills actually fit their workflows — and where the real leverage is a live MCP connection to Salesforce or HubSpot instead. Because we are vendor-agnostic and dual-platform, and because every engagement is staffed by senior consultants rather than junior teams, we scope the decision around your actual data and process, not a generic AI rollout plan.
That starts with clean, well-organized source data and documented processes — the foundation any project's knowledge base or skill's instructions depend on — through our CRM and marketing automation practice. When the rollout involves training teams to use Skills and Projects consistently and reviewing what gets provisioned organization-wide, our advisory and change management practice builds the governance and adoption plan around it. And where the better answer is connecting Claude directly to live CRM records rather than static project knowledge, our system integration and data migration work builds that connection safely.
FAQ
What is the difference between Claude Skills and Claude Projects?
Projects are self-contained workspaces that hold standing background knowledge and instructions, loaded automatically every time you start a chat inside that project. Skills are reusable procedures that load dynamically, only when Claude judges a specific task calls for them, and they work across any conversation — not just inside one project.
Can I use Skills and Projects together?
Yes, and many real workflows benefit from both. A project can hold the standing context for a specific account or initiative, while a skill defines the exact, repeatable procedure Claude should follow for a recurring task that comes up inside that project.
Are Skills available on the free Claude plan?
Skills are available on Free, Pro, Max, Team, and Enterprise plans, provided code execution is enabled on the account. They are also available in beta for Claude Code users and for API users using the code execution tool.
How many projects can a free Claude user create?
Free accounts can create up to five projects. Paid plans (Pro, Max, Team, or Enterprise) do not have that cap, and project knowledge automatically scales through Retrieval Augmented Generation as content grows.
Who can provision Skills across an entire organization?
On Team and Enterprise plans, an organization Owner can provision skills so they appear automatically in every team member's skills list, with the option to enable or disable them by default. Review a custom skill's instructions before provisioning it organization-wide, since it will then run consistently across every user.
Do Skills or Projects connect Claude to live CRM data?
No — both features work with documents, instructions, and content you provide directly. Connecting Claude to live, current records in a CRM like Salesforce or HubSpot is a separate capability, typically built through an MCP (Model Context Protocol) connector.
What is the biggest risk with Claude Projects?
The most common failure is overloading a project's knowledge base with more material than the workflow actually needs, which makes it harder to tell what is relevant even with RAG scaling capacity on paid plans. Curate what goes into a project rather than uploading everything available.
How should a business decide whether to build a Skill or a Project first?
Ask whether the immediate need is "Claude should always know this" — background knowledge for a specific area of work — or "Claude should always do this the same way" — a repeatable task. The first points to a Project; the second points to a Skill. Most teams eventually need both, but starting with the one tied to a real, current workflow avoids building either in the abstract.
