You already use a permission model.
AutoVault gives it a place to live for skills.

Start with what you already know

Claude Desktop has Projects. The instructions you put in a project apply only when you are inside that project — they do not leak into another conversation. That is a scope: a rule about where something is allowed to apply. AutoVault keeps that idea, then adds two more layers that skills make necessary: what the skill says it needs, and what each agent calls the tools it expects.

Three layers, all configured separately, all visible in plain text:

Layer 1 — What the skill needs

The author of a skill puts a small capabilities block at the top of the SKILL.md. Three fields, no surprises:

capabilities:
  network: false
  filesystem: readwrite
  tools:
    - fs.read
    - fs.write

This is the author's signal: "I read and write files, I do not need the network, and these are the canonical tool names I call." It is not enforcement — the agent on your machine still owns what actually happens at runtime — but it makes the skill's expectations explicit and reviewable. AutoVault's admission gate validates the shape (types, enums, list contents) and runs a small denylist on the body; the agent at install time is what compares the declaration against what the skill actually does.

A skill without a capabilities block is accepted with a warning. AutoVault treats the block as optional metadata that improves on the open SKILL.md shape rather than as a new mandatory contract.

Layer 2 — What each agent calls those tools

Different agents call the same tool by different names. Claude Code calls it read; Codex calls it file_read; Cursor's tool surface differs again. Without transforms, the author would have to fork the skill three times to ship to three agents. With transforms, the author writes once against canonical names, and AutoVault renders one profile per agent at install time.

One canonical SKILL.md, rendered for two agents:

capabilities:
  network: false
  filesystem: readwrite
  tools:
    - read
    - write

capabilities:
  network: false
  filesystem: readwrite
  tools:
    - file_read
    - file_write

Transforms stack: a vault may install several, each with a priority, applied in order. A site-wide readonly-clamp transform with priority 100 might strip fs.write entirely for Codex regardless of what an earlier transform added. The order is deterministic and the diff is auditable. The interactive sandbox at the bottom of this page walks the exact applyCapabilityOverrides() logic if you want to see the stacking up close.

Layer 3 — Where the skill is allowed to run

After AutoVault renders a profile for an agent, install scope decides whether that profile is symlinked into a host's ~/.claude/skills or ~/.codex/skills. Same idea as Claude Desktop's project boundary, but for skills, with a few more axes the agent ecosystem actually uses.

The agents axis is enforced by autovault sync-profiles, which only writes to hosts a skill targets. project, device, and profile link are host-policy hooks the local installer composes; they are not validated by the admission gate.

You do not have to write any of this

If you are using a skill someone else wrote, you do not write a capabilities block, you do not write a TRANSFORM.md, and you do not edit install scope by hand. Agents understand the model. When you ask an agent to install a skill, it walks you through the install-scope questions in plain English:

You stay in control of the answers; the agent translates your answers into the right transform priority and install scope. The skill author wrote intent; you supplied policy; AutoVault is the place those two meet.

Compatible with open SKILL.md, stricter where it matters

An "open" SKILL.md — the shape used in Claude Code's published skills — is markdown with YAML frontmatter, body underneath. AutoVault's SKILL.md keeps that shape. The fields the open spec defines (name, version, description, body) work unchanged. AutoVault adds optional fields (capabilities, transformations, agents) and validates everything through the admission gate before signing.

Deep dive: stack transforms in priority order

The interactive sandbox below mirrors applyCapabilityOverrides() from autovault/src/transforms/index.ts. Pick a target agent, toggle the transforms, and watch the rendered profile update. Use it when you want to see how priority stacking and per-agent matching produce the final SKILL.md a host actually loads.

capabilities:
  network: false
  filesystem: readwrite
  tools:
    - fs.read
    - fs.write

capabilities:
  network: true
  filesystem: readwrite
  tools:
    - read
    - write
    - http.fetch

Where next