Mariadb Operator Release Notes
Create the release notes and upgrade guide for a mariadb-operator release.
Install
npx skills add mariadb-operator/mariadb-operator --skill mariadb-operator-release-notes -g -a claude-code -y- Repository
- mariadb-operator/mariadb-operator1k
- Category
- Git and review
- Updated
- 10d ago
- License
- Apache-2.0
- Context cost
- Mediumabout 2,964 tokens
- Runs scripts
- No, instructions only
What it does
Create the release notes and upgrade guide for a mariadb-operator release. Given the release PR whose body lists every PR included in the release, it gathers each PR, groups the changes by relevance, and produces `docs/releases/RELEASE_<version>_HEADER.md.gotmpl` and `docs/releases/UPGRADE_<version>.md` in the format the previous releases use, then opens a PR targeting `release-<version>`. If no release PR is provided it asks for the new version and infers the changes from git history since the last tag. Use whenever the user wants release notes, an upgrade/update guide, or docs for a new mariadb-operator version, "create the release notes for 26.10.0", "write the upgrade guide", "document this release", "prepare the release PR docs", even if they don't mention a release PR.
mariadb-operator Release Notes
Produce the two release documentation artifacts for a new version and deliver them as a PR against the release branch:
docs/releases/RELEASE_<version>_HEADER.md.gotmpl, the release notes headerdocs/releases/UPGRADE_<version>.md, the upgrade guide
How release notes are built
.github/workflows/release.yml runs goreleaser on the release tag. It looks for
docs/releases/RELEASE_${VERSION}_HEADER.md.gotmpl (falling back to the generic
RELEASE_HEADER.md.gotmpl) and prepends its rendered content to the auto-generated "What's Changed"
changelog. Consequences:
- The filename must match the tag exactly: tag
26.10.0→RELEASE_26.10.0_HEADER.md.gotmpl. - The header is a template: use
{{ .ProjectName }}for the project name, never hardcode it. - Do not write a full commit/PR changelog in the header, goreleaser appends the complete one. The header carries the narrative: highlights grouped into sections, each item linking its PR.
- Verify the exact tag-to-file lookup in
.github/workflows/release.ymlbefore relying on it.
GitHub credentials
All GitHub calls in the Step sections below use the project-scoped GitHub MCP tools
(mcp__github-mariadb-operator__*). If that server isn't connected, fall back in order: gh CLI with the
project token (GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh ..., not the ambient gh auth session), then the
generic mcp__github__* tools, then plain gh auth.
Step 0, Gather the input
Preferred input: the release PR. The user provides the release PR (titled Release <version>, head branch
release-<version>, base main). Its body is the ordering and scope authority: it lists every PR in the
release, typically grouped by where it merged ("merged into main", "merged into this branch").
Fetch it with the GitHub MCP server:
