SKILL.md·open spec, evolvingread the spec ↗

A vault for skills
that agents can actually use.

SKILL.md files arrive from GitHub repos, public indexes, team docs, and agent drafts. AutoVault validates them at the door, signs what passes, and renders one clean view per agent without forking.

Terminal

Install the local vault

$curl -fsSL https://autovault.sh | sh

One copy-paste command. The installer creates ~/.autovault and refreshes local agent profiles.

Agent-assisted

Have Claude Code set itself up

Fetch https://autovault.dev/skill.md, show me what it will do, install it into ~/.claude/skills/autovault-bootstrap/SKILL.md if approved, then run /autovault-bootstrap.

Fetches a raw SKILL.md, shows the behavior, installs locally only after approval, then verifies AutoVault.

01In · varied sources

▸

github.com/…/skillsautoworks-ai/skills

unsigned

▸

agentskills.iopublic index

unverified

▸

team / SKILL.mdshared in slack

inconsistent

▸

discord pasteforwarded once

unscoped

▸

internal drafteng wiki, 2 weeks

forked

~/.autovaultgate · sign · scope

Out · rendered per agent02

Claude Coderead · write

✓

Codexfile_read · file_write

✓

Cursorfs_read · fs_write

✓

AutoHubnative bridge

✓

If you're running AI skills, you have these problems.

The format itself is fine. What's missing is everything around it. Six small papercuts that compound the more skills you keep around.

PROBLEM / 01

Skill drift

The same SKILL.md gets copy-pasted across repos and adapted locally. No upstream tracking, no merge story. Vendored code without a lockfile.

no provenance

PROBLEM / 02

Supply chain attacks

The same supply-chain attacks that hit package registries will hit skills too. AutoVault assumes that and gates before admission.

gate first

PROBLEM / 03

Duplicate explosion

Agents write skills on the fly with no dedup. You end up with seventeen variants of extract-pdf-text and the agent picks one at random.

no dedup

PROBLEM / 04

Platform inconsistency

Same skill, three forks — each calling agent expects different tool names. Fork once, maintain three.

fork × 3

PROBLEM / 05

Context bloat

Every agent loads every SKILL.md at startup. Forty skills means thousands of tokens burned before the conversation begins.

token tax

PROBLEM / 06

No permission scoping

Skills load globally. No per-project, per-device, per-tool gating. Dev-machine skills leak into prod, client A skills leak to client B.

leaks by default

What this looks like, concretely

One skill. Three filesystems. Three versions. No source of truth.

Every agent reads from its own folder. Edits in one don't propagate. Versions drift. Signatures don't exist. The same extract-pdf skill ends up looking like this.

Claude Code~/.claude/skills/extract-pdf/SKILL.md

stale

v1.4.0edited 8 days ago⌀ unsigned

  ## Tool calls
  read(path)
  write(path, content)
+ extract_text(pdf)

Codex~/.codex/skills/extract-pdf/SKILL.md

forked

v1.2.1manually edited⌀ unsigned

  ## Tool calls
- read(path)
+ file_read(path)
+ file_write(path, content)

Cursorproj/.cursor/rules/extract-pdf.mdc

orphan

no versionpasted from slack⌀ unsigned

  ## Tool calls
  read(path)
+ // TODO: trim prompt
- write(path, content)

↳ in the vault

~/.autovault/skills/extract-pdf/SKILL.md·v1.4.0signed 0x9af4…2c81rendered per agent

One canonical file. Three native renders — read for Claude Code, file_read for Codex, fs_read for Cursor — generated at install time, not forked by hand.

The simple answer

It's a folder.
That's the whole pitch.

AutoVault lives at ~/.autovault. Your skills go in there. Every agent on your machine — Claude Code, Codex, Cursor, AutoHub — reads from the same folder. Sync it with Git. Sync it with Dropbox. Don't sync it. Your call.

~/.autovaultwatching · 142 skills · 4 agents

~/.autovault/

├── skills/

├── signatures/

│ └── trust.toml

└── config.toml

read path →

extract-pdfv1.4.0

openverifyscoperender

path~/.autovault/skills/extract-pdf/SKILL.md

intentExtract tables and summary text from PDF reports.

sig0x9af4…2c81

scopeclaude-codecodex

name:extract-pdf

version:1.4.0

permissions:fs.read, browser

scope:project:autovault-website

claude-coderead · chrome-devtools

codexfile_read · browser_form

Or self-host the team mode →Deploy a remote vault

How the vault stays clean

How the vault stays clean — 01

Skills enter dirty.
They leave signed.

Anything joining the folder — whether you ran autovault add or an agent proposed one mid-conversation — passes the same five-step gate first. YAML auto-repaired, denylisted patterns refused, behavior cross-checked against the frontmatter, dedup against what's already there, then signed on the way in.

Reject rate

~1 in 9

held in the demo fixture

Avg. gate latency

<1s

local validation fixture

UNTRUSTEDweather-skill v1.2.0 from public mirror?

YAML auto-repair

Frontmatter is the #1 source of breakage. We fix it before storage.

QUEUED

Security denylist

Known-bad patterns: credential reads, fork bombs, exfiltration.

QUEUED

Capability vs. behavior

Does the skill actually do what its frontmatter claims?

QUEUED

Dedup

Text similarity in V1, embedding-space matching in V2.

QUEUED

Ed25519 sign

Provenance becomes a first-class artifact, not a hope.

QUEUED

VERIFIEDweather-skill v1.2.0 — admittedsig:0x9af4…2c81

✓

Gate admits the skill and writes a signature beside it.

How the vault stays clean — 02

One canonical skill.
Three rendered views.

Skills are written once against canonical capability names. The vault rewrites tool names per caller at delivery time — Claude Code sees read, Codex sees file_read, Cursor sees fs_read. Same skill on disk, three honest renderings out.

Transformation manifest in flight

Click a platform or individual capability to see exactly what gets rewritten. The skill on the left never moves.

1 Canonical skill

extract-pdf/SKILL.md SIGNED

name: extract-pdf

version: 1.4.0

tools_required:

# transformations:

# applied at delivery

2 Engine

browser.fill_form→chrome-devtools

3 Rendered for caller

● claude-codeSKILL.md (rewritten)

tools_required:

✓ Skill author wrote one file.
✓ Agent receives its native tool names.
✓ No fork, no drift, no duplicate.

Manifest format

YAML in skill frontmatter, validated at install and render

Resolution latency

< 4ms per skill, cached after first render

Agents supported today

Claude Code, Codex, Cursor, AutoHub + bridge skill for the rest

How the vault stays clean — 03

The skill exists.
Whether you can see it is a separate question.

Every request carries a context. Same folder, filtered four ways — agent, device, project, tool. Dev-machine skills don't surface on a CI runner. Client A skills don't leak into Client B's project.

incoming contextcaller=codex · skill=extract-pdf

requestprofile filterscoped render

vault responsevisible · rendered with file_read/browser_form

Team mode

Same vault.
Made shareable.

When the folder needs to live somewhere your team can reach, AutoVault exposes the same engine over remote MCP. No new format, no new gate — same validation, same signatures, same per-caller transformation. Just routed through a server you run (or one we run for you).

Self-host

Drop the binary on your own server. Point your team's ~/.autovault at it. MIT licensed, no phoning home.

Hosted at autovault.dev

For teams who'd rather not run a server. Reserved namespace, audit log, SSO. Same engine, same gate.

vault.team.acme.devhealthy

skills142 signed

members28

scopes14 projects · 4 roles

protocolremote MCP

jack@laptopjust now

maya@laptop2m

ci-runner-314m

devon@laptopoffline

Five minutes, two agents

Same skill, two callers, zero forks.

Vault vs managers and registries

Different shape.
Different defaults.

Skillfish is the closest direct neighbor for broad install, update, sync, and team bundle workflows across many agents. Managers and registries place skills; AutoVault admits trusted source, signs it, scopes it, and renders caller-specific output from one canonical skill without long-lived forks.

Capability	AutoVault	Skillfish	Tessl	SkillKit / Agent Skills	Manual
Local admission gate	●	◐	◐	○	○
Signed local provenance	●	○	○	○	○
Per-caller rendered output	●	◐	◐	◐	○
Project/agent/device scoping	●	◐	○	○	○
Broad public discovery	◐	●	●	●	○
Broad agent/runtime coverage	◐	●	◐	●	◐
Mature team/package workflow	◐	●	●	◐	○
Local-first, no required cloud	●	●	◐	◐	●

● shipped◐ partial○ absent

A vault for skills
that agents can actually use.

If you're running AI skills, you have these problems.

Skill drift

Supply chain attacks

Duplicate explosion

Platform inconsistency

Context bloat

No permission scoping

One skill. Three filesystems. Three versions. No source of truth.

It's a folder.
That's the whole pitch.

Skills enter dirty.
They leave signed.

One canonical skill.
Three rendered views.

Transformation manifest in flight

The skill exists.
Whether you can see it is a separate question.

Per-caller profiles

Machine-bound skills

Project boundaries

Fine-grained access

Same vault.
Made shareable.

Same skill, two callers, zero forks.

Different shape.
Different defaults.

If you're running AI skills, you have these problems.

Skill drift

Supply chain attacks

Duplicate explosion

Platform inconsistency

Context bloat

No permission scoping

One skill. Three filesystems. Three versions. No source of truth.

It's a folder.That's the whole pitch.

Skills enter dirty. They leave signed.

One canonical skill.Three rendered views.

Transformation manifest in flight

The skill exists.Whether you can see it is a separate question.

Per-caller profiles

Machine-bound skills

Project boundaries

Fine-grained access

Same vault.Made shareable.

Same skill, two callers, zero forks.

Different shape.Different defaults.

It's a folder.
That's the whole pitch.

Skills enter dirty.
They leave signed.

One canonical skill.
Three rendered views.

The skill exists.
Whether you can see it is a separate question.

Same vault.
Made shareable.

Different shape.
Different defaults.