Two layers, one supply chain for agent skills. The store finds a skill; the vault decides whether it actually runs — gated, signed, deduped, scoped, and rendered as one canonical SKILL.md per agent.
The seam
ProSkills and AutoVault solve two different problems that are easy to conflate. ProSkills answers "does a skill for this exist, and is it any good?" AutoVault answers "should this agent, on this machine, be allowed to run it — and in what form?" Keeping those concerns on opposite sides of a signed boundary is the whole idea.
indexed skills, each with reviewer scores
native rendering under local policy
trust.toml tiers decide auto / prompt / blockSKILL.md each agent reads nativelytrust.toml says yes. The score informs policy — it never is policy.End to end
One pass through the pipe. Blue stages live in the store; gold stages live in the vault on the agent's machine.
Agent or human searches 2,388 skills, compares reviewer scores, picks a version.
"Install via AutoVault" mints a signed manifest: skill id, version, content hash, publisher, review snapshot.
Vault checks signature and publisher, then maps the review snapshot onto trust.toml: auto-install, prompt, or block.
If the content hash already exists, reuse it. Otherwise stage once in the content-addressed store and scope it to the requesting agent/project.
Emit one SKILL.md per agent in that agent's native layout — Claude, Cursor, Codex all read their own flavour of the same source.
Agent uses the skill. Vault records invocations, errors, and overrides locally.
Anonymized signals — installs kept/removed, error rates, trust decisions — flow back and nudge reviewer scores.
Topic 1
The button is the handshake. In the store it looks like one click; underneath it hands AutoVault a signed intent and gets out of the way. The store never ships code directly — it ships a verifiable pointer plus the review context the vault needs to make a local decision.
// Not the skill. A signed pointer the vault can verify offline. { "skill": "pdf-form-filler", "version": "2.4.1", "contentHash": "sha256:9f3c…a71b", // drives dedup "publisher": { "id": "asif-labs", "keyId": "k_7d2" }, "review": { "stars": 4.7, "score": 92, "flags": [] }, "source": "https://proskills/registry/pdf-form-filler/2.4.1", "sig": "ed25519:…" // store attestation }
Depending on trust.toml, the same click either installs silently, raises a consent prompt, or refuses with a reason. The store UI stays identical.
The vault checks the publisher signature against pinned keys. No live call to the store is required to decide safety — the intent is self-contained.
autovault://install?intent=… lets the web storefront hand off to the local daemon, or an agent can POST the intent to the vault's local socket.
Re-clicking a skill already present is a no-op after the hash check — you land on "already installed, scoped here" rather than a duplicate.
Topic 2
ProSkills produces a score; AutoVault owns the policy. The mapping is deliberately simple and local-overridable — the operator sets the thresholds, the store just supplies the number. A default trust.toml might read:
# Tiers are evaluated top-down; first match wins. [tiers.verified] min_review = 90 publishers = ["asif-labs", "autojack"] # pinned keys action = "auto" # install without prompt scopes = ["agent", "project"] [tiers.community] min_review = 70 action = "prompt" # one consent click scopes = ["project"] [tiers.untrusted] min_review = 0 action = "block" # manual --force override only [overrides] deny_flags = ["network-exfil", "shell-root"] # block regardless of score allowlist = ["pdf-form-filler"] # always auto, any score
| Store signal | Default tier | Vault action | Default scope |
|---|---|---|---|
| review ≥ 90 & pinned publisher | verified | auto — silent install | agent + project |
| review 70–89 | community | prompt — consent click | project only |
| review < 70 or unknown publisher | untrusted | block — explicit --force | none until forced |
| any score + denied capability flag | override | block — non-negotiable | none |
| on allowlist | pinned | auto regardless of score | operator-defined |
Topic 3
This is the part most "skill marketplaces" get wrong: they ship one format and hope every runtime tolerates it. AutoVault inverts that. There is one canonical source of record per installed skill, and the vault renders it into whatever shape each agent natively reads — Claude's SKILL.md + frontmatter, Cursor rules, a Codex tool spec — all projected from the same bytes.
--- name: pdf-form-filler version: 2.4.1 hash: sha256:9f3c…a71b trust: verified # resolved locally, not shipped scope: [agent:claude, project:autohub] capabilities: [fs:read, fs:write:./out] --- # PDF Form Filler Fills AcroForm fields from a JSON map. Deterministic, no network. Use when a user hands you a fillable PDF.
Dropped as .claude/skills/pdf-form-filler/SKILL.md with the frontmatter the agent expects. Trust + scope fields resolved from local policy.
Projected into a .cursor/rules entry with the same description and capability bounds, in Cursor's native rule grammar.
Exposed as a tool spec (AGENTS.md block or JSON schema) so a terminal agent can call it without reading Markdown prose.
Edit or revoke once in the vault; every agent's rendered copy regenerates. No drift between a skill's "Claude version" and "Cursor version".
Topic 4
The loop only closes if the vault tells the store what happened after install — but without leaking what the agent actually did. AutoVault emits coarse, anonymized signals that let ProSkills sharpen reviewer scores for everyone, while keeping local project data local.
Kept vs. uninstalled within N days. A skill people install and immediately remove is a strong negative signal the stars won't catch.
Invocation failures / crashes per install, bucketed. Feeds a "reliability" sub-score distinct from popularity.
How often operators --force past a block, or demote a "verified" skill. Reveals mismatch between store score and real-world trust.
Content-hash collisions across installs confirm which version is genuinely canonical and surface silent re-publishes under the same version.
{
"skill": "pdf-form-filler",
"version": "2.4.1",
"window": "7d",
"retained": 0.94, // kept after a week
"errorRate": 0.011,
"forcedInstalls": 0,
"trustDemotions": 0
// no filenames, no prompts, no project data
}
trust.toml — an air-gapped or privacy-strict operator sets feedback = "off" and the vault still works; it just stops contributing to the shared score. The store degrades gracefully to review-only signal.Where we're unsure
Publisher keys pinned in trust.toml are the root of the whole gate. Key rotation, revocation (a compromised publisher), and a fallback transparency log all need an answer before "verified" means anything.
One "92" is easy to map but conflates quality, safety, and maintenance. A vector (safety 95 / quality 88 / maintained 70) maps to richer policy but complicates the storefront and the min_review threshold.
Claude, Cursor, and Codex formats drift. Does the renderer live in the vault (needs updates) or ship as per-agent adapters the store distributes? Either way it's a maintenance surface that can silently break installs.
Content-addressed storage is cheap, but a globally shared store crosses trust boundaries (one project's skill visible to another). Per-project dedup is safer but wastes disk. Scoping and dedup pull in opposite directions here.
If retention/error signals move reviewer scores, a motivated publisher can juice them with fake installs. Needs sybil resistance or the loop becomes a reputation-laundering channel.
An autonomous agent hitting a prompt-tier skill at 2am has no human to click. Does it queue, fall back to a stricter default, or use a pre-authorized budget of consents? This is the seam between automation and safety.
What could bite us
If operators treat a high ProSkills score as "safe to auto-run," the local gate becomes theater. The UX must keep the vault's authority visible, not bury it behind a green checkmark.
A skill that changes bytes but keeps its version number defeats dedup and trust pinning. The content hash must be the identity, and a hash change on a pinned version should force re-review, not silent update.
The per-agent render writes into .claude/, .cursor/, etc. A malicious canonical doc could try to smuggle instructions through frontmatter the target agent over-trusts. Render must sanitize, not pass through.
Per-agent, per-project overrides make the effective policy hard to reason about. Need a autovault explain <skill> that prints which tier/override actually decided.
Even coarse signals, correlated over small populations, can leak. Rare skill + small window = identifiable operator. Needs k-anonymity thresholds before a signal is emitted.
An air-gapped vault can't see score drift or revocations. Acceptable, but installs should carry a "last verified" date so the operator knows the trust decision is aging.