Skills
The Skills studio is a proof-carrying skill vault. Each skill is a small ability written in Zi — Zimac's proof language — and installed only if a verifier proves it meets its written specification. A verified skill is cut as a gem you can run for exact, guaranteed-correct answers; the whole vault is a place where every ability is proven, not merely trusted.
A skill is proven before it can be used. Paste a Zi package and the studio verifies every obligation — if the proof checks out it installs as a gem; if not, nothing is minted. Running one is proof-gated: it executes only when the inputs satisfy the skill's preconditions, so an out-of-domain call is refused rather than returning a wrong number. And a gem's very appearance is derived from its proof — tampering shows as a broken stone, never something you have to notice.
◆ Verified on install
A gem exists only if a verifier proved every obligation in its Zi source.
◆ Proof-gated runs
A skill runs only on inputs that satisfy its preconditions — else it's denied.
◆ Safe by proof
Effectful, credential-holding skills are proven not to leak — and armed by you.
◆ Auditable
Publish a gem to a tenant transparency log and anyone can verify it wasn't altered.
What it is#
Most "skills" systems are scripts you have to trust. The Skills vault is the opposite: an ability earns its place by carrying a machine-checkable proof that it does what its specification says. That changes what a skill is — not code you hope is right, but code a tiny verifier has confirmed is correct, over all inputs in its domain. The studio is the case where those proven abilities are kept, run, and shared.
Gems, not scripts#
Each skill is drawn as a cut gem, and the look is derived from the proof, not decorated: the number of facets comes from the ability's function count, and the stone continuously re-verifies — if anything about it were tampered with, the gem shows as broken rather than hiding the problem. Once a gem is published to a transparency log it gains a dashed orbit ring. In other words, you can read a skill's trustworthiness off its appearance.
Cutting a gem#
You add a skill by cutting a gem: paste a Zi package (or ask a specialist to gem an ability it just wrote), and the studio verifies it. The verifier must prove every obligation — full reward, no holes — before it installs; a package that doesn't fully prove is refused, so nothing unproven ever enters the vault. An empty vault says exactly this: "every skill here has been mathematically proven correct before it can be installed, run, or shared."
Running & proof-gated calls#
A gem can be run to compute an exact result, and invocation is proof-gated: the verified interpreter executes the skill only when your arguments satisfy its preconditions. Feed it something out of its domain and the call comes back denied — nothing computed — rather than a plausible wrong answer. When it does run, the value is guaranteed to satisfy the skill's contract, so you can take it at face value without re-checking the math.
Pure vs effectful#
Gems come in two tiers, and the vault treats them differently:
A pure skill is a deterministic computation and runs freely. An effectful skill — one that touches the outside world or holds a credential — is still proven safe (the verifier guarantees the credential can never leak and external data is checked before it's trusted), but it never runs autonomously. You arm it explicitly, supplying any secret, which is stored in the OS keychain and never in a conversation — so a skill that can act on your behalf only ever does so with your consent.
The transparency log#
A gem can be published to your tenant's transparency log — an append-only record that lets anyone in your organization confirm a skill is exactly the one that was verified, unaltered. The studio shows the log's state at a glance ("log pinned at size N"), and you can sync and audit it: a tampered or forked log surfaces as a conflict rather than passing silently. It's how a proven skill becomes a shared, checkable asset instead of a private one.
Built on Zi#
The vault rests on Zi, Zimac's proof-carrying language: a program ships with a proof that a small, auditable kernel re-checks, so neither the model that wrote it nor the prover that found the proof has to be trusted. That's the same machinery any specialist uses when it teaches itself a new capability — proven first, then offered to you. If you want the full picture of how the proofs work, the technical report is the place to start.