Three separate mechanisms in Claude that are easy to conflate: skills, artifacts, and context. Skills change *what Claude knows how to do*. Artifacts are *what Claude produces*. Context is *what Claude can see*. This note covers all three and how they interact. ## Skills A skill is a packaged set of instructions for a specific kind of task — a repo-specific workflow, a document-formatting procedure, a review checklist. Skills live as files (a `SKILL.md` plus optional supporting scripts/resources) and get invoked by name. - **What they're for**: repeatable, well-defined procedures. Anthropic ships some (docx, pptx, xlsx, pdf creation; a `learn` skill for teaching mode; a `schedule` skill for recurring tasks), and you or a project can define your own. - **How they trigger**: either Claude recognizes the task matches a skill's description and invokes it automatically, or you invoke one explicitly by name (a slash-command-style reference). - **What happens on invocation**: the skill's instructions load into the current turn and effectively override Claude's default approach for that task. Some skills run inline; others hand off to a subagent and return only a finished result. - **Order of operations matters**: for skills that produce a *format* (docx, pptx, xlsx, pdf), the convention is research first, format second. Claude should gather all the facts/content it needs using search and file tools, and only load the format skill once it has real content to put in the document. Reading the format skill too early anchors on document mechanics before there's anything correct to write. - **Creating your own**: there's a `skill-creator` skill for scaffolding, editing, and evaluating skills, including testing trigger accuracy. The key distinction from artifacts: a skill is *instructions for how to do something*. It doesn't produce a visible thing on its own — it changes Claude's behavior for the task at hand. ## Artifacts An artifact is a distinct, addressable piece of content Claude produces — code, a document, a diagram, an interactive component — that's kept separate from the conversational reply. - **When Claude creates one**: for substantial, self-contained content the user will want to view, edit, reuse, or come back to — not for short conversational answers. Typical triggers: "write a document," "build a component," "make a presentation," anything meant to be copy-pasted or saved elsewhere. - **Rendering**: certain file types get special treatment in the interface — Markdown, HTML, React (`.jsx`), Mermaid diagrams, SVG, and PDF all render inline rather than as plain text blocks. - **Constraints worth knowing**: artifacts are single-file (no separate CSS/JS files for HTML/React — everything inlined), and browser storage APIs (`localStorage`, `sessionStorage`) are not available — state has to live in memory (React state, JS variables) for the duration of the session. - **In Cowork specifically**: there's also a *persistent* artifact type — a saved HTML page that reconnects to live data (via connector tool calls) each time it's reopened, rather than a static one-off. That's a different, longer-lived thing from a normal chat artifact: it's for dashboards/trackers/reports you'd want to refresh later, not one-off outputs. The key distinction from skills: an artifact is *a thing produced*, not a set of instructions. You can get an artifact without any skill being involved (e.g. writing a plain SVG diagram), and a skill invocation doesn't necessarily produce an artifact (e.g. a skill that just changes how Claude answers a question). ## Context Context is what's actually loaded into Claude's working memory for a given turn — everything it can "see" and reason over. - **Conversation history**: prior messages in the current thread. - **Uploaded/attached files**: some file types (md, txt, html, csv, png, PDF-as-image) get their contents pulled directly into context when attached, so Claude can read them without a separate tool call. Other types need an explicit file-read. - **Tool results**: output from web search, file reads, shell commands, MCP connector calls — all of this becomes context once retrieved, but isn't there by default. Claude has to go get it. - **System/project instructions**: standing instructions (like this vault's `CLAUDE.md`) are loaded into every relevant turn automatically — they're a form of persistent context Claude doesn't have to re-fetch. - **Memory**: a separate, longer-lived layer — files Claude writes to persist facts, preferences, and project state *across* conversations, not just within one. Distinct from in-conversation context because it survives when the conversation ends. - **Limits**: context is finite. Long conversations, large files, or verbose tool output all consume the same budget. This is part of why skills exist as a separate mechanism — a skill's instructions only load when relevant, rather than sitting in context permanently. ## How the three interact A typical flow: context (files, search results, prior conversation) supplies the raw material → a skill supplies the procedure for turning that material into a specific kind of output → an artifact is the resulting deliverable. Skills often *produce* artifacts (the docx/pptx/xlsx skills always do), but the two aren't the same axis — one's a capability, the other's an output.