releasekitlisted

# releasekit A repo that writes [Conventional Commits](https://www.conventionalcommits.org) has already answered the two questions a release asks: what changed, and how much did it break. releasekit reads that answer back out. It resolves the commit range since the last release, derives the next semver version and a [Keep a Changelog](https://keepachangelog.com) section from the commits in it, and cuts the release: a `CHANGELOG.md` entry, a version bump in the ecosystem's manifest, an annotated tag, and a GitHub release. Everything it does is previewed before anything mutates, because a version number is spent permanently. A tag that ships broken code cannot be reused, only superseded. **releasekit stops at the tag.** It does not run `npm publish`, `twine upload`, or `cargo publish`. The tag it creates is precisely the trigger a publish workflow already listens for, and credentials plus irreversibility are two good reasons to leave that where it is. ## When this fires The user wants to turn merged work into a released version: "cut a release", "release this", "tag a version", "what would the next version be", "generate the changelog", "ship v2", "/releasekit". Three boundaries matter: - **It does not write the commits it reads.** Authoring Conventional Commits belongs to the commit step; releasekit only ever parses what is already in the log. - **It is not a publisher.** The registry upload is CI's job, triggered by the tag. - **It is interactive only.** The confirmati