Test/.claude/commands/pre-release.md

Run the pre-release checklist for this project. Work through all three phases in order, pausing for explicit confirmation at each decision point before proceeding. Never create a branch, commit, tag, or push without approval.

---

Phase 1 — Determine next release

1. Run git status and confirm the working tree is clean and on master. If not, stop and report the problem.

2. Run git tag --sort=-v:refname to list existing tags. Identify the most recent tag matching v*.*.*-* and extract its stadium codename.

3. Read the A–Z stadium table from CHANGELOG.md to find the next stadium:

   • No tags yet: start at A (first stadium in the table).
   • Normal case: use the stadium that follows the last used codename alphabetically. If letters were skipped, pick the next after the highest existing codename — do not backfill gaps.
   • Last codename is Z (Zentralstadion): the list is finite. Stop and refer to ADR 0012 for guidance on extending or revisiting the convention.

4. Read the [Unreleased] section of CHANGELOG.md and infer the version bump using these rules (applied in order — first match wins):

   • Any entry contains the word BREAKING (case-insensitive), a BREAKING CHANGE: token in a commit footer, or a ! suffix after the commit type/scope (e.g. feat!: or feat(scope)!:) → major bump
   • Any ### Added subsection has entries → minor bump
   • Otherwise (only ### Changed, ### Fixed, ### Removed) → patch bump

5. Compute the next version by applying the bump to the current latest tag's semver (e.g. v2.1.0-dusseldorf + minor → 2.2.0).

6. Present a summary for confirmation before continuing:

   • Last tag and stadium
   • Next version and stadium codename
   • Bump type and the reasoning (what triggered it)
   • Proposed tag: vX.Y.Z-{stadium}
   • Proposed branch: release/vX.Y.Z-{stadium}

   Wait for explicit approval before proceeding to Phase 2.

---

Phase 2 — Prepare release branch

1. Create branch release/vX.Y.Z-{stadium} from master.

2. Edit CHANGELOG.md:

   • Replace ## [Unreleased] with ## [X.Y.Z - StadiumName] - YYYY-MM-DD (use today's date; use the stadium's display name from the table, e.g. "Bernabeu", "Centenario").
   • Consolidate duplicate subsection headings (e.g. two ### Added blocks should be merged into one).
   • Add a new empty ## [Unreleased] section at the top (above the new versioned heading) with the standard subsections.
   • Update the compare links at the bottom of the file:
     • [unreleased] → .../compare/vX.Y.Z-{stadium}...HEAD
     • Add [X.Y.Z - StadiumName] → .../compare/v{prev-tag}...vX.Y.Z-{stadium}

3. Show the full diff of CHANGELOG.md.

4. If coderabbit CLI is installed, run coderabbit review --type uncommitted --prompt-only on the uncommitted CHANGELOG changes:

   • If actionable/serious findings are reported, stop and address them before proceeding.
   • If only nitpick-level findings, report them and continue.
   • If coderabbit is not installed, skip with a note.

5. Propose this commit message:

   docs(changelog): prepare release notes for vX.Y.Z-{stadium} (#issue)
   

   Wait for explicit approval before committing.

6. Run dotnet build --configuration Release — must succeed.

7. Run dotnet test --settings .runsettings — all tests must pass.

8. If dotnet csharpier is available, run dotnet csharpier --check . — must pass (run dotnet csharpier . to auto-fix). Skip with a note if not installed.

9. Stage CHANGELOG.md and commit using the approved message from step 5.

10. Propose opening a PR from release/vX.Y.Z-{stadium} into master. Wait for explicit approval before opening.

11. Open the PR with:

• Title: docs(changelog): prepare release notes for vX.Y.Z-{stadium}
• Body summarising what is included in this release.

---

Phase 3 — Tag and release

1. Wait — do not proceed until the user confirms:

   • CI is green
   • The PR has been merged into master

2. Once confirmed, run:

   git checkout master && git pull origin master
   

   and show the resulting git log --oneline -3.

3. Propose the annotated tag:

   git tag -a vX.Y.Z-{stadium} -m "Release X.Y.Z - StadiumName"
   

   Wait for explicit approval before creating the tag.

4. Create the tag, then propose:

   git push origin vX.Y.Z-{stadium}
   

   Wait for explicit approval before pushing. Remind the user that pushing the tag triggers the CD workflow which will build, publish the Docker image, and create the GitHub Release.