Claude Projects vs Skills vs Artifacts

Claude Projects, Skills and Artifacts are not three versions of the same feature, so the choice is rarely either-or. A project is a workspace: knowledge and instructions that every chat inside it starts from. A skill is a packaged procedure, instructions and sometimes scripts, that Claude loads only when a request matches it, in whichever chat you are in. An artifact is an output: a document, a dashboard or a small tool Claude makes that you can keep, iterate on and share. Put simply, the project answers “what does Claude need to know about this work?”, the skill answers “how do we do this job?”, and the artifact answers “what are we handing over?”. Most real work uses all three.

The difference at a glance

• What it holds. Project: uploaded knowledge, project instructions and the chats inside it. Skill: a folder with a SKILL.md, plus any scripts, templates or reference files. Artifact: one piece of content Claude produced.
• When Claude uses it. Project: in every chat in that project. Skill: only when your request matches its description, in any chat. Artifact: when you open it, or ask Claude to change it.
• Scope. Project: one body of work. Skill: one kind of job, across all your work. Artifact: one deliverable.
• Who it is for. Project: the people working on it. Skill: whoever does that job. Artifact: whoever you share it with, including people who never see the chat.

Projects: background for a set of chats

Anthropic’s help centre describes projects↗ (opens in a new tab) as self-contained workspaces with their own chat histories and knowledge bases. You upload documents, set project instructions, and each chat in the project starts with both. On paid plans, when knowledge grows large Claude switches to retrieval so a project can hold far more than a single chat. On Team and Enterprise plans a project can be shared inside the organisation, with Can view or Can edit, though each person’s chats in it stay private unless they share them; the details are in can Claude Projects be shared.

The property that matters for this comparison is that a project is always on. The help centre’s article on what skills are↗ (opens in a new tab) draws the line in exactly those terms: projects provide static background knowledge that is always loaded, while skills activate dynamically. That makes a project the right home for things that are true of every conversation about the work, and the wrong home for a procedure only one conversation in ten needs.

Skills: procedures loaded when relevant

A skill is a folder of instructions, scripts and resources. Anthropic’s Agent Skills overview↗ (opens in a new tab) explains how it stays cheap: only the name and description sit in context until a request matches them, then the body of SKILL.md is read, and bundled files are read or run only when the instructions call for them. A script’s code never enters the context; only its output does. That is why you can install many skills without crowding the window.

In the Claude apps, skills need code execution switched on. According to the help centre’s guide to using skills in Claude↗ (opens in a new tab), you upload a custom skill as a zipped folder under Customize, Skills; on Team and Enterprise plans you can share a skill with specific people or groups, and owners can provision skills for everyone in the organisation. The same overview notes that custom skills do not sync between surfaces: a skill uploaded in the Claude app is separate from one in Claude Code or the API.

Skills are also a different thing from a connection to another system. A skill says how to do a job; an MCP server gives Claude access to something it cannot otherwise reach. That line is drawn in MCP vs Claude skills, and five skills worth writing for running projects are in Claude skills for project management.

Artifacts: outputs you can keep and share

The help centre defines an artifact↗ (opens in a new tab) as anything Claude makes that you would put in front of someone: a design, a deck, a document, a dashboard or a small interactive tool. Claude tends to create one when the content is substantial and self-contained, typically over 15 lines, and likely to be edited, reused or referred back to. Some artifacts can store data between sessions, and some can call Claude themselves, which is how a tracker or a small app ends up living in one.

Artifacts start private. Anthropic’s page on sharing artifacts↗ (opens in a new tab) lists the options by plan: the Free plan has no link sharing, only publishing of older chat artifacts; on Pro and Max, only you, anyone with the link, or people invited by email (in beta); on Team and Enterprise, invited people, the organisation, or anyone with the link. Depending on the artifact, people can view, comment or edit, and an artifact that pulls from connected apps uses the viewer’s connections rather than yours. What sharing does not add is a list of work with task states and a record of who changed each task, which is the gap described in Claude Artifacts sharing limits.

When to use which

• You keep pasting the same background into new chats: the brief, the style guide, the client’s constraints. That is a project.
• You keep typing the same steps for a job, whichever project you are in: the weekly report, the review checklist, the release notes format. That is a skill.
• You need something to exist outside the conversation: a page to send, a dashboard to open tomorrow, a tool a colleague can use. That is an artifact.
• A rule applies only when doing one job, not in every chat in the project. Take it out of the project instructions and put it in a skill.
• Reference material that only one job needs, such as a report template. Bundle it in that skill rather than loading it into every chat as project knowledge.

How they combine

Take a consultant producing a monthly report for a client. The three pieces each carry one part of the job:

1. The project holds the client: the contract summary, the brand guide, last quarter’s figures, and instructions such as “British spelling; never quote figures that are not in the knowledge”. Every chat about this client starts briefed.
2. A skill holds the job: how the monthly report is structured, which checks to run on the numbers, and a script that formats the tables. It works the same in this client’s project and the next one.
3. The artifact is the result: the report or a small dashboard, iterated in the chat and then shared with the people who need it.

The division keeps each piece small. Project instructions stay about the client rather than filling up with procedures; the skill stays reusable because it knows nothing about any one client; and the artifact is a clean deliverable rather than a transcript. Keeping project instructions short and current is covered in Claude Projects best practices.

Mistakes that blur them

• Procedures in project instructions. They load into every chat whether or not the job is being done, and they cannot be reused in another project.
• Client facts in a skill. The skill stops being reusable, and the facts go stale in a place nobody thinks to update.
• An artifact as the record of work. A tracker in an artifact is fine for one person; once several people and assistants change it, you need to know who changed what, with what rights.
• Expecting chats to share what they learned. The help centre notes that context is not shared across chats in a project unless it is added to the project knowledge. Write conclusions back deliberately.

What none of the three is

None of them is a list of work with owners and a history. A project knows the background, a skill knows the procedure, an artifact is the output; none records which tasks are open, who has them, or who changed what. fenbs is built for that part: a board of tasks, each a feature, enhancement or bug, in lanes To Do, Next Up, In Progress and Completed, where people and AI assistants are members with roles defined by the company. Claude connects over MCP with the Claude connector, acts under the role of the person who connected it, and appears in the board’s history as “Claude via” that person. A skill can then say how your team files a bug, and the board decides whether this caller may.