Proof for agent skills.
No more blind installs to keep up with your agents. Your skills now carry signed proof of what they touch — exactly where you install them.
Give your skills the proof they need to earn trust
No matter whether you install from GitHub, a registry, or a vendored copy. One signed record says what a skill touches and whether it survived the last model bump.
Scan your way to a manifest.
Across every skill you install.
Diff your way to safe updates.
In the same PR where you review.
Single-prompt attest setup and you're done.
Start gating installs in no time.
"uri": "https://ledger.skillproof.dev/api/att…"}
The manifest viewer
A preview of the manifest viewer — one pane per capability, signed and synced.
Everything a skill can touch, in one manifest
networkOutbound domains and how they are reached.curl → evil.example.com
execShell access and interpreters a skill can invoke.shell: true · bash, python3
filesystemPaths a skill reads and where it may write.reads ~/** · writes ./reports/**
secretsEnvironment variables and credentials in reach.GITHUB_TOKEN, AWS_SECRET…
agentsWhether a skill spawns subagents, and which kinds.spawns research agents
mcpMCP servers a skill connects to.servers: []
skillproof scan derives all six from SKILL.md, scripts, hooks and MCP configs — then cross-checks them against what the skill declares, so honest authors get verification for free.
Why this exists
It works everywhere skills get installed
Don't be locked into one registry. Any host, harness, or CI can fetch the attestation and gate on the diff — keyed by content hash, never by name.
And any other host or harness that fetches attestations by content hash.
Latest changes
skills.sh proof pages, sync, and author Action
Checked-in capability proofs at /skill/ with raw JSON, OG metadata and a badge; bounded trending/hot sync every 6 hours; a GitHub Action skill authors can run; verify skills-sh: and proof-url commands.
Read-only skills.sh commands
skills-sh search, inspect and proof: fetch a skill snapshot, scan it, reconcile the upstream hash, and print the local proof. Exit 2 on hash mismatch, fail-closed errors without a token.
Scanner reports real values, real hashes
Placeholders are gone: domains, interpreters, paths and env names are extracted from content; content_hash is a real sha256; frontmatter supplies name and version; diff exits 2 on changed values; verify fails closed on unknown hashes.
Hand-reviewing skills no longer scales
With skills versioned, scripted, and installed from third parties, a new verification standard is being born. Proof-first review is the way to ship skills.
Traditional skill review
Reading code
Manually read every SKILL.md, script, and hook — one at a time, on every update.
Tracking changes
Diff versions by eye and hope no new domain, secret, or exec slipped in.
Trusting authors
Open the repo, scroll for the install script, and guess whether it changed.
Surviving model bumps
Re-run every skill by hand after each model update, one by one.
Managing skills
Manually keep a spreadsheet of which skills you installed, consuming precious time.
Proof-first verification
Reading code
Read nothing by hand — the scanner derives the manifest from the skill itself.
Tracking changes
Ask the diff what changed. It reorders, highlights, and fails CI on new privileges.
Trusting authors
Fetch the Sigstore attestation — who signed it, and which scanner version checked it.
Surviving model bumps
Publish the eval delta once. Know which of your 40 skills degraded last Tuesday.
Managing skills
Gate every install in one bulk check.
How it works
- Scan — the CLI statically analyses a skill into a signed-able capability manifest.
- Attest — CI signs it with Sigstore and appends it to the public, append-only ledger, keyed by content hash.
- Gate — installs, PRs and harnesses fetch the attestation and the capability diff, and block on new privileges or model-bump regressions.
Evidence, not guarantees
Attestations prove what was analysed, and by which scanner version. They never certify safety — and neither do we. Start with core concepts, then scan your first skill.
For your agent
Onboard your agent
Paste this prompt into your coding agent. It points at the agent instructions rather than repeating them, so it cannot go stale here.
You are working in the SkillProof repository (github.com/RavaniRoshan/skillproof). Read AGENTS.md before you touch anything: it carries the build and test commands, the conventions, the two invariants that must not be weakened (content addressing beats names; evidence never guarantees safety), and a status section that names every v0.1 stub next to the file that causes it. Then run npm install, npm run build and npx vitest run, and confirm the baseline is green before you change anything.FAQs
It reads a skill directory and produces a machine-readable capability manifest: the network domains, shell interpreters, filesystem paths, secrets, subagents and MCP servers the skill reaches for. It then diffs two versions of that manifest and publishes a signed record to a public ledger.
No. Skills stay in git, where they already live. The ledger stores roughly one kilobyte of JSON per attestation — manifests and eval results only, never skill code.
A registry decides what you can install. SkillProof answers a different question: what does the thing you already installed actually touch, and did that change? Any registry, harness or CI can consume the records without asking us.
Skills are forked, vendored and renamed constantly. A name is a weak identity that can be squatted; the hash of the skill directory is a strong one. Copies and forks share a single identity automatically.
No, and we never claim it does. An attestation proves what was analysed and by which scanner version. Treat it as evidence you can audit, not a safety certificate.
Detection will never be complete — that is a stated limitation, not a bug to be hidden. The durable promise is the diff: a capability that appears between two versions is reported even if nobody read the code carefully.
Anything that can fetch a manifest by hash, because the records are plain JSON with no vendor binding. The field is moving quickly, so the integration list on this page is illustrative rather than exhaustive.
The core is MIT and the ledger is public, forever. If the project ever commercialises, it will be hosted conveniences such as scheduled evals and SLAs around a standard that stays open and free.
The intent is keyless signing from CI, so the signature binds to an OIDC identity and a workflow rather than a stored key. Keyless signing is not wired up yet — signature work is the next v0.1 milestone.
Not yet. v0.1 is a working scaffold: the CLI surface, schemas and docs are real, while the scanner's findings are placeholders and signing is unimplemented. AGENTS.md lists exactly what is stubbed.
Everything you expect from a skill manifest
SkillProof packs all six capability classes into one signed record — from quick scans to detailed organization.
All through keyless Sigstore signing or the always-synced public ledger.