50 of 197 skills in seven packs call a script their pack never shipped

I installed twenty skill packs — 197 skills in total — and then checked every single one for the same defect: does the instruction file call a script or asset that the pack does not actually contain? 50 of the 197 do. That is 25 per cent of the archive pointing at files that were never shipped with it.

This is not a vendor problem in the usual sense. It is structural, it is invisible until you run the thing, and it is the most common reason a skill that "looks well written" does nothing when you invoke it.

Why it happens

Claude Code plugins resolve paths through a variable, ${CLAUDE_PLUGIN_ROOT}. Inside the plugin marketplace that variable points at a repository root that also contains scripts/, agents/ and extensions/. When the same pack is copied as a set of skill folders — which is what every "install the skills" flow does, including mine — those folders arrive and the rest of the tree does not. The prose is intact, the commands are dangling.

The numbers, by pack

Two shapes recur. The first is a wrapper: the skill is three paragraphs and one call to a CLI that lives at the repository root. The second is a kit installer: the skills are templates that expect a per-install directory with its own schedules and state files, and the installer itself is the thing that was not copied.

Why you only notice later

Because nothing fails at install time. There is no validation step in any of the pack formats: a SKILL.md is markdown with front matter, and markdown has no opinion about whether the path inside a code fence exists. The failure surfaces on the first real invocation, as an empty result or a shell error, and by then you have already trusted the output of the surrounding text.

The thirteen that are fine, and why

The remaining packs in the catalogue are prose: prompts, checklists, editorial rules, style guides. They have no scripts to miss, so "does it run" is not a meaningful question for them — the only check that matters is whether the writing is good. The failure mode is entirely a property of packs that promise to *do* something and then hand you a command to run.

How to check a pack in sixty seconds

1. Grep for the root variable. grep -rn "CLAUDE_PLUGIN_ROOT" <pack>/ — every hit is a command that will not resolve outside the original plugin.
2. Grep for relative script calls. scripts/x.py, scripts/x.mjs: check the file is there, in the folder the skill actually lives in.
3. Count the folders the pack references but does not contain — agents/, extensions/, schema/, data/.
4. Run the first command in a scratch directory before you wire the skill into anything that matters.

The auditor on this site does steps one and two in your browser: paste the SKILL.md, and it lists every root-variable call, every script reference and every collision with a name you already have installed.

What to do when you find one

Vendor the missing tree next to the skills and rewrite the variable to that absolute path. It takes about five minutes per pack and it is the difference between a skill that describes work and one that does it. If you cannot vendor it — the pack calls a private service — then treat the skill as documentation, not tooling, and say so in your notes so future-you does not fall for it twice.

Corrections

Measured 2026-11-05 against the pack archives as downloaded that day. Packs change; the method above is what stays true.