Package manager for Claude Code skills
Sharing Claude Code extensions across a team without emailing Markdown files around.
Stack
TypeScript · MIT
Problem
Solution
Outcome
14
official packages
2
clients, one contract
npm
plugvault
MIT
open source
System design · Pipeline · Decisions
System Architecture
How It Works
Discover
The client pulls the index from every registered vault and caches it for an hour. The terminal UI is a full-screen browser with tabs for what is available, what is installed, and which vaults are configured.
Resolve
A requested name is matched against the merged index in vault order. First match wins, so an internal vault can shadow a public package of the same name. A vault-qualified form exists when you need to be explicit.
Install
Files are fetched and written where Claude actually reads them: a skill at .claude/skills/<name>/SKILL.md, a command at .claude/commands/<name>.md, under the project or ~/.claude/ depending on scope.
Track
The manifest records package name, version, and which vault it came from. Update, remove, and list operate on that record, not the directory listing, so multi-file packages and hand-written files stay distinct.
Publish
Adding a package means creating a folder with meta.json and an entry file, adding one index row, and opening a pull request. Every package in the official vault went in through that path.
Key Decisions
A registry is a JSON index committed to a repo. A hosted API would have needed its own accounts and something to keep running. Using repos means private distribution comes free from GitHub access controls. What I gave up: no download counts, no central moderation, no way to yank a bad package.
Each package is registry/<name>/ holding meta.json and a Markdown entry file. Inlining into one large manifest would have been simpler to fetch and horrible to review. The file that lands in .claude/ is byte-identical to the one on GitHub.
The terminal UI is Node and Ink. The Claude Code skill runs inside the conversation with no Node runtime at all. Both perform resolve, fetch, write, record in the same order, which is the only reason it is safe to have two of them.
An organisation registers its internal vault ahead of the public one, and its version of a package shadows the community version by the same name. Unqualified installs can silently resolve somewhere you did not expect.
Scanning .claude/ and inferring what is installed falls apart the moment a package spans more than one file, and it cannot tell a Plug-managed file from one you wrote yourself. The trade-off is drift: hand-edit the folder and the manifest is quietly wrong.
Evaluation
There's no evaluation harness yet, and that's the honest gap. CI unit tests catch regressions in resolution and path routing, but they don't test whether a package installs correctly from a fresh machine, into both scopes, and whether removing it leaves nothing behind. Dogfooding covers the common path. Private vault authentication, multi-file packages, and removal with dependents are verified by hand. An install matrix in a clean container per case would replace all of that manual checking.
What I'd Change
Get in Touch