The install pattern

Writing a skill file is half the work. The other half is making it loadable — by you, by colleagues, and by any Claude instance without manual copy-paste. The install pattern is how that happens.

What this actually is

The install pattern is the mechanism by which a skill file moves from a registry into Claude's context window. When you run npx skills add deploy-gh-pages, three things happen: the registry fetches the skill file, validates the frontmatter, and injects the file into Claude's system prompt before your next message.

From that point forward, Claude knows the procedure as if you had pasted the entire file into the conversation yourself. The difference is that the injection is automatic, versioned, and reproducible.

Walk-through

Installing a skill from the registry:

# Install the latest version
npx skills add deploy-gh-pages

# # → Installing deploy-gh-pages@1.2.0...
# # → Injecting into system prompt...
# # → Done. Skill deploy-gh-pages is now active.

Pinning to a specific version:

npx skills add deploy-gh-pages@1.0.0
# # → Installing deploy-gh-pages@1.0.0...

Listing installed skills:

npx skills list
# # → deploy-gh-pages@1.2.0 (active)
# # → run-tests@2.0.1 (active)

Updating to the latest version:

npx skills update deploy-gh-pages
# # → Updated deploy-gh-pages 1.0.0 → 1.2.0

How injection works

When the skill is injected, it appears in Claude's system prompt under a <skills> block. Claude reads this block at the beginning of every turn and uses it to answer the question: "Do I have a procedure for what the user is asking?"

If you ask Claude to "deploy the site," and deploy-gh-pages is installed with triggers: [deploy, ship, publish to github pages], Claude will recognize the trigger and offer to run the skill. You confirm, and it executes the steps.

This is why the triggers field in the frontmatter is not optional. Without triggers, Claude has to read the description of every installed skill on every turn to decide which one applies. With triggers, it can match quickly.

Versioning and the lock file

Skills use semantic versioning. 1.2.0 is the version you get if you do not pin. If a skill update breaks your workflow, pin to the last working version and open an issue with the skill maintainer.

When you pin skills in a project, the version constraints go in .skills.lock at the project root — the same pattern as package-lock.json. Check the lock file into version control so your team and your CI environment get the same versions.

// .skills.lock
{
  "deploy-gh-pages": "1.0.0",
  "run-tests": "2.0.1"
}

If you get stuck

If npx skills add returns "skill not found": check the registry slug against the name field in the frontmatter. The registry is case-sensitive and uses hyphens.

If a skill installs but Claude does not use it: check the triggers field. If no triggers match your natural language, add a trigger and republish, or invoke the skill explicitly: "Use the deploy-gh-pages skill to deploy the site."

If you need a skill available in every Claude session without installing it each time: add it to your user-level ~/.skills.rc file. Skills listed there are injected automatically.

Cross-reference

L5 (The Agent Skills format) covers the frontmatter fields — particularly name and triggers — that the install pattern depends on to function correctly.

Deliverable

Install one skill you have written (or a public skill from the registry) and verify it is active. Then ask Claude to execute the procedure using only natural language that matches one of the skill's triggers — do not name the skill explicitly. The success criterion: Claude recognizes the trigger and offers to run the skill without being told which skill to use.