docs: update RELEASING.md to clarify automated steps

Clarifies that the tracking issue is created automatically by the
Prepare workflow, and that the release branch is cut automatically
after the prepare PR is merged.

Author: rickeylev

RELEASING.md

@@ -13,42 +13,41 @@ Release Tracking Issue and automated workflows triggered by comments or issue ed
 
 ### Steps
 
-1.  **Create a Release Tracking Issue**: Go to the GitHub Issues page and create
-    a new issue using the **Release Tracking Issue** template. This issue serves
-    as the central hub and checklist for the release.
-
-2.  **Prepare the Release**: Comment `/prepare` on the tracking issue. This
-    triggers the **Release: Prepare** workflow which:
-    *   Automatically determines the next version based on news entries.
-    *   Creates a `prepare-X.Y.Z` branch.
-    *   Updates `CHANGELOG.md` and version placeholders.
-    *   Creates a Pull Request with these changes.
-
-3.  **Review and Merge**: Review, approve, and merge the generated Pull Request.
-    Once merged, the **Release: Complete Prepare** workflow will automatically
-    mark the "Prepare Release" task as complete on the tracking issue checklist.
-
-4.  **Create Release Branch**: Manually check the **Create Release branch** box
-    on the tracking issue checklist. This triggers the **Release: Create Release
-    Branch** workflow, which cuts the `release/X.Y` branch.
-
-5.  **Tag Release Candidate (RC)**: Comment `/create-rc` on the tracking issue.
+1.  **Prepare the Release**: Manually run the **Release: Prepare** workflow from
+    the GitHub Actions UI (or via `gh workflow run`), leaving the `issue` input
+    empty. This workflow will:
+    *   Automatically determine the next version based on news entries.
+    *   Create a new **Release Tracking Issue** (which serves as the central
+        hub and checklist for the release).
+    *   Create a `prepare-X.Y.Z` branch.
+    *   Update `CHANGELOG.md` and version placeholders.
+    *   Create a Pull Request with these changes.
+
+2.  **Review and Merge**: Review, approve, and merge the generated Pull Request.
+    Once merged:
+    *   The **Release: Complete Prepare** workflow will automatically mark the
+        "Prepare Release" task as complete on the tracking issue checklist.
+    *   The **Release: Create Release Branch** workflow will then automatically
+        run (triggered by the issue edit) to cut the `release/X.Y` branch and
+        mark the "Create Release branch" task as complete.
+
+3.  **Tag Release Candidate (RC)**: Comment `/create-rc` on the tracking issue.
     This triggers the **Release: Create RC** workflow, which:
     *   Tags the release branch with `X.Y.Z-rcN`.
     *   Triggers the **Release: Publish** workflow to publish the release.
 
-6.  **Announce and Wait**: Announce the RC release (see [Announcing
+4.  **Announce and Wait**: Announce the RC release (see [Announcing
     releases](#announcing-releases)) and wait for feedback.
 
-7.  **Handle Backports (if needed)**: If bugs need to be fixed in the release:
+5.  **Handle Backports (if needed)**: If bugs need to be fixed in the release:
     *   Cherry-pick the fixes into the release branch (see [Patch release with
         cherry picks]).
     *   Add the backported PRs to the `## Backports` section of the tracking
         issue.
     *   Comment `/process-backports` on the tracking issue to update the checklist.
     *   Comment `/create-rc` again to tag a new RC (e.g. `rc1`).
 
-8.  **Final Release**: Once the RC is stable, promote it to final release by
+6.  **Final Release**: Once the RC is stable, promote it to final release by
     manually triggering the **Release: Promote RC** workflow from the GitHub
     Actions UI (or using `gh workflow run`), specifying the final version
     (e.g., `0.38.0`).