I've spent the past couple of weeks installing public Claude Code skills to see which ones held up, and I've deleted most of them. Not because they were badly written, and not because the idea is wrong, but because a skill that restates what the model already does well is a tax you pay on every session for nothing. The listicles won't tell you this, they'll give you thirty entries with a stale GitHub star count and a paragraph of enthusiasm each, and none of them tell you what happened when the skill was actually installed alongside twenty others in a real project.

Someone else did the work properly. Mikhail Shcheglov installed all 47 skills from a popular collection, tested each against vanilla Claude Code output, and found that forty of them made the output worse. He went further, going through 200+ skills across dozens of repositories, and his conclusion was that most publicly available skills don't just fail to help, they actively hurt, adding tokens, adding latency and injecting constraints that narrow the output. That matches what I found, and it matches what Anthropic have said about their own internal use in Lessons from building Claude Code: how we use skills: verification skills have had the most measurable impact on Claude's output quality internally, and it can be worth having an engineer spend a week just making your verification skills excellent.

Verification skills, not the design skills or the document skills or the productivity skills that fill the top of every ranking, but the thing that checks the work. That's the single most useful sentence anyone has published about skills and almost nobody is quoting it.

This article is about public skills, the ones you can install from a marketplace or a GitHub repo in thirty seconds. Custom skills you write yourself are a completely different proposition and in my experience far more valuable, but only if you build them properly, which I get into further down. The public list is short.

What a Claude Code skill actually is

A skill is a folder with a SKILL.md file in it. The file has YAML frontmatter with a name and a description, and below that, plain Markdown instructions. Optionally it ships references/, scripts/, assets/ and evals/ alongside. That's the whole format. Anthropic describe them as organised folders of instructions, scripts and resources that agents can discover and load dynamically, and they launched in October 2025.

The mechanism that makes them interesting is progressive disclosure. At session start Claude reads only the name and description of each installed skill, roughly 50 tokens each depending on whose numbers you believe, and Firecrawl say closer to 100. When a request matches, the full SKILL.md loads, around 500 tokens. Bundled reference files load only when something explicitly references them, and those can run to thousands. So a skill is cheap when idle and only costs you real context when it fires.

Where they live:

• ~/.claude/skills/<name>/SKILL.md for personal skills available across every project
• .claude/skills/<name>/SKILL.md for project skills, committed to git and shared with anyone who clones
• Plugin-bundled skills, namespaced and invoked as /plugin-name:skill-name

The directory name becomes the slash command. Custom slash commands have now merged into skills entirely, so .claude/commands/deploy.md and .claude/skills/deploy/SKILL.md both give you /deploy, legacy commands still work, and skills win on a name conflict. Agent Skills is also a published open standard, so the same folder works across Claude Code, the Claude apps, Cowork, the API, and per Firecrawl also Codex CLI, Cursor, Gemini CLI and GitHub Copilot.

Skills, subagents, hooks and MCP

Most of the confusion I see isn't about what a skill is, it's about which primitive to reach for, and picking the wrong one is how you end up with a skill that silently does nothing.

• CLAUDE.md is always-on project context. Rules Claude always knows, loaded in full, every session.
• A skill is an on-demand procedure loaded when a task matches the description.
• A subagent is an isolated context window for parallel or heavy work, which is what you want when the problem is context pollution rather than missing knowledge. I went through this in detail in Claude Code agents and subagents.
• A hook is deterministic code that runs on a lifecycle event. The best framing of the difference I've read comes from shiplight: a skill is instruction the model interprets, a hook is code that executes, and a model can be talked out of an instruction but it can't talk its way past a hook. If you need a guarantee rather than a suggestion, you want hooks, not a skill.
• An MCP server gives the agent a capability it doesn't otherwise have, a browser, a database, a test runner. Skills teach an agent how to use what it already has.
• A plugin is a versioned bundle shipping any mix of the above.

The compression I keep coming back to, credited to a developer called Moeed: skills are knowledge, MCP servers are actions, subagents are isolation, hooks are guarantees.

How I judge whether a public skill is worth installing

There's a two-type split that Firecrawl use, originally from Nate Herk, and it's the most useful lens I've found. A skill is either capability uplift, meaning Claude couldn't do the thing before, or encoded preference, meaning Claude could do it but the skill captures your specific way of doing it.

Capability uplift skills are doomed by the next model release. The base model catches up, the skill stops adding anything, and the SKILL.md becomes a token tax you're still paying. Encoded preference skills survive indefinitely, because no model update is ever going to teach Claude your team's commit format or your review checklist or the three things your migrations always get wrong. That distinction has done more to clean up my installed set than anything else I've read.

So when I look at a public skill now I ask which of the two it is, and if it's capability uplift I ask how long that gap is likely to last. Most of the ones I deleted were capability uplift skills that the model had already absorbed.

The second filter is the one Anthropic point at. Does the skill define success criteria the model doesn't know to care about? Shcheglov's example is a meeting reschedule, where the model will happily move the meeting and quietly drop the participants, the agenda, the video link and the duration, because nobody told it those mattered. A skill that encodes what "done properly" means is worth its context, and a skill that says "you are an expert Python developer, write clean code" isn't.

The public skills that are worth it

Star counts here are as of early August 2026 and they move fast, so treat them as directional. Most guides currently running are badly stale on this, with Superpowers cited at 40.9k in several of the top-ranking articles when it's well past 260k.

Superpowers (obra), roughly 265k stars. Jesse Vincent's framework is the one community package I'd install on a new machine without thinking about it. It bundles TDD enforcement, Socratic brainstorming, git worktrees, a four-phase systematic debugging process, code review and subagent isolation, with /superpowers:brainstorm, /write-plan and /execute-plan as the entry points. It's mostly encoded preference and process, which is why it's aged well. Install with /plugin marketplace add obra/superpowers-marketplace then /plugin install superpowers@superpowers-marketplace.

The Anthropic document skills, docx, pdf, pptx and xlsx. These power file creation in Claude.ai and they're source-available rather than open source. They're genuine capability uplift and they do work, with an honest caveat: practitioner testing found docx clearly improved output and pptx was good if you have no design sense, but xlsx showed no harm and no significant difference either. Install the bundle with /plugin install document-skills@anthropic-agent-skills.

webapp-testing, the Playwright skill from Anthropic's skills repo. Testing is verification, which is the category Anthropic themselves say has the most measurable impact, and this is the closest thing in the official set to a verification skill you can install rather than write.

skill-creator, which got a significant upgrade. Version 2.0 ships automatic eval generation, a benchmark mode that tracks eval pass rate, elapsed time and token usage, parallel multi-agent eval runs in clean contexts, and blind A/B comparator agents that compare skill against no-skill. That last feature is the reason to install it, because it turns "I think this skill helps" into a number.

The Karpathy guidelines skill, around 199k stars, is a single set of behavioural rules encoding Think Before Coding, Simplicity First, Surgical Changes and Goal-Driven Execution. It's pure encoded preference and it costs almost nothing. Whether you want it depends entirely on whether those four rules match how you work, and for me they mostly do.

That's the list, five entries, one of which is a bundle, and everything else I'd call situational.

Situational

Firecrawl's own skill if you scrape regularly, with the obvious note that it appears at number one in Firecrawl's own ranking of best skills, which tells you something about how those rankings get built. The three Vercel skills (Web Design Guidelines with 100+ accessibility rules, React Best Practices with 57, Composition Patterns) if you do frontend work. Trail of Bits Security, which wraps CodeQL and Semgrep, if you ship anything security sensitive. Handoff and Grill Me, both from Matt Pocock, for session handoff and for having your plan relentlessly interrogated before you commit to it. Caveman, which claims to cut output tokens by about 65% on average, if token spend is a real constraint for you.

The ones I deleted

Anything that's a prompt in a folder. If the entire SKILL.md is a persona instruction and a list of adjectives, it isn't doing anything a sentence in your CLAUDE.md wouldn't do, and it's competing for attention with the skills that are.

Anything vague enough that I couldn't predict when it would fire. This turns out to be a measurable problem rather than an aesthetic one. Three independent studies found the same failure: Vercel measured 56% non-invocation, Villega found a 50% success rate, and Seleznov's study with 650 samples found 77% activation. No error, no warning, nothing in the log, the skill simply doesn't trigger and you never know. Seleznov's fix is worth knowing, since directive-style descriptions ("ALWAYS invoke this skill when… Do not X directly") got to 100% activation against 37% for the passive style Anthropic's own docs suggest, an odds ratio of 20.6 at p<0.0001. Vercel's own finding from January 2026 is more uncomfortable, where an 8KB AGENTS.md documentation index hit 100% across build, lint and test while their skills stayed uninvoked in 56% of cases.

There's a second, nastier failure mode that Marc Bara describes well. Activation failure you can at least see in the session log, and execution failure is when the skill fires and Claude skips steps inside it, which is invisible.

And anything unvetted from a public hub, which I cover in the security section below.

MacAgentBench puts numbers on all of this. On skill-covered tasks the skilled agent reached 89.4% against 55.9% for baseline, which is a large gain, but on tasks without skill coverage the advantage largely disappeared, and for five of eight models the skilled agent actually underperformed baseline. Skills help precisely where they're scoped and add noise everywhere else, which is the single strongest argument for keeping the installed set small.

The built-in skills you already have

Almost every listicle skips this entirely. Claude Code ships with /review, /simplify, /loop, /batch, /debug and /claude-api already available, no install, no marketplace, no vetting. Working through those properly is a better first week than installing a pile of external skills, and I'd go further and say that if you haven't hit a real limitation with the built-ins, you don't yet know what you'd be installing a skill to fix.

Custom skills are where the value actually is

Everything above is about public skills, and the honest summary of public skills is that a handful are good and the rest are noise. Custom skills are a different story. The ones that have earned permanent space in my setup are all ones I wrote, and they're all encoded preference: the shape of a Go service in my projects, what a migration has to include before it's considered done, the specific verification steps that catch the failures I actually hit rather than the ones a generic reviewer imagines.

Write the description in third person, because it's injected into the system prompt and mixed point of view measurably hurts discovery. Make the description state what the skill does and when to use it, as a trigger rather than a summary. "Use when writing a git commit message for staged changes" fires reliably, "helps with git" doesn't. Front-load it too, because the listing description gets truncated at 250 characters.

Build the evals before you write the instructions. Anthropic's own loop is identify the gap, build three eval scenarios, establish a baseline, write minimal instructions, then iterate against the baseline. Daniel Sogl's line on this is the one I'd put on a wall: skills without evals are just markdown and hope. The caveat from Anthropic's own writing on evals is that an eval saturated at 100% tracks regressions but gives you no signal for improvement, so it needs to be hard enough to fail sometimes.

Keep the SKILL.md lean and push detail into reference files, one skill one job, examples over rules, and put real effort into the Gotchas section because that's the highest-signal content in the whole file. Gotchas come from your actual failures, which is exactly the knowledge no base model has.

Skills can also bundle hooks that activate only when the skill is invoked, which is how you get a /careful mode that blocks rm -rf, DROP TABLE and force pushes for the duration of a risky task. That combination, an instruction the model follows plus code it can't argue with, is the most reliable pattern I've found.

One practical detail that catches people: skills load at session start only. There's no /reload-skills, so restart or use /reload-plugins, and deleting a skill mid-session doesn't take effect until you restart. To disable one without removing it, rename SKILL.md to SKILL.md.disabled.

The problem that shows up the moment a custom skill is actually good is distribution. A skill that encodes how your team does migrations is worth having on every machine, and the default answer is that someone pastes it into a Slack thread and half the team has version one while the other half has version three and nobody knows which is which. Version control the .claude/skills/ directory at minimum. Past a certain team size you want something that tracks which version is approved and who approved it, which is the gap I've been building for.

How many is too many

Progressive disclosure means the raw install count isn't directly the problem, but it isn't free either. With too many skills Claude spends more attention deciding which skill a task needs, and match precision degrades. There's also a hard wall. As of Claude Code 2.0.70 the combined skill and command description budget defaults to 15,000 characters, roughly 4,000 tokens, and when you exceed it skills are silently dropped from the listing and Claude is told never to use skills it hasn't been shown. Jesse Vincent documented this and the workaround is SLASH_COMMAND_TOOL_CHAR_BUDGET=30000. Run /doctor to see whether you're overflowing, and note that the least-invoked skills' descriptions get dropped first.

A bare "hi" already consumes around 31,000 tokens of fixed overhead, and a 20k-token skill file is 10% of a 200k window gone before a single line of code is read. This is the same problem I built Cont3xt to solve for project context, and it applies just as directly to skills: the question is never how much context you can load, it's how little you can get away with loading at any given moment.

The rule I'd give someone starting out is that most people need a CLAUDE.md, one or two skills and a single MCP connection. Install as few as clear the description budget with room to spare, and pick for encoded-preference durability rather than for the demo.

Security, and why installing a skill is a trust decision

A skill inherits the full permissions of the agent running it. Shell access, filesystem read and write, whatever credentials sit in your environment variables and config, the ability to send email or Slack messages if those connections exist, and persistence through memory. The barrier to publishing a skill on a public hub is a SKILL.md file and a GitHub account that's a week old. No code signing, no security review, no sandbox by default.

Snyk audited 3,984 skills across public hubs in February 2026 and the numbers aren't comfortable. 36.82% carried at least one flaw of any severity. 13.4%, which is 534 skills, contained critical-level security issues. 76 had confirmed malicious payloads, eight of which were still live at publication. 91% of the malicious ones combined prompt injection with traditional malware. Their own summary is that if you installed a skill in the past month there's roughly a 13% chance it contains a critical security flaw.

The attacks are already happening. ClawHavoc was the first coordinated malware campaign targeting Claude Code and OpenClaw, with Bitdefender identifying 14 malicious actors on one hub and a single user submitting 199 malicious skills at a rate of one every few minutes via automation. Datadog documented a skill posing as a usage leaderboard that abused dynamic context commands executing before model-level prompt injection defences engage, with the model announcing it wouldn't execute the skill after it already had. A published exploit shows skill chaining, where a benign code-review skill with allowed-tools: [Read, Bash] gets hijacked by a repository's own config file into sourcing .env, because skills define tool types but not tool targets. Daily submissions to one hub went from under 50 in mid-January 2026 to over 500 by early February, and volume like that doesn't come with review capacity attached.

Having spent years in payments where every third-party integration went through a formal review before it touched anything, watching an ecosystem run at this velocity with no vetting layer is familiar in an uncomfortable way. The failure mode is the same one I wrote about in what actually goes wrong when you give AI agents production access, where the permission was granted once, casually, for a narrow reason, and then used for something else entirely.

What vetting looks like in practice isn't complicated. Read everything in the skill directory rather than just the SKILL.md, because the scripts are where the interesting behaviour lives, and treat it as a code review because that's what it is. Test in isolation and watch the network traffic, since any outbound call is a potential exfiltration path. Red flag phrases to grep for: "ignore previous instructions", "do not mention", "do not show the user", anything conditional on who is asking, and curl | bash anywhere in an install step. For a team, keep a registry with version, owner, purpose and review date, re-review on update, and make sure the person approving isn't the person who wrote it.

That last part is where it falls over in practice, and it's the reason I've been building Vettory. One person reading a SKILL.md carefully is fine, and fifty people pasting skills out of blog posts into fifty laptops, with security asking who can run what and the honest answer being a shrug, isn't. Vettory is an approval and distribution layer, so a skill gets scanned and reviewed by someone who didn't write it before anyone can install it, every version is snapshotted, and every install, approval and revocation is logged with actor and timestamp. Team members say "update my skills" in whichever agent they already use and get the approved set, and lose it automatically when their access changes. The thing I'd say about it that isn't in the marketing copy is that scanning and review reduce risk without eliminating it, and a governance layer mostly buys you the ability to answer the question rather than the ability to promise nothing bad happened.

For a solo developer none of that is necessary and I wouldn't pretend otherwise. Read the directory yourself and keep the installed set small enough that reading it is a realistic thing to do.

On the tooling side, allowed-tools in the frontmatter narrows what a skill can reach, .claude/settings.json gives you a shared deny list which should include .env alongside the obvious network and deploy commands, and PreToolUse hooks block regardless of what the allow list says. Anthropic do run permission prompts, context-aware analysis and input sanitisation, and curl and wget aren't auto-approved by default, but their own repository README says it plainly: test skills thoroughly in your own environment before relying on them.

Conclusion

Five public skills, a handful of custom ones I wrote and can point at evals for, and the built-in commands doing more work than any of them. How I decide now comes down to whether the skill encodes something a model update will never learn, whether it defines success criteria the model doesn't already care about, and whether I've read every file in the directory, and most public skills fail at least one of those.

If you want a starting point rather than a verdict, install nothing for a week, use /review and /debug properly, and write down every point where Claude got something wrong in a way that was specific to your codebase. That list is your first custom skill, and it'll be worth more than the thirty you were about to install.