@@ -23,8 +23,8 @@ body:
         - label: Sweep deprecations whose stated removal version has arrived (`grep -rn 'deprecated::' cuda_core/cuda`) and remove any that are due
         - label: "Finalize the doc update, including release notes (\"Note: Touching docstrings/type annotations in code is OK during code freeze, apply your best judgement!\")"
         - label: Update the docs for the new version
-        - label: Create the release branch (`release/cuda-core-vX.Y.x`) from `main` for a minor release, or check out the existing one for a patch release
-        - label: Create a public release tag on the release branch
+        - label: "For cuda-core: create the release branch (`release/cuda-core-vX.Y.x`) from `main` for a minor release, or use the existing one for a patch release"
+        - label: "Create a public release tag (for cuda-core, on the release branch)"
         - label: Wait for the tag-triggered CI run to complete, and use that run ID for release workflows (this will upload the release to PyPI)
         - label: Publish the release at https://github.com/NVIDIA/cuda-python/releases (this will trigger the conda package update)
         - label: Approve the conda-package update PR
 
@@ -160,8 +160,9 @@ git push origin origin/main:refs/heads/release/cuda-core-v0.6.x
 For a patch release (`X.Y.Z`), use the existing branch. Changes reach it
 through pull requests that cherry-pick the fixes from `main`, with
 `(cherry picked from commit ...)` trailers. The release notes for the patch
-release also go to `main`, so the docs switcher and the `latest` docs list
-them.
+release must be on the release branch before the tag: the release workflow
+checks for them in the tagged tree. Add them to `main` as well, so the docs
+switcher and the `latest` docs list them.
 
 The repository ruleset protects `release/**`: a push to an existing release
 branch needs a pull request and passing checks.