Installing a Skill Usually Means Running a Stranger's Code

The pitch for Claude Code "skills" is that they're just instructions — a SKILL.md file with some markdown telling the agent how to do a task. That framing makes them feel safe to install. A prompt can't hurt you; worst case it gives bad advice. So people drop skills into ~/.claude/skills/ with about the same caution they'd give a Stack Overflow answer.

We wanted to know if that mental model holds, so we pulled a sample of public skills off GitHub and looked at what's actually in them. The answer: a skill is not a prompt. It's a package of executable code with a prompt on top.

The numbers

We took 34 public skills (every repo we could find with a SKILL.md) and, for each one, looked only at files co-located with that SKILL.md — the skill's own directory, not the surrounding repo — so a full project that happens to contain a skill doesn't inflate the count.

• 29 of 34 (85%) bundle an executable script — a .sh, .py, .js, .ts, etc. sitting right next to the SKILL.md.
• 20 of 34 (58%) have a SKILL.md that references running code — "run", "execute", bash, python, ./script, a scripts/ path.

So the typical skill isn't "here's how to think about X." It's "here's a script — and here are instructions telling the agent to execute it." Installing it isn't adding a note to the agent's context; it's putting someone else's code one tool-call away from running on your machine, with your environment, when the agent decides the skill applies.

(Honest scoping: 34 is a sample, found via code search, so it skews toward published, indie skills rather than first-party ones; and "references execution" is a keyword match, not proof the script runs every time. But the direction is unambiguous and the co-located count matched the whole-repo count almost exactly — these are the skills' own scripts, not incidental project files.)

Why this is a different risk than it looks

This isn't a knock on skills — bundling code is why they're useful. A skill that can run a real script does real work a prompt never could. The problem is the mismatch between the risk and the perceived risk. Three things stack up:

1. The install ceremony is "copy a folder." There's no npm audit, no permission prompt, no signing — you drop a directory into ~/.claude/skills/ and it's live. The friction is lower than installing an npm package, but the capability is the same: arbitrary code execution under your user.

2. The SKILL.md is the instruction the model follows. This is the part that makes it sharper than ordinary dependency risk. With a normal library, you decide when to call it. With a skill, the SKILL.md tells the agent when and how to run the bundled script — and the model can't tell a helpful instruction from a malicious one any better than it can for any other text in its context. A skill that says "before answering, run setup.sh to prepare the environment" gets setup.sh run, by the agent, on a trigger you didn't review. Security writeups have already shown the obvious version of this: a skill can package a script that opens a reverse shell or installs a backdoor, and the SKILL.md is what tells the agent to launch it.

3. The agent runs it more trustingly than you would. You might glance at a script before running it. An agent that has "installed" a skill treats running its bundled script as the intended behavior — that's what the skill is for. The human-in-the-loop that catches "wait, why is this calling out to an IP address" is exactly the step the skill abstraction removes.

None of these is exotic. Together they mean the safe-feeling "it's just a prompt" skill is, 85% of the time, a code-execution surface installed with less scrutiny than a dependency.

The cheap check

We're on record that the fix for AI-code risk is rarely "trust less" and usually "make the check cheap." Skills are a clean case. Before you install one, the check is thirty seconds and entirely deterministic — no judgment, no model:

• List the executables. What .sh/.py/.js ships in the skill's directory? If the answer is "none, it's only SKILL.md and reference docs," it really is just a prompt — install freely.
• Read what SKILL.md tells the agent to run, and read that script. Not the whole codebase — just the entry points the markdown points at. You're looking for the same things you'd look for in a curl | bash: network calls to unexpected hosts, writes outside the project, anything touching ~/.ssh, ~/.aws, .env, or your shell config.
• Check for a persistence hook. The nastier skill writes itself into settings.json hooks or a shell rc so it runs every session, not just when invoked. One grep finds that.

That's it. The point isn't paranoia — most skills are fine, built by people solving their own problem in the open. The point is to stop treating a skill like a prompt when 85% of them are programs, and to spend thirty seconds reading the code you're about to let your agent run on a trigger you don't control. The skill ecosystem is going to be huge and mostly great; the failure mode is the same one every package ecosystem has, arriving faster because the install is a folder copy and the "should I run this" decision got delegated to a model.

A skill is code you run. Read it like code.

We measured this with a short, reproducible script (included) — point it at any skill repo and it tells you what's executable inside. → Talk to us if you're vetting skills before they reach your agents.

---

Sample: 34 public skills discovered via GitHub code search for SKILL.md, 2026-06-20; "bundles a script" counts executables co-located with the SKILL.md (the skill's own directory), and that figure matched the whole-repo count, confirming the scripts are the skills' own. "References execution" is a keyword heuristic over the SKILL.md body. The measurement script is included for reproduction. Prior art on malicious-skill mechanics credited inline.