fastapi-release

Cut a release: pick the next version, update every place the version is declared, write the changelog from the conventional commits since the last release, and tag. Stop before pushing or publishing unless the user asked for those too. ## Phase 1: Establish the baseline 1. **Find the current version and every file that declares it.** Read CLAUDE.md for the version location, then confirm by searching — a project often repeats the version in more than one file (e.g. `pyproject.toml` *and* `src/<pkg>/__init__.py`, or `package.json` *and* a lockfile). List them all; a release that bumps one and misses another ships an inconsistent version. 2. **Find the last release tag.** `git describe --tags --abbrev=0` (fall back to the first commit if there are no tags). This is the range boundary for the changelog. 3. **Collect the commits since that tag.** `git log <last-tag>..HEAD --oneline`. If there are none, there's nothing to release — say so and stop. ## Phase 2: Choose the next version Derive the bump from the conventional-commit types in the range (semver): - **major** — any commit with a `!` (e.g. `feat!:`) or a `BREAKING CHANGE:` footer. - **minor** — at least one `feat:` and no breaking change. - **patch** — only `fix:` / `perf:` / `refactor:` / `docs:` / `chore:` etc. State the computed version and the reason before changing anything. If the user named a specific version, use theirs; if the commits disagree with it (e.g. they said patch but there's a `feat!`), flag the mis...