releasinglisted

# Release procedure Pick the bump per semantic versioning: **patch** for bug-fixes only, **minor** for any new user-visible feature, **major** for breaking changes that require user or operator action. Use today's date. ## 0. Read the repo profile first Read `Lock:` and `Docs language:` from the `## Repo profile` section of the repo's root `CLAUDE.md` (see the `committing` skill). The lock decides whether you cut the release on a feature branch through a pull request or straight on `main`. The docs language decides the CHANGELOG wording. If the section is missing, infer, confirm once, then write the four-line `## Repo profile` marker into the root `CLAUDE.md` yourself (the block is in the `scaffolding-repos` skill, step 5). Reach for the full `scaffolding-repos` skill only if the repo also lacks its other generic files. ## 1. Pre-flight: run the `committing` checklist A release ships the docs, not just the code, so before bumping anything run the `committing` pass over everything since the last release: confirm the docs are current and that no change left an existing doc stale, update any `CLAUDE.md` the work invalidated or extended, and prune comments to the strictly useful. Then make sure `[Unreleased]` is complete: every user-visible change since the last tag has a bullet, there are no duplicates, and it reads cleanly for a human. A release is the worst moment to find the changelog is missing entries. If the project has a typecheck or build step, run it now and confi