release-notes
Create release notes for a new version tag. Gathers all commits, PRs, issues fixed, and breaking changes since a previous release. Creates the release notes markdown file, tags the repo, and pushes. Asks the user to confirm the base version to diff against.
Profile →npx skills add agentic-community/mcp-gateway-registry --skill release-notes --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Creates release notes for a new version tag by gathering commits, PRs, issues fixed, and breaking changes since a base release. Writes a release-notes markdown file under docs/release-notes/{version}.md, tags the repo, and pushes. Prompts user to confirm the base version to diff against.
How it works
- Takes a version input in the format major.minor.patch (bare semver, no v prefix).
- If a v-prefixed version is provided, it strips the prefix and confirms.
- Verifies the tag does not already exist; if it exists, asks whether to move or choose a different version.
- Lists existing release notes and git tags to determine the most recent base version and asks the user to confirm the base version (most recent tag as recommended; 2-3 previous tags as alternatives).
- Gathers changes between base and HEAD via multiple git commands and gh pr view invocations to compile commits, non-merge commits, merge commits, authors, environment variable changes, and chart changes.
- Categorizes changes into Major Features, Breaking Changes, New Environment Variables, Bug Fixes, Security Fixes, Infrastructure/Helm Changes, Dependency Updates, Documentation, Closed Issues, and Contributors.
- Writes the release notes to docs/release-notes/{version}.md following the project’s structure and includes relevant PR references, changelog sections, and contributor mappings.
- Provides a summary ready for user review and awaits approval before finalizing.
When to use it
- Use when preparing a release for a new version tag to generate standardized release notes.
What it can touch
- Documentation: creates docs/release-notes/{version}.md
- Git: tags the repo with {version}
- External tools: gh (GitHub CLI) to fetch PR data and issue data
Caveats
- Requires running the pre-release smoke test gate, base tag verification, and user confirmation steps as defined in the workflow.
- Outputs rely on the presence of PRs and issues closed within the release window; de-duplication and username resolution depend on gh pr view results and Git history.
Full summary of changes and contributors is embedded in the generated release notes file and presented to the user for review.
# Release Notes Skill Use this skill when the user wants to create release notes for a new version. This skill gathers all changes since a previous release, writes structured release notes following the project's established format, tags the repo, and pushes. ## Input The skill takes a version tag as input: - Format: `{major}.{minor}.{patch}` (e.g., `1.24.0`) - **no `v` prefix**, semver only - Older releases (pre-`1.23.0`) used a `v` prefix (e.g., `v1.0.22`) - existing artifacts under `docs/release-notes/v*.md` and tags `v1.0.x` are preserved as-is, but **new releases must use the bare-semver convention** - If the user provides a `v`-prefixed version for a new release, strip the prefix and confirm ## Output Creates a release notes file in `docs/release-notes/` and tags the repo: - `docs/release-notes/{version}.md` - Release notes markdown file (e.g., `docs/release-notes/1.24.0.md`) - Git tag `{version}` pointing to the commit that includes the release notes ## Workflow ### Step 0: Confirm the Pre-Release Smoke Test Was Run (Gate) Before doing any release-notes work, confirm the end-to-end release smoke test ([tests/e2e_release_test.py](../../../tests/e2e_release_test.py)) has been
- Input
- Output
- Workflow
- Step 0: Confirm the Pre-Release Smoke Test Was Run (Gate)
- Step 1: Determine the New Version Tag
- Step 2: Determine the Base Version (Ask User to Confirm)
- Step 3: Gather All Changes Between Base and HEAD
- Step 4: Categorize Changes
- Step 5: Write Release Notes
- Step 6: Present Draft for User Review
- Step 7: Commit, Tag, and Push
- Important Rules
- Example Usage
uv run python tests/e2e_release_test.py --token-file .token --registry-url http://localhost
uv run python tests/e2e_release_test.py \
ls docs/release-notes/*.md
git tag --sort=-v:refname | grep -E '^v?[0-9]+\.[0-9]+\.[0-9]+'
All commits (including merges) between base and HEAD
git log {base_tag}..HEAD --oneline
Non-merge commits only (for detailed change analysis)
git log {base_tag}..HEAD --oneline --no-merges
Merge commits (to extract PR numbers)
git log {base_tag}..HEAD --oneline --grep="Merge pull request"What does the release-notes skill do?
Create release notes for a new version tag. Gathers all commits, PRs, issues fixed, and breaking changes since a previous release. Creates the release notes markdown file, tags the repo, and pushes. Asks the user to confirm the base version to diff against.
How do I install it?
Run `npx skills add agentic-community/mcp-gateway-registry --skill release-notes --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From agentic-community/mcp-gateway-registry, a repository with 862 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.