Skip to content

v1.2.0

Latest

Choose a tag to compare

@catidegla catidegla released this 11 Sep 15:06
· 6 commits to main since this release

Provenance and containment

A skill is a directory of instructions an agent reads and scripts it can run. Installing one is an install, and until now this treated it as a copy.

Installs are pinned to content digests. skills.lock.json ships with the package and records the sha256 of every skill as released. Installing compares against it and refuses on a mismatch, because at that point the files on disk are demonstrably not the ones the lock describes. The digest is taken over a sorted listing of <file sha256> <path>, so a rename is caught even when no file content changed, and symbolic links inside a skill are refused rather than followed, since the installer copies recursively and a link can point anywhere on the machine.

.skillbelt.json records what was actually installed, beside the skills themselves. That answers the question the lock cannot: whether anything has touched your copy since. verify exits non-zero when something is modified, so it works in CI, while a skill that merely has a newer version available is reported as outdated and does not fail the run.

Scripts launched through skillbelt run execute inside the access they declare. Anything undeclared is denied, so a skill that forgets a key loses the capability rather than keeping it. The scopes are named rather than free paths, project being the directory you are working in and skill the installed skill itself, so a skill cannot declare its way to your home directory.

What this does not claim

run binds scripts it launches. An agent that reads SKILL.md and types node scripts/check-parity.mjs gets no sandbox at all, and an installer cannot prevent that. The skills here document the sandboxed invocation first for exactly that reason.

allow-exec: php grants the whole child process capability, because the i18n checker shells out to php to read PHP locale arrays and Node has no way to grant one binary alone. The binary list is disclosure that shows up in a diff. It is not a fence, and Node prints its own warning saying as much.

So the three parts stand differently. Provenance is pinned and enforced. Capabilities are declared, checked against the code, and enforced on the launch path this tool controls. Containment of a script somebody else chooses to run directly is not something this can offer, and nothing here pretends otherwise.

Also

The capability banner never prints a limit the runtime is not applying. A sandbox that silently is not one is worse than no sandbox.

run no longer requires a harness. Running a skill's script is not the same act as installing it into an editor, and it was refusing on machines that had nothing installed yet.

run exits 3 when it declines to start, which is how a script tells that apart from the skill having found problems. Both are failures and they mean opposite things.

The README names the packages that already install skills, agent-install and skills, and says plainly which job each does better. The installer half of this was never a novel idea.

25 tests on Linux, macOS and Windows. Node 20 or later, no dependencies.