release

# `/gflow:release` — Cut a new release Follow this sequence verbatim. Every step matters. > **Branch-protection note:** `main` blocks direct pushes. The release commit travels > via a `chore/release-vX.Y.Z` branch PR. The signed tag is pushed independently > (tag pushes bypass branch protection and trigger the CI release workflow immediately). > > **Source-branch note (read first):** `develop` is the integration branch — it carries > ALL unreleased work and `main` usually lags it. The release branch is cut from > **`develop`**, NOT `main`. The PR `chore/release-vX.Y.Z → main` then brings the full > integration history onto `main`. Do not expect the work to already be on `main`. ## Inputs Ask the user (if not already provided): 1. **Version** — the new version (e.g. `0.4.0`, `0.4.0a3`, `1.0.0rc1`). Use PEP 440 prerelease suffixes (`aN`, `bN`, `rcN`). If they don't know, run `/gflow:changelog` first and propose the next bump (PATCH for fixes only, MINOR for new features, MAJOR for breaks). 2. **Pre-release?** — prerelease versions stay marked as GitHub prereleases. Only the user can say when a release line is ready for the stable tag. --- ## Sequence **1. Review what's queued.** Run `/gflow:changelog` — confirm the `[Unreleased]` block is non-empty and accurate before proceeding. **2. Verify (or triage) a clean working tree.** ```bash git status --short ``` If empty, continue. If not, **triage before aborting** — do not blindly stop: - **Auto-injected boilerplate**...