Publishing a skill¶

Publishing turns a built dist/<name>/ into GitHub release assets, following the release model. It is driven by a GitHub Actions workflow in the skill's source repository — one build-*skill*.yaml per repo today, all repeating the same logic.

What the workflow does¶

For each skill it publishes, the workflow:

1. Computes build identity — short SHA, generation date, the rolling tag <prefix>-YYYY.MM.DD-<sha7>, and the asset sha256.
2. Packages the dist/<name>/ tree into a .tar.gz and .zip.
3. Emits a manifest — the version.json / latest.json payload ({tag, source_commit, generated, sha256, asset_url}).
4. Publishes in the appropriate mode:
5. rolling — create the dated prerelease, update the <prefix>-latest pointer, and prune old rolling builds to KEEP_ROLLING;
6. tagged, repo-coupled — attach the assets to the repo's v… release;
7. tagged, independently-versioned — publish under the skill's own <skill>-vX.Y.Z tag namespace.

Which tag a tagged release lands on¶

This is the one decision that varies, and it follows the skill's versioning (see the release model):

A client never has to care which of the two it is: any non-rolling tag carrying the skill's asset tarball is simply a "release". The per-skill prefix / rolling_re / pointer_tag in SkillSpec already namespace everything per skill, so independent tagged releases slot in without special handling.

Library boundary¶