Agent Skills Just Became a Package Ecosystem

Vercel’s skill packs let you bundle agent skills from local folders, zips, and public or private GitHub repositories into a single unlisted URL, install them with one command, and refresh them with another. Strip the branding and that is the shape of a package manager: a distribution surface, an install command, an update command. Package managers acquire supply-chain problems. Nothing here has been compromised — this is an argument for borrowing the hardening now, before the ecosystem has to learn it expensively.

The feature landed on August 7, 2026 in Vercel’s changelog, and it is a genuinely useful piece of plumbing. Teams have been passing around skill directories by hand for months; a pack turns a standardised set into a link you can send to one person or to a whole engineering org. The problem is not the feature. The problem is that the announcement, read end to end, contains no versioning scheme, no checksum, no signature verification and no provenance attestation — the exact set of controls the JavaScript ecosystem spent years bolting on after it needed them.

This piece covers what a skill pack actually is, why the distribution shape matters more than the file format, what verifies a pack today, how far a single compromised source could fan out given how the CLI is designed to be used, what npm’s own hardening history suggests about sequencing, and the concrete mitigations available right now — including the one Anthropic already ships two products away.

Vercel published skill packs on its changelog on August 7, 2026. The mechanics are short enough to state completely. You build a pack from community skills, your own local folders and zips, or public and private GitHub repositories. Every pack is unlisted and gets its own URL. You share that link with one person or a whole team. The recipient installs it with npx skills add pointed at the pack URL, and refreshes it later with npx skills update. Packs are built and browsed at skills.sh.

Underneath sits the npx skills CLI — the MIT-licensed vercel-labs/skills project — which does the resolving and installing. A skill in this world is a plain directory containing a SKILL.md file with YAML frontmatter carrying a required name and description. The CLI discovers those directories in standardised locations and walks catalogues up to three levels deep. If you have ever built one by hand, our walkthrough of building a skill from scratch covers what actually goes into the file and how to review it before it is shared.

Those three default limits are worth reading as what they are. A 10 MiB download that may expand to 25 MiB is a two-and-a-half-times expansion allowance — a zip-bomb guard and a disk-exhaustion guard, both sensible. They are resource limits. None of them inspects a single byte of what arrives, and all three are overridable by environment variable, which the README frames as something you do when you trust the source. Trust, in that sentence, is doing all the work.

Here is the distinction that keeps this argument honest. A SKILL.md file is markdown. It is instruction text an agent reads. It is not a postinstall script, it does not execute on install, and anyone claiming skill packs and npm packages are technically identical is overreaching in a way a technical reader will catch immediately.

The analogy is structural, not mechanical. What makes something a package ecosystem is not that its artefacts execute — it is that artefacts get authored by one party, distributed through a shared channel, installed by a second party who did not write them, and then updated in place by a command that fetches whatever the upstream has become since. Skill packs now have every one of those properties. The install command exists. The update command exists. The sharing surface exists and is deliberately frictionless. That is the ecosystem, and it arrived complete.

The reason the markdown-versus-code distinction does not rescue you is that agents have tools. Skills ship auxiliary scripts and reference files alongside the markdown, and an agent with shell access does what a skill instructs it to do. The execution boundary has not disappeared; it has moved from the package manager into the agent runtime, which is a place with far less mature tooling around it. That is also why the server-allowlisting and least-privilege guidance we wrote for MCP transfers almost unchanged to skill sources: in both cases you are deciding whose instructions your agent is permitted to obey.

Read that sentence as a distribution statement rather than a feature statement and the shape is unmistakable. Four heterogeneous source types across the CLI, normalised into one installable unit, addressed by one URL. Every package manager that has ever mattered started with exactly that sentence.

This is the observation the rest of the post rests on, so it is worth being precise about what is being claimed. The changelog post announcing skill packs makes no mention of a versioning scheme, signature verification, checksums or provenance attestation anywhere in its body. Searching the CLI README for the same terms returns nothing relevant either. That is a statement about the primary sources — an absence directly observed — not a claim that such controls are impossible, unplanned, or being withheld.

It is also not a claim of negligence. Vendors ship distribution before they ship verification all the time, because distribution is what users ask for and verification is what they ask for later. No source states why signing or provenance was not part of the initial release, and speculating about a roadmap would be inventing evidence the research does not contain. What can be said is narrower and more useful: as documented today, a skill pack is installed on the basis of the URL you were given and nothing else.

One further honest gap: whether skills.sh performs any server-side scanning or vetting of submitted packs before listing or sharing them is not stated on any page we fetched. We are not going to assume it does, and we are not going to assume it does not. It is undocumented, which is itself a useful thing for a platform team to know when writing policy — you cannot cite a control you cannot point at.

Three design decisions in the CLI are individually reasonable and collectively define how far a bad source could travel. First, breadth: the tool targets 75-plus distinct agent runtimes at the time of writing, each with its own project-level and global skill-directory convention — Claude Code reads .claude/skills/ and ~/.claude/skills/, Codex reads .agents/skills/ and ~/.codex/skills/, Cursor reads .agents/skills/ and ~/.cursor/skills/, and so on down a long table. Those are trusted-instruction directories. A wildcard agent target writes into many of them in one command.

Second, linkage: the interactive installer offers Symlink as the default and recommended method, with Copy as the alternative. Symlink creates a canonical copy that every target agent links to, which is elegant — one source of truth, one place to update. It also means a single compromised source propagates to every agent surface it is linked into the moment someone runs an update.

Third, automation: skills add ships a non-interactive mode via --all or -y, explicitly marketed as CI/CD friendly. A pack can be pulled into an automated pipeline with no human review step, by design. That is not a flaw — it is what CI requires. It does mean the human checkpoint has to be somewhere else, and if you have not decided where, it is nowhere.

The most useful thing about the JavaScript ecosystem’s supply-chain history is not the incidents — it is the sequencing. npm’s hardening was reactive rather than proactive at almost every step. The controls in npm 12 that block install scripts by default — an allowlist for postinstall, preinstall and install hooks, and a Git-dependency resolution default of none — shipped after the incidents that made them obviously necessary were already public, not before. The right lesson is not that npm was careless. It is that opt-in-by-default hardening is politically difficult to ship until something has gone wrong, and dramatically cheaper to ship before.

The same week skill packs launched, a self-propagating npm worm was reported to have targeted AI-tool configuration and credentials specifically — we covered that incident and its response in our piece on the npm package compromise, and the figures and mechanics belong there rather than here. The only thing worth carrying across is the timing: a distribution layer for agent instructions arrived in the same news cycle as a demonstration that attackers are now specifically interested in agent configuration.

One nuance matters and is easy to get wrong. npm’s provenance-attestation system — GitHub Actions plus OIDC signing, linking a published package to the build that produced it — exists and is generally available. It is a real control. The correct reading of the past week is not that provenance is broken or useless; it is that stolen or forged credentials can let a compromised release pass a signature check, which is an argument for defence in depth rather than a verdict on the mechanism. Provenance you have is worth a great deal more than provenance you do not, and skill packs currently have none documented at all.

This table is ours. No single source lays these columns out side by side — the Vercel changelog and the CLI README describe the tool in isolation, and npm’s hardening is documented separately in our own prior reporting. Assembling them together, with an explicit “none documented” column where that is the honest answer, is the point. Where a cell says none documented, it means exactly that: we searched the primary sources and found no such control described. It does not assert that no control exists behind the scenes.

Read down the third column and the pattern is the one that matters: every genuine control in that column is something you brought, not something the ecosystem supplied. Access control, review discipline, pipeline gates. Those are all real, and they are all the kind of control that degrades quietly the moment a team gets busy. The controls that survive busy teams are the ones enforced by tooling, which is precisely what is missing today.

None of this requires waiting for a vendor. The point of naming the gap precisely is that the compensating controls are ordinary engineering practice.

The governance layer is where this becomes an organisational question rather than a personal one. Platform teams already know how to constrain what an agent may connect to — GitHub’s enterprise managed settings now support MCP server allowlists for Copilot, which is the same instinct applied to a different edge of the same problem. Skill sources deserve the same treatment: an approved list, a named owner, and a review step before anything reaches a shared directory. The portable-skills standard now emerging across harnesses makes that easier and more urgent at the same time — portability means one reviewed artefact travels everywhere, and so does one unreviewed one.

Skill packs did not arrive alone. They shipped inside a dense week of agent-infrastructure releases from the same vendor — per-agent sandbox isolation, an AI gateway and sandbox pairing for hosted agents, public read-only container registry repositories, audit log drains to third-party SIEM destinations. Read together, that is a platform building the operational surface agents need in production. Distribution is simply the piece that arrived without its verification half attached.

The forward projection worth making is about sequence rather than catastrophe. Ecosystems of this shape tend to add controls in a predictable order: first a canonical identifier, then a version string, then a lockfile or manifest, then integrity hashes, then signed provenance, and finally defaults that fail closed. Skill packs are at the identifier stage. If the pattern holds, the versioning scheme and a manifest arrive next, because those are what make the update command safe rather than merely convenient. The interesting question is not whether those land — it is whether they land before or after the first incident, and that is partly determined by how loudly the teams adopting this ask for them now.

For agencies and platform teams the practical read is that agent skills have crossed from a personal productivity artefact into a distributed dependency, and dependencies need owners. If you are standardising agent tooling across an engineering org, the policy work — approved sources, review ownership, pinning discipline, agent-level privilege limits — is the same work you would do for any other dependency class, and it is much cheaper to write while the surface area is still small. That policy design is a standard part of our AI and digital transformation engagements, usually alongside the tooling rollout rather than after it.