rhiza-release

Portable copy of plugin/skills/release/SKILL.md, generated by plugin/scripts/build_bundle.py. Edit the source and run make bundle — an edit here is overwritten.

• ${RHIZA_ROOT} is your rhiza-claude checkout. Export it, or substitute the path wherever it appears. Any remark below about the variable being empty in a source checkout is Claude Code's spelling of the same idea — ${RHIZA_ROOT} replaces it, and the repo-relative fallbacks do not apply, because you are working in the user's repo, not in this one.
• /rhiza:<name> names another skill in this bundle, rhiza-<name>. Invoke it however your client invokes skills.
• Tools. Read, Edit and Write read and write files; Grep and Glob search; Bash is a shell in the user's repo. Use your equivalents.
• AskUserQuestion is a multiple-choice question put to the user. With no such tool, ask in plain text, number the options, and wait for a reply: where the procedure says nothing is created without an explicit selection, that holds however the question was asked.
• Arguments: [version e.g. v1.4.0] (optional; omit to pick from a table of candidates). The text below writes $ARGUMENTS for what the user passed; substitute it yourself if your client does not.
• Runs: git, gh, glab, uv, uvx, make, cat, grep. Nothing here enforces that list, where the plugin's frontmatter did — your client has to permit them.
• Never run this on your own initiative — only when the user asks for it by name.

You are running /release in the current working directory's repo. Goal: land the version bump on the default branch through a pull request, like every other change, and tag the commit that actually merged — in one run.

A tag still cannot be cut before the merge, which is why there is a wait in the middle. A tag must point at a commit that exists on the branch you publish from; a squash-merge replaces the branch's commits with a new one, so a tag created before the merge names a SHA that never lands. No reordering of the steps fixes that — the commit to tag does not exist until the request merges. So the run goes through the merge instead of stopping in front of it: it hands the merge to the forge, waits for the bump to appear on the default branch, and tags what landed.

phase A and phase B — what step 1a's script reports — name the repo's state, not two runs of this command. Phase A is "nothing pending"; phase B is "a bump is committed that no tag names". An ordinary run starts in A, and steps 10–11 are what put the repo into B; step 12 then tags it. A run that starts in B is one finishing a release whose wait had expired.

The wait can time out, and then the run hands back rather than half-finishing. Review takes as long as it takes and a session does not outlive a weekend; when the wait expires the run reports the open PR and stops, having created no tag. Re-running /rhiza:release finishes the release — step 1a reports phase B and goes straight to step 12. That is not a special case: it is steps 12–13 entered later, and it is why an expired wait leaves nothing to undo.

Never push to the default branch, and never move an existing tag. The run pushes one release branch — the same thing /rhiza:init and /rhiza:update do — and then one tag, onto the commit the forge merged.

The human decision is the version; the checks are the gate. Step 3 stops and makes a person choose the bump, because that is the judgement nothing here can make. What follows is mechanical, so the run carries it through rather than handing back a command to re-type. What keeps that safe is not a second pair of hands, it is step 12's guard: a version that does not strictly increase, or a tag that already exists, stops the run before anything is created. If anything is ambiguous, stop and report.