Claude Code Skills Worth Actually Installing

In short

A Claude Code skill is a folder with a SKILL.md file: YAML frontmatter that tells Claude when to use it, and markdown instructions it follows when invoked. Personal skills live in ~/.claude/skills/<name>/SKILL.md, project skills in .claude/skills/<name>/SKILL.md, and plugins bundle them under a plugin:skill namespace. Custom commands have been merged into skills, so .claude/commands/deploy.md and .claude/skills/deploy/SKILL.md both give you /deploy. The catch nobody mentions in the "12 best skills" listicles: every installed skill's description sits in your context permanently, and once a skill is invoked its whole body stays in the conversation for the rest of the session. Installing thirty skills is not free — it's a standing tax on the context window you're already fighting for. The skills worth keeping are the ones that encode a procedure you'd otherwise paste by hand, not the ones that rename a prompt. As of July 2026.

What a skill is, and how it differs from a prompt or an MCP server

The official docs put it plainly: create a skill when you keep pasting the same instructions or checklist into chat, or when a section of CLAUDE.md has grown from a fact into a procedure. The difference from CLAUDE.md is loading behaviour — memory content is always in context, a skill's body loads only when it's used.

People conflate four different mechanisms. They do different jobs:

The line that matters: a skill cannot give Claude a capability it doesn't have. It can't reach your Jira, query your warehouse, or call an API — that's what an MCP server is for. A skill changes how Claude uses the tools it already has. If a "skill" you're evaluating promises integration with an external service, it's either wrapping a CLI you must install separately or it's marketing.

Skills follow the Agent Skills open standard, so the same folder works across several agents. Claude Code extends it with invocation control, subagent execution and dynamic context injection.

How to install one

Three routes, in descending order of how much you should trust them:

1. Bundled. You already have /code-review, /verify and /debug. Since v2.1.215 /verify and /code-review run only when you invoke them, so they don't quietly spend tokens.
2. Plugin marketplace. /plugin marketplace add anthropics/skills, then /plugin install example-skills@anthropic-agent-skills. Plugin skills are namespaced plugin:skill, so they can't collide with yours.
3. By hand. mkdir -p ~/.claude/skills/my-skill and drop in a SKILL.md. Claude Code watches these directories and picks up edits within the session — but creating a top-level skills directory that didn't exist at startup requires a restart.

Two gotchas worth knowing before you build a workflow on skills. Name collisions resolve enterprise → personal → project, and a project-level code-review skill silently replaces the bundled one. And Cowork sessions, cloud sessions and scheduled routines don't read ~/.claude/skills/ from your machine at all — a personal-only skill will report as not found when a routine tries to invoke it. Commit it to the repo or ship it in a plugin.

The skills that earned their place

Not a top-12. Four things I'd actually keep installed, with what's wrong with each.

The bundled ones. /code-review on a diff before you commit is the highest-value skill most people never invoke, and it costs nothing to keep. Start here before installing anything.

anthropics/skills — Anthropic's own collection. The document skills (pdf, docx, pptx, xlsx) are genuinely useful if you generate files, and they're the reference implementation for how a skill should be structured. Honest caveat: those four are source-available, not open source. The example skills are Apache 2.0. Check the licence before you fork one into a client project.

kepano/obsidian-skills — five MIT skills from Obsidian's CEO covering Obsidian-flavoured markdown, .base files, JSON Canvas and vault CLI access, plus defuddle for pulling clean markdown out of web pages. Narrow by design, which is exactly why it works: it encodes syntax rules Claude otherwise guesses at. Useless if you don't use Obsidian. We track it in our arsenal card.

ponytail — MIT, and the most interesting one conceptually. It makes the agent walk a ladder before writing code: does this need to exist, is it already in the codebase, does the stdlib do it, is it a native platform feature, is it in an installed dependency, is it one line — and only then write the minimum. Less output means fewer tokens and less to review. It also fights you when you genuinely do want scaffolding, and its effect is a nudge, not a guarantee. Card here.

Everything else in our skills section I'd install one at a time and remove if unused within a week.

How to tell a useful skill from a wrapper

Most published skills are a prompt in a folder. Here's the test, and it's mechanical rather than aesthetic:

• Does it survive being invoked twice? A skill whose entire content is "you are an expert X, be thorough" adds nothing a good request doesn't. If the body has no branching, no checklist and no file references, it's a wrapper.
• Does it encode something you'd have to look up? Syntax rules, an internal API's conventions, a deploy sequence, a review checklist you keep forgetting item four of. That's the sweet spot.
• Is the body short? Once invoked, the rendered SKILL.md enters the conversation as a message and stays for the whole session — Claude Code doesn't re-read the file on later turns. Every line is a recurring cost. A 400-line skill is a 400-line permanent tax.
• Is the description tight? Descriptions of installed skills sit in context so Claude knows what's available, and the combined description plus when_to_use text is truncated at 1,536 characters in the listing. Thirty installed skills means thirty descriptions competing for attention — and mis-triggered skills are worse than absent ones.
• What does it grant itself? allowed-tools in the frontmatter pre-approves tools for the turn that invokes the skill. For project skills this takes effect once you accept the workspace trust dialog. A skill checked into a repo you cloned can grant itself broad tool access. Read SKILL.md before trusting an unfamiliar repository — this is the part every listicle skips.

One more piece of arithmetic: after auto-compaction, Claude Code re-attaches the most recent invocation of each skill, keeping the first 5,000 tokens of each within a combined 25,000-token budget, filling from most recent. Invoke many skills in a long session and the early ones silently vanish. If a skill's rules must hold for the whole task, they belong in CLAUDE.md, not in a skill you invoked an hour ago.

Writing your own in an afternoon

The format is small enough to learn in one sitting:

---
name: summarize-changes
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed or wants a commit message.
allowed-tools: Bash(git diff *) Bash(git status *)
---

Below the frontmatter, write the instructions as standing rules rather than a one-time narration. Useful fields beyond the basics: disable-model-invocation: true for anything you only want triggered by hand, paths to activate a skill only when working with matching files, context: fork to run it in a subagent so its output never touches your main context, and ${CLAUDE_SKILL_DIR} to reference bundled scripts regardless of where the skill is installed.

Start with the thing you paste most often this week. Write it as a project skill in .claude/skills/, use it for a few days, delete the lines that never fired. That editing pass is the whole craft — the rest of the setup is one mkdir. For a wider view of what to pair skills with, our Claude Code CLI stack covers the tooling side.

FAQ

What are Claude Code skills?

Folders containing a SKILL.md file — YAML frontmatter describing when the skill applies, plus markdown instructions Claude follows. Claude loads one automatically when your request matches the description, or you invoke it directly with /skill-name.

How do I install a Claude Code skill?

Three ways: install a plugin that bundles it (/plugin marketplace add <repo> then /plugin install <name>), or create ~/.claude/skills/<name>/SKILL.md for a personal skill available everywhere, or .claude/skills/<name>/SKILL.md for a project skill that travels with the repo. Edits are picked up live; a brand-new top-level skills directory needs a restart.

What's the difference between a skill and an MCP server?

A skill is instructions — it changes how Claude works with tools it already has. An MCP server adds actual tools and connections to external systems. If you need Claude to read your database, that's MCP. If you need Claude to follow your deploy checklist, that's a skill.

Are Claude Code skills free?

The mechanism is built into Claude Code, and most published skills are MIT or Apache 2.0. The real cost is context: descriptions of every installed skill stay in your window, and an invoked skill's body persists for the session. Install selectively.

Is it safe to install skills from GitHub?

Treat them like any code you clone. A SKILL.md can pre-approve tools via allowed-tools, and for project skills that takes effect once you accept the workspace trust dialog. Read the file first — it's usually under 100 lines, so there's no excuse not to.