Skip to content

Connect in 2 minutes

The entry point is a skill, not the CLI. You add one skill; your agent does the rest — it installs the engine, connects this machine, shows you a block, sets up the runtime gate, and pulls your organisation's approved skills. The only things you do by hand are adding the skill, approving the sign-in once, and approving the hook it adds to your Claude Code settings.

What you need

Any agent that loads skills (Claude Code, Codex, Pi, …). No CLI setup, and no account yet is fine: the first skillsvault login creates your account and organisation.

Add the skillsvault skill to your agent

From your harness's skill UI, or:

npx skills add skillsvault/skillsvault-skill

That's the whole human step. The skill is the installer/driver — your agent reads it and bootstraps the rest.

Let your agent connect this machine

Your agent runs skillsvault whoami. If the skillsvault binary is missing, it installs it first:

curl -fsSL https://skillsvault.io/install.sh | sh

Finding this machine isn't connected yet, it asks you to authorize it. Approve the browser sign-in once — if you're new, the same visit creates your account and organisation:

skillsvault login

For CI or headless machines, paste an agent key from Settings → API keys instead of the browser flow:

skillsvault login --key <agent-key> --org <org-slug>

login syncs your org's signed policy bundle as soon as the machine is approved, and prints the next step.

See a block happen

If your org has already banned a skill, the agent runs:

skillsvault try             # gates a banned skill here, exactly as the hook would

try shows the BLOCKED decision and the audit link, and exits 0 — it is a demonstration. It picks a skill whose status is banned; a skill blocked only by a Block policy isn't picked. Nothing banned yet? Ban a skill in the console (open it and choose Ban skill, or click Add a demo skill and block it on the dashboard), then run skillsvault try again.

Turn on enforcement and pull approved skills

skillsvault install-hook    # prints the Claude Code hook config (skills, subagents, /commands)
skillsvault pull --all      # install approved skills into every detected harness;
                            # removes banned skills from the folders it installs into

install-hook only prints a hooks block; the agent asks before merging it into ~/.claude/settings.json (or the project's .claude/settings.json). Once it's there, Claude Code checks every skill, subagent and typed /command with the gate before running it. If a copy of a banned skill is still installed — sideloaded, or put there before the ban — and the agent reaches for it, the hook denies it before it runs and shows the agent your org's reason:

skillsvault blocked this skill. Skill version is banned by the organisation.

You can also check from the terminal — a block exits with code 2:

skillsvault gate --skill acme/legacy-export
# ⛔ BLOCKED  acme/legacy-export@1.2.0
#    Skill version is banned by the organisation.

The decision lands in your immutable audit log, visible to your governance officer in the console. That is the whole loop: one skill added → a banned skill blocked on a real machine → audited.

What just happened

You didYour agent did
Added one skillInstalled the skillsvault engine
Approved sign-in onceConnected this machine to your org
—Showed a banned skill being blocked (skillsvault try)
Approved the hookInstalled the runtime gate (Claude Code)
—Pulled approved skills, removed banned ones

Honest enforcement tiers

The runtime veto — blocking a skill mid-invocation — works where the harness exposes a blocking hook, which today means Claude Code. On Codex, Pi, and others, skillsvault provides distribution governance: it installs the approved skills and removes banned ones from the folders it installs into, but cannot veto an invocation those harnesses never offer to gate. Lead with distribution everywhere; enforcement where the hook exists.

Next