Directory FAQ

How do I self-host a manifest with a lock?

Download the manifest, then let the CLI resolve every member in a clean project and export the manifest and lock together:

npx @skill-set/cli share --manifest ./my-set.skill-set.json --output ./public/my-set

Host the generated my-set.skill-set.json and my-set.skill-set.lock.json beside each other at the same HTTPS path. Installing the manifest URL discovers the sidecar lock automatically:

npx @skill-set/cli add https://example.com/my-set/my-set.skill-set.json

If you cannot host the lock, share the manifest URL with the generated lock's setHash as an out-of-band integrity pin:

npx @skill-set/cli add https://example.com/my-set/my-set.skill-set.json#sha256=<setHash>

The CLI strips the fragment before fetching, resolves the current skill contents, recomputes the set rollup, and keeps nothing if it differs. The lock does not need to be hosted for this form, but you still need share to produce its trustworthy setHash. Never derive it from skills.sh catalogue metadata or invent it from the manifest alone.

See the canonical CLI share documentation for the complete command behavior and the receipt-time verification specification for the hash rules. Hashes prove delivered-byte integrity, not author identity or safety.

What is the difference between temporary and submitted sets?

A temporary URL is unlisted and immediately installable, but has no lock and expires after roughly 30 days without use. Directory submission re-resolves the skills, generates a lock, and opens a pull request for review. You can also self-host the CLI's generated manifest and lock without submitting to this directory.