Releasing mergify-cli — autonomous headless release agent

Global Rules

• Repo guard first: confirm git remote -v is Mergifyio/mergify-cli and the version scheme is CalVer (YYYY.M.D.N) targeting PyPI + Homebrew. If the repo uses semver/crates.io (e.g. a Rust workspace like lint-arwaky), stop — this skill does not apply; use that repo's own release process.
• This is an agent instruction, not a human runbook. Run every step end-to-end, stop only on hard failures, and report a final status at the end.
• The only step reported to the user and not executed is the Homebrew tap PR merge, which needs a human.
• Everything is driven by .github/workflows/release.yml. There is no version to bump in any file — pyproject.toml and Cargo.toml keep placeholder versions and the workflow stamps the tag at build time. The release prep PR commits the version stamp and changelog; it is not a manual edit of version files.
• Versions are calver: YYYY.M.D.N (no zero padding, N starts at 1 each UTC day).
• Never commit the version bump directly to main or push a release tag outside the prep PR flow. The prep PR (Step 1) is mandatory: CI must run green on the release branch before merge, and the tag is created only on the merge commit. Bypassing it ships an unverified release.
• Never run gh release create or push a tag by hand. A release created outside the workflow has no binaries, and once published it is immutable — the asset assertion then permanently blocks the PyPI publish for that version.
• Never click / script "Draft a new release" in the Releases UI. Same trap.
• Step 4 (Publish) is irreversible and outward-facing — it locks the release and pushes to PyPI. The headless flow proceeds straight to publish; this is the intended autonomous behavior, not a stop-and-ask step.
• RELEASING.md at the repo root explains why the flow is shaped this way (GitHub's immutable-releases policy). Read it when something goes wrong or the workflow itself needs changing.

Routing