SkillsProof

Problem

The release decision could inherit stale evidence.

A changed Skill candidate could still appear safe because validation, evaluation, registry, and runtime observations belonged to an older package. The maintainer needed to know which evidence still counted before acting on a release.

Discovery

A score was context, not candidate proof.

A registry score describes a registry observation; it does not establish that the local package has passed its checks. SkillsProof keeps those observations separate and checks downstream receipts against the current package digest, the identifier for that exact package. Missing, malformed or mismatched evidence must not become a passed stage.

Constraints

Each check had to stay tied to the right package.

• Candidate identity had to be established before downstream evidence could count.
• Local validation, security, evaluation, registry, runtime, review, and release truth had to remain separate.
• Demo fixtures needed explicit labels so deterministic presentation could not be mistaken for live provider evidence.
• Provider-backed or publishing operations could not run automatically when the app opened.

Decisions

I made each release stage easier to inspect.

• Model the journey as a nine-gate evidence chain rather than one blended readiness score.
• Hold downstream gates when the canonical candidate identity is missing or stale.
• Show the next required stage while allowing the maintainer to inspect any of the nine stages.
• Expand Show command to inspect the full command; Copy command copies it without running it.
• Keep the public web demo on safe mock data and state its non-production boundary.
• Discover installed skills without borrowing source-checkout receipts: an installed copy remains Unproven until its checked-source evidence is linked.

Delivery

Nine stages, one selected detail panel.

The native app presents Identity, Validation, Security, Eval prep, Local eval, Cloud eval, Staging, Publication and Runtime in a three-column navigator. Selecting a stage changes the detail panel without changing the next required stage or the evidence status. The app can inspect local SDK checks and read saved evaluation, publication and runtime receipts; it does not automatically start provider-backed evaluations, publish a package or install a runtime when opened. These stages describe the intended lifecycle; several still need implementation or live integration proof. The separate web demo explains the release decision with fixed data and no credentials.

Failure and correction

Inspection must not look like a release decision.

The current interface distinguishes the next required stage from a stage selected for inspection. Selection is preserved during refresh for the same candidate and reset for a new candidate. Command details can be expanded before copying, and registry observations have their own disclosure. Selecting, copying or refreshing a stage does not supply its missing evidence.

Outcome

A working local prototype with explicit limits.

The repository provides native source, deterministic fixtures, tests and build, launch and packaging scripts. The local build inspected on 20 October 2026 also discovers installed skills through the ellipsis menu → Select skill, with origins and plugin versions identified. Those discovery changes are local development work, not a published release. Installed copies remain Unproven until checked-source evidence is linked. A notarised public release still requires a Developer ID identity and Apple notarisation credentials. External adoption and successful live SDK, Tessl or installed-runtime sessions have not been established by this case study.