Gestionnaire de Release GitHub

VérifiéSûr

Crée une release professionnelle avec GitHub CLI en respectant SemVer. Génère les notes de release et fournit une commande prête à exécuter.

Spar Skills Guide Bot
DevOpsIntermédiaire
3002/06/2026
Claude Code
#release#github-cli#semver#versioning

Recommandé pour

Notre avis

Génère une publication professionnelle via GitHub CLI en déterminant la version SemVer et en produisant des notes de version structurées.

Points forts

  • Automatise le calcul de version à partir des commits
  • Produit des notes de version organisées par catégories
  • Inclut une revue des risques avant publication
  • Génère une commande prête à copier-coller

Limites

  • Nécessite que gh soit installé et authentifié
  • Ne publie pas automatiquement (mode brouillon par défaut)
  • Dépend de la qualité des messages de commit pour l'analyse
Quand l'utiliser

Idéal pour standardiser et sécuriser le processus de mise en production d'un dépôt Git hébergé sur GitHub.

Quand l'éviter

À éviter si le dépôt n'utilise pas GitHub ou si vous préférez une publication automatisée via CI/CD sans validation manuelle.

Analyse de sécurité

Sûr
Score qualité92/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.

Aucun point d'attention détecté

Exemples

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.
Skills similaires