GitHub Release Manager

VerifiedSafe

Creates a professional GitHub release with SemVer compliance. Generates release notes and provides a ready-to-run gh command.

Sby Skills Guide Bot
DevOpsIntermediate
206/2/2026
Claude Code
#release#github-cli#semver#versioning

Recommended for

Our review

Creates a professional release using GitHub CLI by determining the SemVer version and generating structured release notes.

Strengths

  • Automates version calculation based on commit history
  • Produces categorized release notes for clarity
  • Includes a risk review before finalizing the release
  • Outputs a copy-paste ready command

Limitations

  • Requires gh to be installed and authenticated
  • Does not publish automatically (uses draft mode)
  • Relies on commit message quality for accurate analysis
When to use it

Best for standardizing and securing the release process for a GitHub-hosted repository.

When not to use it

Not suitable if the repository is not on GitHub or if you prefer fully automated CI/CD releases without manual review.

Security analysis

Safe
Quality score92/100

The skill only instructs the model to generate a safe, draft release command using gh, with clear warnings and no execution. No tools are called, and the command is not automatically executed.

No concerns found

Examples

Create a patch release
Create a patch release for this repository
Bump to major version and generate notes
Create a major release with release notes from the commits since last tag
Infer version automatically
Create a release for this repository, inferring the version from commit history

name: release description: Create a professional release using GitHub CLI (gh). Generate SemVer version, clear release notes, and ready-to-run command. argument-hint: "[major|minor|patch|explicit version] (optional)" disable-model-invocation: true

Act as a Release Manager + Senior Engineer with experience in professional release workflows and production repositories.

Your goal is to create a release of the current repository using GitHub CLI (gh), in a safe, clear, and reproducible way.

Input:

  • $ARGUMENTS can be:
    • "major", "minor", or "patch" (SemVer)
    • An explicit version (e.g., v1.4.2)
    • Empty → automatically infer the correct bump

Process to follow:

  1. Initial validations
  • Verify the repo is a clean Git repository (no uncommitted changes).
  • Check that gh is installed and authenticated.
  • Detect the latest existing tag (SemVer).
  • Flag if there are no previous tags or if versioning is inconsistent.
  1. Version determination
  • Use SemVer strictly.
  • If the argument is:
    • major → increment MAJOR
    • minor → increment MINOR
    • patch → increment PATCH
    • explicit version → validate format (vX.Y.Z)
  • If no argument:
    • Analyze commits since the last tag:
      • BREAKING CHANGE → major
      • feat → minor
      • fix / perf / refactor → patch
  • Clearly explain why you choose that version.
  1. Release notes generation
  • Summarize changes since the last tag.
  • Group into sections:
    • 🚀 Features
    • 🐛 Fixes
    • 🛠 Refactors / Maintenance
    • ⚠️ Breaking Changes (if applicable)
  • Use clear and technical language.
  • Avoid noise (trivial commits, formatting, etc.).
  1. Risk review
  • Flag:
    • Potentially breaking changes
    • Required migrations
    • Flags, configs, or manual post-release steps
  • If high risks detected, warn explicitly before continuing.
  1. Tag and Release creation
  • Generate the exact gh release create command:
    • Include tag, title, and notes
    • Use --draft by default
    • IMPORTANT: gh release create automatically creates the Git tag when executed
  • Example: gh release create vX.Y.Z --title "vX.Y.Z" --notes "<release notes>" --draft

DO NOT execute the command. Deliver the command ready to copy/paste.

Note: The tag will be created automatically when the release is published (or when draft is created if using --draft).

Output format:

A) SUMMARY

  • Last version:
  • Proposed new version:
  • Release type:
  • Risk: Low / Medium / High

B) RELEASE NOTES <full text>

C) GH COMMAND <exact command>

D) TAG CREATION Explain that the tag (vX.Y.Z) will be created automatically when running the gh command above.

Rules:

  • Don't publish the release automatically (use --draft).
  • Don't invent changes: if there are doubts, indicate them.
  • Prioritize clarity and safety over speed.
  • Always explain that the Git tag will be created automatically by gh release create.
  • Include verification step: after creating draft, user should verify tag was created with git tag -l.
Related skills