Skills

A skill is a packaged procedure — a folder under .claude/skills/ whose entry point is a SKILL.md file. When a task matches a skill's description, an agent loads the skill and follows its method instead of improvising. The Skills view is where you browse, inspect, edit, and author them; the library ships with 23 of them.

Open it from the sidebar, in the Agents section: Skills.

Skills is a Pro surface — see Tiers: Pro & Ultra. Without an active subscription the view still appears in the sidebar and renders a lock instead of the library.

How skills work

Three facts explain the whole layer:

• A skill is registered by existing. A directory in .claude/skills/ with a SKILL.md is a skill — no manifest, no build step, no registration. Saving the file is the deployment; the next invocation reads it fresh.
• The description is the gate. Agents decide whether to load a skill by its frontmatter description. A precise, keyword-rich description that says when to use the skill — and when not to — is the single highest-leverage line in the file.
• Skills disclose progressively. A good SKILL.md stays lean and defers its bulk to sibling files in the same folder (references, templates, assets) that load only when needed. This keeps the always-loaded cost of a skill small.

How a skill is reached

Two independent frontmatter switches decide how a skill can be invoked, and a skill may set either, both, or neither:

The two are not opposites, and that is the point. A skill can be auto-invoked and offered as a command; a skill that sets neither is simply auto-invoked and has no command of its own. Both are checkboxes in the create dialog — Manual only and User-invocable.

Most shipped skills leave both unset, so /skill-name works for the skills that opted in, not for every skill in the library. If a name does not autocomplete, that skill is an auto-invoked one: describe the task instead and let the description do its job.

A third, hand-authored option exists for heavier work: context: fork runs the skill in its own isolated context and returns only its result, which keeps a long investigation from filling the session that asked for it. The create dialog does not expose it — you add the line yourself.

Browse and inspect

The view is three panes:

• Left — a card per skill: its name and the first line of its description.
• Middle — the skill folder's file tree, with SKILL.md pinned at the top. Sibling reference files, templates, and assets are all visible here; a skill is its whole folder, not just the entry file.
• Right — the editor. Markdown files open with a rendered/raw toggle; other files open directly for editing.

Reading a skill top-to-bottom is the reliable way to know exactly what an agent will do when it invokes it.

Edit a skill

1. Select the skill, pick the file (start with SKILL.md), switch to edit mode.
2. Make your change — tighten a rule, fix a step, extend a reference file.
3. Save. That is the entire deploy: the next /name invocation or auto-match reads the updated file. No restart anywhere.

You can also add a new file inside a skill from the middle pane — the standard move when SKILL.md grows too long and detail belongs in a sibling reference file. Deleting a file or a whole skill moves it to the system trash, so mistakes here are recoverable. Do not carry that expectation next door: deleting an agent is permanent.

Create a skill

Two paths, depending on how much help you want:

The Create/Clone dialog (the + New skill button, or Clone on an existing skill) scaffolds the folder and a valid SKILL.md frontmatter for you — you write the content. It validates the frontmatter as you go, offers the two invocation checkboxes described above, and can scaffold sibling reference, example, and script files. The created skill opens in the view, live immediately. Cloning a proven skill and editing it is the fastest route to a working custom skill.

The skill-builder skill (/skill-builder in any session) is the assisted route: it interviews you — goal, trigger, auto vs. manual, workflow, reference files, guardrails — and then designs and writes a complete, production-quality skill for you, sibling files included.

Whichever path you take, three authoring rules pay off:

1. Invest in the description. State what the skill does, when to use it, and when not to — including pointing to a sibling skill when one covers an adjacent case. This is what makes auto-invocation land on the right skill.
2. Keep SKILL.md lean. Move detailed references, mappings, and templates into sibling files the skill points at.
3. Add explicit rules. A short block of hard constraints ("always X, never Y") does more for output quality than paragraphs of prose.

One formatting rule shared with agents: the frontmatter is strict YAML — inside a description value, write — (a dash) rather than a colon followed by a space.

Skills, agents, and protocols

The three doctrine layers divide cleanly: an agent is who does a job (an identity with tools and a model), a skill is how a specific kind of task is done (a reusable procedure any agent can load), and a protocol is a standing rulebook multiple agents obey — browsable and editable in the Protocols view, covered under Doctrine & protocols. All three are hot-reloaded Markdown — improving your system is editing files, never redeploying software.

Where to go next

• The skills catalog — every shipped skill and what it is for
• Agents — the roster that invokes these skills
• Doctrine & protocols — the corpus and the Protocols view
• The operator model — the file-based competence model skills belong to