/releasing-streamlit

name: releasing-streamlit
description: Runs a Streamlit core release (regular x.y.0 or patch x.y.z) from wiki/release-process.md, pausing at each human gate. Invoke explicitly with /releasing-streamlit <version>.
disable-model-invocation: true

Releasing Streamlit

Drive a core release with the user, following [`wiki/release-process.md`](../../../wiki/release-process.md). That runbook and the workflows in `.github/workflows/` are the source of truth. This skill adds how to drive them from an agent session: how to tell what is already done, when to ask, and where a human has to act.

**Usage:** `/releasing-streamlit <version>`, for example `/releasing-streamlit 1.67.0`. A patch version (`1.66.2`) runs the patch flow.

Read the runbook before the first step. If it disagrees with this skill, follow the runbook and tell the user this skill is out of date.

Work out the state first, every time

Start every invocation, and finish every step, by running the read-only status board:

uv run --no-project python .claude/skills/releasing-streamlit/scripts/release_status.py <version>

It derives each step's state from GitHub, PyPI, and the SiS asset CDN. Nothing is stored locally, so rerunning the skill after a break, a crash, or someone else's manual step resumes correctly. Trust the board over your memory of the conversation, and show it to the user so they can see where things stand.

• `✗` on any row means stop. Show the row and ask the user how to proceed. Do not repair state automatically: a contradictory state (a tag that is not at the branch head, a build running on an old commit) usually means someone acted by hand, and guessing can publish the wrong commit.
• `…` means a run is in flight. Attach to it and watch; never dispatch the same workflow again. On the branch, cherry-pick, and tag rows the API can't show which version a run is for, so open the link and check before acting.
• `»` means the next step needs a human or a source the script can't read. On the cherry-picks row before tagging, it lists what's on the branch so far; it is not a decision.
• `⚠` means the board can't confirm the step (a red nightly, a branch base that matches no nightly, a successful build PyPI doesn't show yet). Show the row and ask before acting on it.
• The script exits with code 2 if a lookup failed (network, `gh` auth, rate limit). Report it and retry later; do not read a failed lookup as "not done".
• The board enforces the runbook's "one release in the publish phase at a time": another open `release/*` PR is `⚠` on the tag row until this release has a branch, then `✗`.

Things the agent never does

These are irreversible or belong to a person, so they stay with the user even if the agent's credentials would allow them:

• Approve a deployment to the `release` environment. The second person's review is the release's independent check; an agent approving with someone's login defeats it.
• Post to Slack or reply on issues and forums. Draft the text instead.
• Set `dangerous_overwrite_existing_static_assets`, resolve a cherry-pick conflict, or work around a workflow's validation guard.

Asking the user

Use `AskUserQuestion` for every decision and every handoff. In tools without it, ask the same question with numbered options. Keep status updates (progress, check results) as plain text.

• Put the decision and its main risk in the question. Put the exact command and its effect in the option preview, so the user sees what they approve.
• Offer a "Pause here" option on handoffs. Pausing is safe because the next invocation rebuilds state from the board.
• Copy a draft to the clipboard only if the user picks that option. The prod static-assets job link in step 5 is the exception: always copy it.

Writes

Every write needs its own confirmation that names it: dispatching a workflow, submitting a Jenkins job, pushing or moving a tag, opening or merging a PR.

• The release workflows send Slack notifications when they run, so say so in the preview for any dispatch.
• Dispatch every workflow from `develop` except Build Release, which runs from the tag.
• The board's reads work on any `gh` account, but dispatches need write access to `streamlit/streamlit`. Check `gh auth status` before the first write, and switch accounts if needed.
• Offer `dry_run=true` first for the four workflows that have it, and say what it covers. Cherry-pick attempts the real pick and skips only the push, so it catches conflicts. Release branch and patch branch validate the inputs and check out the tag, but skip the branch script, so the version bump and `uv lock` don't run. Tag + PR validates the inputs, that the branch exists, and that the tag doesn't. No run of it checks for other open `release/*` PRs, so read the board's tag row before the real run.
• Recent `gh` versions print the run URL after `gh workflow run`; older ones print nothing. Either way, note the time just before dispatching and confirm the run by workflow, `event=workflow_dispatch`, your `gh` login, and a creation time after that timestamp. If it doesn't show up yet, poll again. Never dispatch a second time because the first run hasn't appeared.
• Confirm the result by its effect (the branch exists, the tag is at the branch head), not only by the run's conclusion. Print each run URL as soon as you find it, and each resulting branch, tag, or PR link as it appears.

Regular release steps

Step numbers match the runbook.

1. **Cutoff nightly.** Nightly tags are named for the day *before* the 04:30 UTC run, so the run on Nov 5 publishes `x.y.z.dev20261104`. 1. Confirm the nightly workflow is green. 2. For SiS e2e, read the jenkins bot posts in Slack `#e2e-tests-sis-oss` (through Glean if available) for runs after the nightly published. Read the `Run`/`Passed` counts, not the PASSED/FAILED header, which has said PASSED at 1/5, and note if the suite has shrunk. If no run has covered the nightly yet, ask whether to wait, use the previous nig