Our review
Creates a professional release using GitHub CLI with automatic versioning based on conventional commits.
Strengths
- Automated SemVer bump based on commit history
- Risk review for breaking changes
- Clean grouping of release notes
- Safety via draft release mode
Limitations
- Requires `gh` installed and authenticated
- Depends on conventional commit analysis
- Does not execute the command, only provides it
When you need to create a GitHub release with proper versioning and changelog.
If the repository does not follow conventional commits or if you want to publish immediately without review.
Security analysis
SafeThe skill provides a guided workflow for creating a GitHub release using gh CLI, with explicit instructions not to execute the command automatically and to use --draft for safety. It does not involve any destructive actions, data exfiltration, or bypassing of safety measures.
No concerns found
Examples
Create a patch release for this repository.Analyze commits and create a minor release using GitHub CLI.Prepare a major release v2.0.0 with draft mode and risk review.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:
- Initial validations
- Verify the repo is a clean Git repository (no uncommitted changes).
- Check that
ghis installed and authenticated. - Detect the latest existing tag (SemVer).
- Flag if there are no previous tags or if versioning is inconsistent.
- 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
- Analyze commits since the last tag:
- Clearly explain why you choose that version.
- 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.).
- Risk review
- Flag:
- Potentially breaking changes
- Required migrations
- Flags, configs, or manual post-release steps
- If high risks detected, warn explicitly before continuing.
- Tag and Release creation
- Generate the exact
gh release createcommand:- Include tag, title, and notes
- Use
--draftby default - IMPORTANT:
gh release createautomatically 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.
Docker Compose Architect
DevOps
Designs optimized Docker Compose configurations.
Incident Postmortem Writer
DevOps
Writes structured and blameless incident postmortem reports.
Runbook Creator
DevOps
Creates clear operational runbooks for common DevOps procedures.