Read public agent skills before your coding agent runs them
I audited 257 agent skills in three trending repos. None runs shell commands on load, but bulk installs stop the right skill firing.
Senior Full-Stack Engineer- Published
- 7 minReading time
- Artificial IntelligenceCategory
Listen to this post· AI-narrated
0:00 / 7:48Three agent skills repos sit on GitHub's weekly trending list right now. Matt Pocock's skills (opens in a new tab) gained 9,575 stars this week, Anthropic's (opens in a new tab) 5,738 and Google's (opens in a new tab) 2,013. Each installs into Claude Code with one command, so the obvious move is to add all three and let your coding agent pick what it needs. I cloned the three repos on 12 November and read what they would put in my agent: 257 skills, 311 bundled scripts and every line my greps flagged as able to run a command. They're cleaner than I expected. Installing all of them would still hide skills from my agent, for a reason that has nothing to do with security.
TL;DR: Public agent skills from the big repos barely use the features that run code without asking, but bulk installs overflow Claude Code's skill listing and stop the right skill from firing. Read each skill before you install it. Install vendors' skills for the products you use, and copy workflow skills into your own repo instead.
What does installing agent skills actually cost?
Agent skills cost almost nothing until your agent uses them, and that's the selling point. Anthropic's Agent Skills docs (opens in a new tab) put the always-loaded part, a skill's name and description, at about 100 tokens per skill. The body loads only when the skill fires, and should stay under 5k tokens.
The catch is the listing. Claude Code keeps every installed skill's name and description in context so the model can match your request to one, and that listing has a budget of 1% of the model's context window, per the docs (opens in a new tab). When it overflows, Claude Code drops descriptions, starting with the skills you invoke least. A skill that loses its description loses the keywords Claude matches your request against, so it rarely fires unless you call it by name.
Google's repo shows the scale. Its 198 skills carry 116,397 characters of names and descriptions by my count, about 29,000 tokens at a rough four characters a token. On a million-token model, 1% is 10,000 tokens. Install that whole repo and most of its descriptions never reach the model, and neither do the ones you installed last month and rarely use.
Two tools help. /doctor estimates what the listing costs you, and the skillOverrides setting in your Claude Code settings file can list a skill as "name-only", so it keeps its slash command without spending description budget.
What can a public skill run on your machine?
Three features in Claude Code's skill format (opens in a new tab) let a skill you downloaded run code with your permissions, some of it before you see what the skill does. A line written as !`command` runs the shell command before the skill's text reaches the model. An allowed-tools field lets the agent use the listed tools "without asking permission" for the turn that invokes the skill. And bundled scripts run instead of being read, with the same network access in Claude Code as any other program on your computer.
Anthropic's own advice is blunt: "Use Skills only from trusted sources: those you created yourself or obtained from Anthropic."
So I checked the three trending repos for those features. None of the 257 skills uses the pre-run shell syntax. Two set allowed-tools, both Google Cloud skills that grant terraform and gcloud, which is what you'd expect from a skill that writes alert configuration. Of the 311 bundled scripts, 40 contain a network call such as curl or fetch: 36 in Google's repo, 4 in Anthropic's and none in Matt Pocock's.
Registries are where the numbers change. In February, Snyk scanned 3,984 skills (opens in a new tab) from the ClawHub and skills.sh registries and found at least one security flaw in 36.82% of them, a critical issue in 13.4%, and 76 confirmed malicious payloads. In the top 100 skills on skills.sh, Snyk found no prompt injection and no malicious code. A skill from a big, maintained repo and a skill you found in a registry search aren't the same risk, and the install command looks identical for both.
How do you vet an agent skill before installing it?
Vetting an agent skill starts with a clone and three grep commands. These are the checks I ran on all three repos, and you can run them on any skill folder:
# Shell commands that run before the model sees the skill
grep -rnE '!`|^```!' --include=SKILL.md .
# Tools the skill can use without asking you
grep -rn '^allowed-tools:' --include=SKILL.md .
# Bundled scripts that can reach the network
grep -rlE 'curl |wget |fetch\(|requests\.|urllib|axios' --include=*.py --include=*.sh --include=*.js --include=*.ts .
Every hit needs reading. My first grep flagged two lines that turned out to be an Excel formula and a Rust doc comment. The greps also miss the subtler risk Snyk describes, plain instructions in SKILL.md that talk the agent into something the skill never mentions, so read the file itself too, start to finish.
Then read the description, because it decides when the skill fires. A vague description fires on the wrong requests, and a greedy one crowds out skills you wrote for your own repo.
Last, check the size. Claude Code's docs say to keep SKILL.md under 500 lines. Anthropic's own claude-api skill is 105,146 characters, which is fine for an API reference you load on purpose and a lot to land in context every time a description happens to match.
If you install skills you haven't read, set disableSkillShellExecution to true in your Claude Code settings. Pre-run commands then show a policy notice instead of running.
Should you install a skill or write your own?
The authors of these repos answer that themselves. Anthropic's README says its skills are "provided for demonstration and educational purposes only" and asks you to "Always test skills thoroughly in your own environment before relying on them for critical tasks." Matt Pocock's says his are "designed to be small, easy to adapt, and composable" and ends with "Make them your own."
I read that as two kinds of skill. The first is a vendor's skill for the vendor's own product: Google's Cloud skills if you deploy on Google Cloud, or the Claude API skill that ships with Claude Code. Install those, because the publisher knows the product and has a reason to update the skill when the product changes. The second is a workflow skill: how to triage issues, plan a feature or write tests. Read those and copy what fits into .claude/skills in your repo. Your agent follows a skill like a spec, and a workflow skill written for someone else's codebase points it at their folders and their test command.
Installing fewer skills fixes the listing problem. Copying the few you keep adds a second gain: three skills you adapted cost a fraction of the listing budget of Matt Pocock's 39-skill plugin, and their descriptions use your project's words, so they fire when you need them. The price is that you maintain them, which for a page of instructions about your own repo is a fair trade.
What to do this week
Run /doctor and look at the biggest contributors to your skill listing. If one of them is a whole skills repo you installed for a single skill, every other description in it is competing for the budget with the skills you use: uninstall it and copy the one skill into .claude/skills. Before your next install, clone the repo, run the three greps and read the SKILL.md you're about to load. My counts come from the repos as they stood on 12 November, so run the greps yourself before you trust mine.
I write about coding agents and the tools around them on the gabs.app blog. I'm a full-stack engineer and my work is on gabs.app; if you're hiring, the contact form comes straight to me.