SKILL.md Is the New package.json — Treat Your Skill Library Like the Supply Chain It Is

Your agent just installed a skill from a marketplace. Did anyone read it first?

A skill is a folder — a SKILL.md and, usually, some scripts it's allowed to run. It can read your files, call your tools, and reach the network, with your agent's permissions, not a sandbox's. It is, in every way that matters, unsigned executable third-party code. And most teams install it the way they'd star a repo: on vibes.

We spent fifteen years learning not to curl | bash a stranger's script — then handed our agents a marketplace and forgot the lesson.

We've seen this movie. It was called npm.

---

The supply chain you didn't know you had

package.json was never really a list of libraries. It was a list of people you decided to trust — most of whom you never met, whose code you never read, running with your build's privileges. We eventually grew up about it: signing, provenance, lockfiles, scanners, a whole decade of supply-chain hygiene.

SKILL.md is that same trust decision, made faster and with less ceremony. Each skill you add is a new dependency that ships behavior, not just data.

A skill isn't content. It's code with your agent's hands.

This isn't hypothetical anymore. OWASP just published the Agentic Skills Top 10 — the first real security framework for the skill layer. And the empirical work behind it isn't comforting: a study of tens of thousands of public skills found roughly a third carry security flaws, with malicious payloads confirmed live in the wild. The attack categories rhyme with everything we already know — prompt injection, data exfiltration, privilege escalation, supply-chain pull-through — just wearing a new file extension.

---

Why this is worse than the npm problem

npm at least had a head start: registries that sign, tools that scan, lockfiles that pin. The skill ecosystem has almost none of that yet. You're back in 2014, installing trust by reputation.

But the blast radius is the part that should keep you up. A malicious npm package runs at build time, in CI, against a checkout. A malicious skill runs at decision time — in production, holding your agent's live credentials, choosing what to do next with your data.

The dependency that scared you ran at build time. This one runs at decision time.

Same supply chain. Higher stakes, fewer guardrails.

---

What we do — and what you can take

We build and stamp our own skills into one canonical toolkit, and we treat that toolkit like the supply chain it is. Four practices, none of them exotic:

• Provenance. Skills come from one source we control and can audit — not ad-hoc installs from wherever. If you can't say where a skill came from, you don't own it; it owns you.
• Least-privilege scopes. A skill gets the narrowest capability it needs, never the agent's full hand. Most skills don't need the network. Most don't need write access. Make them prove it.
• Payload scanning. SKILL.md and its scripts are dependencies — scan them before they run, the same way you'd scan any package.
• Immutable manifests. Pin what's installed and diff it. A skill library you can't diff is a skill library you can't trust.

Map it onto the ROBOT framework and it's the same questions you'd ask of any agent: what is this skill allowed to be (Role), what are its Boundaries, and can you see what it actually did (Observability).

You don't have to out-engineer the attacker. You have to know what's in your own toolbox.

---

The three questions

A supply-chain program, stripped down, answers three things: what's installed, where did it come from, and what can it do. Ask them about your agent's skills right now. If you can't answer all three, you don't have a skill library — you have an attack surface with good intentions.

The agents are already running the skills. The only real choice is whether you're governing that, or hoping.