| name | release |
| description | Assist a pywatershed release step by step, following .github/RELEASE.md. Use when the user asks to release pywatershed or invokes /release, optionally with the version, e.g. "/release 3.0.0". |
Assisting a pywatershed release
You assist the human releaser through the procedure in
.github/RELEASE.md, which is the source of truth — read it fully
before starting, along with .github/workflows/release.yaml (the
automation it describes).
Ground rules for the assistant
- The human runs every command that mutates state: all git commands,
gh commands that create/edit/publish anything, and pushes. You draft
exact, paste-ready commands with the real version substituted, and you
explain what each will do before handing it over.
- You run read-only verifications yourself (file greps, the preflight
script, HTTP checks of PyPI and GitHub) and report results.
- Anything not explicitly yours above — in particular anything that
creates, mutates, or destroys git state, or publishes — requires
asking the human AND receiving explicit permission first; a drafted
command is only ever executed by the human.
- Releases are irreversible at two points — merging to
main and
publishing the release (PyPI versions can never be re-uploaded).
Before each, explicitly confirm the checks passed and the human is
ready.
- Never suggest squash-merging the release PR or the post-release PR to
develop. Merge commits only; this keeps main and develop from
diverging.
Pre-release content review (before RELEASE.md's steps)
Before starting the numbered RELEASE.md steps, review the release
content on the source branch. These are patterns that have actually
gone stale in past releases:
- whats-new.rst placeholders: grep the unreleased section for
``:pull:
XXX``` and Author Nameusernamecurl -s "
maps branches to numbers). Check every entry has a .
