
Claude Skills vs Projects vs Artifacts: What Each One Actually Is
Three Claude features with overlapping names and completely different jobs. Skills are procedures, Projects are context, Artifacts are output — here's how to tell which one you need.
Skills, Projects and Artifacts get confused constantly, and the confusion is understandable — all three are things you "set up" in Claude, all three persist beyond one message, and none of the names say what they do.
The distinction is cleaner than the naming suggests. They sit at different points of the same request:
- Projects are what Claude knows before you ask.
- Skills are what Claude does when you ask.
- Artifacts are what Claude hands back.
Context, procedure, output. Once you see them in that order, choosing between them mostly stops being a question — you rarely pick one instead of another, because they answer different halves of the same job.
Artifacts: the output
An artifact is a substantial thing Claude produced, shown in its own panel beside the conversation instead of inline: a webpage, a React component, a document, a diagram, an SVG.
The reason it gets its own panel is that it's meant to leave the chat. An HTML artifact is a working page — its JavaScript runs, its buttons work — and you can download it, publish it to a link, or iterate on it across several messages without Claude retyping the whole thing each time.
Artifacts are per-conversation and ephemeral by default. They don't carry over to your next chat, and nobody else can see one until you publish it. (What publishing exposes is its own question: are Claude artifacts public?)
You want an artifact when: you asked Claude to make something.
Projects: the context
A Project is a workspace that holds knowledge and instructions across many conversations. You attach reference material — a style guide, an API spec, a set of transcripts, your product's docs — and set instructions that apply to every chat started inside it.
The point is not saving retyping. It's that Claude answers from that material rather than from general knowledge. Ask a question inside a Project holding your API docs and you get your endpoints, not plausible-looking generic ones. Conversations inside a Project stay grouped, so a body of related work doesn't scatter across your history.
You want a Project when: you keep pasting the same background material at the start of every conversation.
Skills: the procedure
A Skill is a packaged set of instructions for performing a particular kind of task — a procedure Claude can follow, invoked when the work matches. Where a Project supplies facts, a Skill supplies method: how your team formats a release note, which checks run before a deploy is called done, the steps in your incident write-up.
The distinction that matters in practice: a Project makes Claude better informed, a Skill makes it behave consistently. If two colleagues ask for the same deliverable and get differently-shaped answers, the missing piece is a Skill, not more context.
You want a Skill when: you find yourself re-explaining how to do something you've already explained.
Telling them apart in one line
| What it is | Lives where | Question it answers | |
|---|---|---|---|
| Artifact | Something Claude made | One conversation | "What did I get?" |
| Project | Reference material + standing instructions | Across conversations | "What does Claude know?" |
| Skill | A packaged procedure | Across conversations | "How does Claude do it?" |
They stack
The confusion often comes from treating these as alternatives. A single piece of work usually touches all three: a Project holding your brand guidelines and last quarter's reports, a Skill describing how your monthly summary is structured, and the artifact that comes out — the actual document.
Swapping one for another is where friction shows up. People routinely paste a procedure into Project instructions where a Skill belongs, and then wonder why it's followed inconsistently in long conversations. Or they attach reference files to a Skill, where they'd be better placed in a Project that several Skills can draw on.
What is a Claude artifact, exactly?
An artifact is one piece of work Claude produced and put in a side panel instead of into the chat, because it is meant to be kept rather than read once. Underneath what are artifacts in Claude there are usually three narrower questions, and the definition on its own answers none of them:
- Why it appeared in a panel at all. Claude opens an artifact when the output is substantial, self-contained and likely to be edited or reused — a whole page, a full document, a component. A short answer or a two-line snippet stays inline. You can ask for one explicitly, but you usually don't have to; the shape of the answer decides it.
- Whether the word names one thing or a feature. Both, which is what makes the plural confusing. Artifacts is the feature; an artifact is one of them. A single conversation can produce several, each in its own panel.
- What you actually have when you have one. Not a file on your computer, and not an address anyone else can open. An HTML artifact runs in the preview, but the preview is part of Claude's interface, not a page on the web. Getting it somewhere a reader can reach means downloading it or putting it on a URL.
So an artifact is the output, and it is still sitting where it was made. That is the part that has to change if anyone but you is going to see it.
Getting the output out
Whichever combination produced it, the artifact is where the work lives, and it's stuck in a chat window until you move it. Downloading gives you a file — with one significant gotcha for React artifacts. Publishing gives you a link, either Claude's own or a standalone one you control, with the differences laid out in how to publish a Claude artifact.
Related
- Are Claude artifacts public? — what publishing an artifact actually exposes
- How to unpublish a Claude artifact — and why it is a one-way door
- Turn a Claude artifact into a link you control — somewhere for the output to live
Bottom line: Projects are context, Skills are procedure, Artifacts are output. You don't choose between them — you notice which one you're missing. Repeating background material means you want a Project; repeating instructions means you want a Skill; and whatever comes out the far end is an artifact that still needs somewhere to live.
更多文章

What Happens When a dochost Page Expires, and How to Bring It Back
After 7 days a free page shows an expired notice instead of the content. Nothing is deleted: the page, its URL, its views and likes are all kept. Here is what readers see, what the owner sees, and the three ways to put the same link back online.

How to Get a Published dochost Page Indexed by Google
Published pages are noindex by default. Flip one switch on the manage screen and a permanent, public page becomes indexable, joins the sitemap, and can rank under its own title. Here are the five conditions, why free pages are excluded, and how to check the result.

How Long a Free dochost Link Lasts, and How to Extend It
Free pages expire after 7 days. Here is where that countdown shows up — success panel, reader footer, dashboard — and the three ways to keep a page online: a one-time extension, a like milestone, or a plan that makes every link permanent.
邮件列表
加入我们的社区
订阅邮件列表,及时获取最新消息和更新