We hash-check vercel-labs/skills installs and fail on drift. 10 of 10 tests green.

vercel-labs/skills is the npx skills installer, and it records a content hash for every skill it installs in skills-lock.json. We ported its folder-hash function into a small CLI that recomputes the hash from disk and fails when the two disagree, so the rules your agent follows stay the ones you reviewed. Our keyless run passed 10 of 10 lab tests and verified the committed skill in 285 ms. The catch is that the installer has a restore command that puts skills in the wrong place, and the lock only protects you if you review before you rewrite it.

The catch

skills@1.7.2 experimental_install restores into .agents/skills/ and ignores -a claude-code. Claude Code and Cursor both read .claude/skills/<name>/SKILL.md in our setup, so a restore through that command puts the skill where our agents do not look. tests/experimental-install.test.ts pins that behavior. Re-run add with -a claude-code --copy to restore instead.

The lock is also only as honest as the last --write. bun run verify --write regenerates every hash from whatever is on disk, so run it after you read the diff, never to make a red check go away.

We did not get the full upstream suite green on this machine. With Homebrew git 2.39 on PATH, the git-lfs-clone and git-transport-allowlist tests pass, and the full 964-test run can time out under load. The README records it as expected green on CI (ubuntu-latest, Node 24) and it is not part of reports/skills-lock.json.

What we ran (keyless)

bash scripts/vendor-upstream.sh
bun install
bun run typecheck
bun run test
bun audit
test ! -e .cursor/skills && test ! -e .agents/skills
bun run verify

From reports/skills-lock.json, run on October 13, 2026:

The upstream pin matched (13e4063a), and the vendored clone was present. The find-skills install we used as the reference hash produced 913b9d37d0d54047dd65222bb8c67b2bf04e3cb87dcad1729068d7a8b2c8c396. In the README run, bun audit found no vulnerabilities across 13 packages.

To watch it fail, append a byte to an installed skill and verify again:

echo x >> .claude/skills/find-skills/SKILL.md
bun run verify
# DRIFT find-skills expected=... actual=...  (exit 1)

Exit codes are 0 for OK, 1 for DRIFT and 2 for MISSING, so CI and pre-commit hooks can branch on them.

How it is wired

The skills CLI writes the lock at install time. Our lab skill, verify-rules-before-deciding, tells the agent to run bun run verify before it follows any installed skill, and CI runs the same check on every push. If someone edits a SKILL.md by hand or a sync pulls a changed copy, the hash moves, verify exits 1, and the change waits for a human.

Minilab (open source)

The lab pins vercel-labs/skills at 13e4063a (34,939 stars, MIT, TypeScript, as of October 14, 2026) and installs only from a local clone, so it needs no API keys. Re-run bash scripts/vendor-upstream.sh, bun install and bun run report, then read reports/skills-lock.md for your own numbers.

bash scripts/vendor-upstream.sh && bun install && bun run verify