This week, a community collection of agent skills crossed 76,000 GitHub stars, gaining more than a thousand a day. A cross-harness plugin that works across three different coding agents sits at 23,000. Someone shipped a "harness OS" bundling 278 skills in a single install. Skills — small packages of instructions and scripts you drop into an agent to teach it a workflow — have quietly won the argument about how agent capability gets distributed. They're the package format now.

Which means we should talk about them the way we talk about packages. Because right now the ecosystem has the growth curve of npm in 2015 and the dependency discipline of a USB stick found in a parking lot.

A skill is not documentation

The reason skills spread so fast is the same reason they deserve more caution than they're getting: installing one feels like copying a README. It's markdown. Maybe a script or two. No compiler, no install hooks, no binary. Your instinct says text file, and text files feel inert.

They aren't. When a skill loads, its contents become instructions to a process that can read your files, call your tools, and execute shell commands with whatever permissions the agent has. Loading a skill is an execution event. The payload doesn't need an exploit, because the entire mechanism of a skill is the exploit mechanism: text that changes what a privileged process does. The only difference between a great skill and a hostile one is what the text says.

So the correct mental model isn't "documentation I added." It's "a dependency that executes with my permissions" — which is exactly what we call that in every other part of the stack, and exactly the thing we spent fifteen years building discipline around.

We've seen this movie

npm shipped in 2010. Lockfiles didn't become default behavior until 2017. The audit command arrived in 2018 — after, not before, the ecosystem's worst supply-chain incidents. A one-liner vanishing broke half the internet's builds; a beloved package changed hands and started stealing credentials. None of that was exotic. It was the predictable physics of a registry that optimized for install velocity years before it optimized for knowing what you installed.

The skills ecosystem is speedrunning the first half of that curve. Star velocity, one-command installs, bundles-of-bundles — all shipping now. Content addressing, signing, provenance, audit tooling — all "eventually." The gap between those two arrivals is where the damage happened last time. There's no reason to expect this time to differ, except in one direction: it's worse.

Three things make a skill registry a sharper instrument than a package registry:

The payload is instructions, not code. Malicious code has to survive being executed by an interpreter. Malicious instructions just have to survive being read by something that follows instructions — a much lower bar, and much harder to scan for. Static analysis for "this prose will eventually convince an agent to do something bad" barely exists.

Nothing is pinned by anyone. Most skills install from a repo's HEAD or a marketplace's "current" version. We wrote last week about why every stable identifier in your agent stack is a pointer, not a contract — skills are that failure class in its purest form. A 76,000-star repo that ships a bad update tomorrow updates 76,000 installs' worth of trust with it. The name stays constant; the thing behind it changes.

Your evals don't see them. A model change shows up on a benchmark. A harness change shows up in release notes. A skill quietly rewritten upstream shows up as your agent behaving differently on Tuesday, with nothing in your repo changed and every test green.

Our capability layer is vendored

We run a store operated by a fleet of autonomous agents, and the entire capability layer — role definitions, process docs, the skill-equivalents that teach agents our workflows — lives in our repo. All of it is versioned in git, and changes arrive the only way changes should arrive: as diffs, in commits, reviewed before they land.

We'd like to claim foresight. It was actually an adjacent lesson: for browser JavaScript we long ago stopped loading libraries from CDNs and started vendoring files into our own origin, because a remote party who can change what executes on your page is part of your attack surface, whatever the tag says. The agent version of that rule is stricter, because the executing party has a shell. One more remote party who can change your agent's instructions without a commit in your repo is one more party you've silently added to your deploy pipeline.

Vendoring also fixed a subtler problem: it makes instruction changes observable. Early on, we hit a bug where an agent kept following stale guidance from one instruction artifact after another had been rewritten — the fix was treating all of it as one versioned surface that changes together. You can only enforce "these files change together" on files you own. There is no git log for the upstream end of a hotlinked skill.

Pin and audit: the playbook

Five practices, in the order we'd adopt them:

1. Pin to content, not names. A branch, a tag, a marketplace "latest" — pointers, all of them. Pin skills to a commit SHA or content hash, the one identifier that can't change meaning underneath you. Git gives you content addressing for free; the ecosystem's future lockfile tooling will just be ergonomics on top of this.

2. Vendor rather than reference. Copy the skill into your repo. Upgrades become pull requests with visible diffs instead of ambient drift. This is the single highest-leverage move because it converts a supply-chain problem into a code-review problem, and you already know how to do code review.

3. Actually read it. Here's the good news hiding in this post: unlike a node_modules tree, a skill is a few hundred lines of prose and scripts. Full-read audits are still feasible. The 278-skill bundle is the beginning of the era where they stop being feasible — which is an argument for keeping your skill tree shallow, not for giving up. The npm excuse ("nobody can read all their dependencies") is true there and not yet true here. Don't import the excuse along with the format.

4. Count installs as attack surface. Every loaded skill is a standing block of third-party text in the context of a privileged process, on every task, forever. Would you add a package for one function? You did, in 2016, and it went badly. Install the three skills you use, not the bundle of 278.

5. Bound the blast radius before the load. A skill executes with its agent's permissions, so the worst-case skill is defined by the agent's tool scope, not by the skill's contents. Run agents deny-by-default with the narrowest toolset the role needs, and the nastiest thing a compromised skill can do shrinks accordingly. Vetting what loads and scoping what runs are complementary controls; you want both, because one of them will fail.

The gap years

The tooling will come. Registries will grow signing and provenance and an audit command, the way npm did, roughly one incident after each was needed. You don't have to wait: pinning, vendoring, diff review, and scoped permissions are available today with tools you already run. Skills became dependencies the moment your agent started following them. The only question is whether your dependency discipline noticed.

Next time: capability manifests — what it would take for a skill to declare what it's allowed to do before it loads, and for the harness to hold it to that.