What Skills Actually Are: Account-Level, Automatic, Variance-Reducing

Beyond the Parallel: What a Skill Concretely Is

The previous concept draws a parallel between Skills and system-level instructions -- both are reusable, packaged guidance instead of re-explaining a task each time. That parallel is useful, but the exam also expects you to know what a Skill *is* as a concrete product feature, not just what it's analogous to.

A Skill packages a repeatable procedure. Anthropic ships several of these out of the box for everyday document work -- building out a spreadsheet, drafting or revising a Word file, assembling slides, or restructuring a PDF. Someone who asks Claude to turn a pasted table into a formatted workbook or clean up a PDF's layout is triggering one of these built-in procedures, even if they've never heard the word "Skill."

Custom Skills: When a Team Builds Its Own

Custom Skills can be added through settings for task-specific workflows a team repeats often -- but that raises the practical question every builder eventually asks: if a system-level instruction already captures "how we want this done," why build a Skill at all?

The answer is procedure versus behavior. A system-level instruction is well suited to *behavioral* guidance that applies broadly across a workspace -- tone, role, boundaries, format defaults. A custom Skill earns its keep when the task has a multi-step procedure with its own internal logic, one that's awkward to compress into a paragraph of instruction text and that gets invoked the same way regardless of which Project the request comes from.

Consider a finance team that closes the books every month. The system-level instruction for their Project might say "you are a financial-close assistant; be precise, flag any unreconciled variance over $500, and never finalize a number without a cited source." That's behavior -- it applies to how Claude acts throughout the Project. But the actual close procedure -- pull the trial balance, match it against three named subledgers in a specific order, apply the standard rounding convention, flag variances above the threshold in a specific format, and produce a standardized handoff memo -- is a *procedure* with sequenced, task-specific steps. That procedure is a strong candidate for a custom Skill: it's the same steps every month, it's detailed enough that burying it in the standing instruction would make the instruction bloated (violating the concise/high-signal trait covered in the previous concept), and once built as a Skill it's available automatically wherever the team needs it -- not just inside the one Project where someone remembered to paste it.

The practical rule of thumb: if you can state it in one or two sentences of standing behavior, it's an instruction; if it's a repeatable, multi-step workflow with its own internal structure, it's a better fit as a Skill.

Account-Level, Not Project-Level

Here's the detail that separates Skills from everything else in this domain: a Skill sits at the level of the whole account, never tucked inside a single Project. Instructions and project knowledge, by contrast, are set up per Project and stay confined there. A Skill works differently -- it's on tap account-wide, and Claude reaches for it automatically whenever it fits, whether or not you're inside a Project at the time. There's no per-workspace on/off switch to flip; it's simply there wherever you're logged in.

"Claude Just Knows How to Do This" -- Skill or Project Knowledge?

From a learner's chair, both a Skill and Project knowledge can look identical: you ask for something, and Claude produces it correctly without you re-explaining the details. That surface similarity is exactly why this distinction is a recurring point of confusion, and the exam leans on it.

The test is what's actually doing the work. Say a Project has a style guide uploaded, and Claude reliably follows the house style when drafting a memo -- that's project knowledge: a document being retrieved and used to ground the answer, and it would disappear if you asked the same question in a different Project without that upload. Now say Claude reliably converts a messy CSV paste into a properly formatted Excel workbook with formulas, in that Project and in a completely unrelated chat outside any Project -- that's a Skill: a procedure Claude runs, not a document it consulted, and it travels with the account rather than staying behind in one workspace.

A fast way to tell them apart in a scenario: ask whether the behavior would still happen in a brand-new, empty Project (or a plain chat with nothing uploaded). If yes, it's a Skill. If the behavior depends on something someone specifically uploaded or configured in that one Project, it's project knowledge (or an instruction).

Reduces Variance, Doesn't Eliminate It

A Skill tightens up how consistent the output is; it doesn't clone the output. Run the same reporting Skill five separate times and the five results will follow the same layout and formatting rules while still coming out worded differently each time. Assuming a Skill's consistency means byte-for-byte repeatable text is the mistake to avoid: variance shrinks, it doesn't vanish. Anything a Skill hands back still deserves the same scrutiny you'd give any other Claude output.

Common exam traps

• Assuming Skills need to be configured per Project, the way instructions and knowledge do. Skills are account-level and available everywhere on the account automatically -- there's no Project-by-Project setup step.
• Confusing "built-in Skill invoked automatically" with "a document Claude happened to have." A Skill is a procedure Claude runs (how to build the spreadsheet, how to restructure the PDF), not a piece of grounding knowledge -- don't classify a Skill scenario as a project-knowledge scenario.
• Treating a Skill's consistency as eliminating variance entirely. A Skill narrows the range of outcomes; it does not make every run of the same Skill produce identical text.
• Reaching for a custom Skill when a one- or two-sentence instruction would do, or the reverse -- cramming a genuinely multi-step procedure into an instruction until it becomes bloated. The dividing line is standing behavior (instruction) versus a repeatable procedure with its own internal steps (Skill).