Invoking product-manager agent to drive the Gum release checklist.
Gum Release Orchestrator
This skill is a guided checklist driver, not full automation. Most release steps are inherently human — taking screenshots, clicking GitHub Actions, uploading to FTP, announcing on Discord/Twitter/Bluesky. The skill's job is to walk the maintainer through the steps in order, track what's done, and invoke the one step a skill can actually do (the notes draft).
Source of truth — do not restate it here
The release process lives in docs/contributing/building-and-releasing-gum.md (published to the Gum GitBook space). That doc is canonical and maintainer-edited. Read it at the start of every run and follow whatever it says today — do not hardcode or paraphrase its steps into this skill, or the two will drift.
How to run
- Read the doc above and confirm the current step list with the user.
- Ask if this is a hotfix — an emergency tool release for a bad bug, outside the normal cadence. If yes, follow the doc's "Hotfixes" subsection: skip
gum-monthly-release (write a short manual note instead), skip screenshots and community announcements, and confirm with the user that the fix carries no breaking changes before tagging.
- Track progress — create one task per step (
TaskCreate) so nothing is dropped across the long-running release, and mark each completed as the user confirms it. For a hotfix, only create tasks for the steps that apply.
- Walk the steps in order, one at a time. For each, state what the user needs to do (the doc has the detail) and wait for confirmation before advancing.
- Hand off the automatable step (non-hotfix only). Release-notes generation is the only step with real automation, and it lives in
gum-monthly-release. That skill is disable-model-invocation: true, so the Skill tool refuses it — read .claude/skills/gum-monthly-release/SKILL.md and follow it yourself instead. Everything else (NuGet workflow trigger, Build-and-Release workflow, screenshots, migration doc, announcements, FRB FTP upload) is the user's manual action; you confirm and check it off.
Gotchas
- The two processes in the doc — NuGet publishing and tool release — are independent. Ask which the user is doing; don't assume both.
- A hotfix is a mode of the tool release, not a separate process — same steps, minus notes/promotion. Don't run
gum-monthly-release for one.
gum-monthly-release only writes the notes markdown. It does not bump versions, cut the tag, or trigger workflows — those are separate manual steps in the doc.- The Full Changelog compare link in the notes can only be filled after the tag exists, so it stays a placeholder until the release is cut.
1---2name: gum-release3description: Invoking product-manager agent to drive the Gum release checklist.4---56Invoking product-manager agent to drive the Gum release checklist.78# Gum Release Orchestrator910This skill is a **guided checklist driver, not full automation.** Most release steps are inherently human — taking screenshots, clicking GitHub Actions, uploading to FTP, announcing on Discord/Twitter/Bluesky. The skill's job is to walk the maintainer through the steps in order, track what's done, and invoke the one step a skill can actually do (the notes draft).1112## Source of truth — do not restate it here1314The release process lives in **[`docs/contributing/building-and-releasing-gum.md`](../../../docs/contributing/building-and-releasing-gum.md)** (published to the Gum GitBook space). That doc is canonical and maintainer-edited. **Read it at the start of every run** and follow whatever it says *today* — do not hardcode or paraphrase its steps into this skill, or the two will drift.1516## How to run17181. **Read the doc** above and confirm the current step list with the user.192. **Ask if this is a hotfix** — an emergency tool release for a bad bug, outside the normal cadence. If yes, follow the doc's "Hotfixes" subsection: skip `gum-monthly-release` (write a short manual note instead), skip screenshots and community announcements, and confirm with the user that the fix carries no breaking changes before tagging.203. **Track progress** — create one task per step (`TaskCreate`) so nothing is dropped across the long-running release, and mark each `completed` as the user confirms it. For a hotfix, only create tasks for the steps that apply.214. **Walk the steps in order**, one at a time. For each, state what the user needs to do (the doc has the detail) and wait for confirmation before advancing.225. **Hand off the automatable step (non-hotfix only).** Release-notes generation is the only step with real automation, and it lives in **`gum-monthly-release`**. That skill is `disable-model-invocation: true`, so the `Skill` tool refuses it — read `.claude/skills/gum-monthly-release/SKILL.md` and follow it yourself instead. Everything else (NuGet workflow trigger, Build-and-Release workflow, screenshots, migration doc, announcements, FRB FTP upload) is the user's manual action; you confirm and check it off.2324## Gotchas2526- The two processes in the doc — **NuGet publishing** and **tool release** — are independent. Ask which the user is doing; don't assume both.27- A hotfix is a mode of the tool release, not a separate process — same steps, minus notes/promotion. Don't run `gum-monthly-release` for one.28- `gum-monthly-release` only writes the notes markdown. It does **not** bump versions, cut the tag, or trigger workflows — those are separate manual steps in the doc.29- The **Full Changelog** compare link in the notes can only be filled after the tag exists, so it stays a placeholder until the release is cut.
vchelaru