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.
Add changelog entries as part of shipping bugfixes, changes, and features during
day-to-day development.
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: