Skip to content

skilldrop·docs·Reference

Versioning and what stays stable

What skilldrop promises from 1.0.0 — the CLI, skill folders and names, scripts' flags and exit codes, loops, packs, the GitHub Action and plugin names — what each kind of release can change, and how deprecation and retirement work.

From 1.0.0, skilldrop follows Semantic Versioning for the surfaces below. A change that would break one of them waits for the next major version. The decision is RFC-0064.

What stays stable within 1.x

SurfaceStable
The CLI, skilldrop-cliIts commands and their flags, exit codes, and --json fields. The install targets. The .skilldrop.json ledger: any 1.x reads it (updates and the ledger). The SKILLDROP_POLICY, SKILLDROP_AUDIT_LOG, SKILLDROP_LOOP_LOG and SKILLDROP_NO_STAR variables
A skill's folderThe anatomy in the skill contract: SKILL.md's name and description, manifest.json's fields, and what its permissions mean
A skill's nameAn installed skill stays installable and updatable under its name
A skill's scriptsThe flags and exit codes its SKILL.md documents, because loops and CI gate on them
Loops, packs and profilesThe loop contract, pack.json, profiles.json, and each gate's verdict words
The GitHub ActionIts inputs and outputs (reference)
PluginsThe plugin names, <pack>@skilldrop

What any release can change

Version numbers

ReleaseExampleContains
Patch1.0.0 → 1.0.1Fixes. Improvements to a skill that keep its documented flags and exit codes
Minor1.0.1 → 1.1.0Anything added. Any deprecation. A skill's retirement
Major1.x → 2.0.0A break in a stable surface, after a deprecation in a minor release

Each skill has its own version in its manifest.json, under the same rules. skilldrop outdated compares them.

Deprecation and retirement

Supported runtimes

Raising either floor is a minor release with a changelog entry.

Edit this page on GitHub · View source