This skill bundles key release engineering use cases with tenzir-ship.

Treat released changelog data as published history. Files under , including release notes, manifests, and release entry files, are immutable once published because they may already exist in GitHub releases, package registries, documentation, and downstream copies.

For normal follow-up work, add a new changelog entry on top of the existing history. Edit historical release artifacts only for severe publication defects, such as legally or operationally unsafe content, and only when the user explicitly asks for that correction.

Set up a new changelog workspace before the first entry exists. Prefer the explicit command when the task is project setup rather than entry creation.

Instructions:

Add changelog entries as part of shipping bugfixes, changes, and features during day-to-day development.

Instructions:

We distinguish two types of releases:

Prefer a remote release if a workflow exists, and use a local release otherwise.

When running into errors during the release process, obtain additional help by reading the official documentation: