pnpm 12.18 starts managing agent skill links: install a package, get a directory in .claude/skills

pnpm 12.18 shipped on November 5. The first entry under Minor Changes stopped me: pnpm now links agent skills shipped by your dependencies into the project.

Skills inside packages finally have a convention

The behaviour: if @acme/kit ships a skill in skills/auth/, pnpm links it as .claude/skills/auth.

The naming matters. The earlier shape was .claude/skills/pnpm-@acme+kit-auth, encoding package name and version into the directory. It worked, but it was hard to read and looked wrong next to hand-written skill directories. Now the skill uses its own name.

Conflicts are settled too: when two approved packages ship a skill with the same name, or the name is already taken, pnpm links it as pnpm-<package>-<skill>. Previously this failed the install outright, which is the genuinely maddening part: you changed nothing except a dependency version and the install breaks.

Per-skill approval instead of blanket trust

The second change I like more: when a package ships more than one skill, pnpm approve asks which ones to link. The choice is recorded as permissions.<pkg>.skills, and the ones you skipped stop being offered.

The first time a project approves a skill, it also asks which agent directories to link into, stored under skills.dirs.

This moves “dependency code can execute” one step forward: a skill is an instruction set an agent reads and follows, which is closer to a permission than to library code. Having the installer ask once is the right instinct.

Skills nested in category directories, such as skills/engineering/implement/SKILL.md, are now linked too, up to three levels deep.

Two more

• pnpm store add: install offline from downloaded tarballs, which matters for air-gapped and internal build machines
• Repeat installs and verifyDepsBeforeRun no longer read package.json of unchanged workspace projects, which saves real time in large monorepos
• A handful of peer dependency resolution fixes

A personal read

For twenty years the package manager battlefield was “installs fast, installs correctly”. There is now a third axis: how much of what you install executes itself.

pnpm’s approach here is moderate. It names skills, deduplicates them and asks for approval. But it admits something: a dependency is no longer only code, it can also be an agent’s behavioural instructions. That admission carries more weight than the feature.

If you do not use packages with skills yet, the practical wins are fewer package.json reads and offline installs. But when a pnpm install one day leaves something new in .claude/skills, do not be surprised. The chain is already running.