docs(release): add a maintainer skill for cutting a release - #1795
Conversation
Merge Protections🔴 3 of 7 protections blocking · waiting on 👀 reviews and ⛓️ dependency
🔴 ⛓️ Depends-On RequirementsWaiting for
This rule is failing.Requirement based on the presence of
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
Show 4 satisfied protections🟢 🤖 Continuous Integration
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
There was a problem hiding this comment.
🟢 Approval recommended
The change is isolated to documentation for maintainer operations and matches the referenced workflow structure without introducing code risk.
Pull request overview
Adds an agent-facing “releasing” skill runbook under .claude/skills/ that mirrors the existing human-driven RELEASING.md workflow, focusing on driving the two-stage GitHub Actions release process via gh while emphasizing safety guardrails around draft vs publish.
Changes:
- Introduces a new maintainer skill document for cutting a release using
ghcommands (pre-flight checks, stage 1 draft, stage 2 publish). - Documents irreversible vs repeatable steps and enforces an explicit “go-ahead” before publishing.
- Adds post-publish verification steps, including the Homebrew tap sync PR flow.
File summaries
| File | Description |
|---|---|
| .claude/skills/releasing/SKILL.md | Adds the agent-oriented release runbook (commands, guardrails, verification, recovery) aligned with the release.yml workflow. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
`RELEASING.md` documents the two-stage flow for a human driving the Actions UI. This adds the agent-facing counterpart: the `gh` commands for each stage, the pre-flight checks, and the guardrails. It lives in `.claude/skills/`, not the published `skills/` tree — that one ships as the `mergify` plugin for CLI users, where a runbook for releasing *this* repo would fire on anyone asking to release their own project. Content beyond what `RELEASING.md` already covers: - Up front: there is no version to bump in any file, so no "release prep" PR. The workflow stamps the tag at build time. - Pre-flight: main is green, no leftover draft, what ships since the last tag. - Stage 2 is irreversible and outward-facing (immutable release, PyPI push), so the skill stops after the draft and requires an explicit go-ahead. Stage 1 is marked safe and repeatable. - Post-publish verification of the Homebrew tap, which was undocumented: the `homebrew-tap-sync` workflow in `Mergifyio/mergify-ci-bot` opens a formula-bump PR against `Mergifyio/homebrew-tap` within ~20 min of publish, and it still needs a human to merge. The why — GitHub's immutable-releases policy and the reason stage 1 runs from `workflow_dispatch` — stays in `RELEASING.md`, which the skill points at, so the two can't drift on the rationale. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVKnCd4MKakhVJJiJTfZcD Change-Id: I588ca3b86af6143c8440af6cab0b968f80e1a0f7
7805be8 to
7e8ce16
Compare
|
This pull request is part of a Mergify stack:
|
Revision history
|
|
Rebased onto #1796, which sits below this one in the stack now. The diff here is unchanged ( Why: |
RELEASING.mddocuments the two-stage flow for a human driving theActions UI. This adds the agent-facing counterpart: the
ghcommandsfor each stage, the pre-flight checks, and the guardrails.
It lives in
.claude/skills/, not the publishedskills/tree — thatone ships as the
mergifyplugin for CLI users, where a runbook forreleasing this repo would fire on anyone asking to release their own
project.
Content beyond what
RELEASING.mdalready covers:prep" PR. The workflow stamps the tag at build time.
last tag.
push), so the skill stops after the draft and requires an explicit
go-ahead. Stage 1 is marked safe and repeatable.
the
homebrew-tap-syncworkflow inMergifyio/mergify-ci-botopens aformula-bump PR against
Mergifyio/homebrew-tapwithin ~20 min ofpublish, and it still needs a human to merge.
The why — GitHub's immutable-releases policy and the reason stage 1 runs
from
workflow_dispatch— stays inRELEASING.md, which the skillpoints at, so the two can't drift on the rationale.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01RVKnCd4MKakhVJJiJTfZcD