Préparation de version

VérifiéPrudence

Préparation générique de version : génération de changelog, mise à jour de version, création de tag. Pour les projets non EvoNexus.

Spar Skills Guide Bot
DevOpsIntermédiaire
23/07/2026
Claude Code
#release-management#changelog#semver#git-tagging#versioning

Recommandé pour

Synthèse automatique

Prépare une release générique : génération du changelog depuis git log, bump de version semver et création du tag Git.

Points forts

  • Découpe le processus en six phases explicites, de la pré-vérification à la vérification finale
  • Détermine le type de bump semver en lisant le manifeste du projet (package.json, Cargo.toml, go.mod, pyproject.toml)
  • Regroupe les commits conventionnels par type pour un changelog structuré
  • Contrôle l'état de la branche, l'arbre de travail propre et le CI vert avant toute modification

Limites

  • Suppose des commits conventionnels pour un regroupement optimal du changelog
  • Dépend de skills externes (@oath-verifier, @flow-git, dev-verify) qui doivent être disponibles
  • Exclut explicitement les releases EvoNexus, qui relèvent de custom-release
Quand l'utiliser

À utiliser pour publier une nouvelle version d'un projet non-EvoNexus maintenu dans workspace/projects/, avec un workflow semver standard.

Quand l'éviter

Ne pas l'utiliser pour une release d'EvoNexus ou pour un projet disposant déjà de son propre processus de release personnalisé.

Analyse de sécurité

Prudence
Score qualité78/100

The skill is a conventional release workflow: inspect git history, edit manifest/CHANGELOG, commit, tag, and push. It uses powerful tools (git, network push) but only for their intended purpose, and it explicitly gates the push on user confirmation. No curl|sh, no rm -rf, no credential/token harvesting, no decoded payloads, and no attempt to bypass safety. Risk is limited to ordinary version-control side effects, so 'caution' rather than 'safe' or 'risky'.

Points d'attention
  • •Uses git commands including commit, tag, and push to origin (network write) after user confirmation
  • •References git log/manifest reading — read-only, but operates inside a real repo
  • •No destructive commands, no secret exfiltration, no obfuscation
Comment cette analyse est faite

Exemples

Release patch d'une librairie
Prépare la release patch de la librairie Evolution API : génère le changelog depuis le dernier tag, bump la version dans package.json et crée le tag.
Changelog depuis les commits
Génère un CHANGELOG.md pour Evo Go en regroupant les commits conventionnels depuis le dernier tag, puis propose le type de bump semver.
Pré-vol avant tag
Vérifie que je suis sur la bonne branche, que l'arbre de travail est propre et que le CI est vert avant de préparer la release v1.4.0 de Evo AI.

name: dev-release description: Release preparation — changelog generation, version bump, tag creation. Generic version (not project-specific). For EvoNexus releases, use custom-release instead.

Dev Release

Derived from oh-my-claudecode (MIT, Yeachan Heo). Adapted for the EvoNexus Engineering Layer.

Generic release preparation: changelog generation from git log, version bump, tag creation. For EvoNexus-specific releases, use custom-release (the existing skill that handles git-flow develop→main).

Use When

  • Releasing a non-EvoNexus project (Evolution API, Evo AI, Evo Go, etc.)
  • Generic semver bump on a library you're maintaining

Do Not Use When

  • Releasing EvoNexus itself → use custom-release instead
  • Project has its own custom release process → follow that

Workflow

Phase 1 — Pre-flight

  • Verify on the right branch (not main/master directly)
  • Verify clean working tree (no uncommitted changes)
  • Verify CI is green on the target commit
  • Verify tests pass locally (dev-verify)

Phase 2 — Determine version

  • Read current version from manifest (package.json, Cargo.toml, go.mod, pyproject.toml)
  • Determine bump type: major / minor / patch (semver)
  • Confirm with user

Phase 3 — Generate changelog

  • Read commits since last tag: git log {last-tag}..HEAD --oneline
  • Group by type (feat / fix / docs / etc.) if conventional commits
  • Save to CHANGELOG.md with new version section

Phase 4 — Bump version

  • Update manifest file
  • Update any version references in docs

Phase 5 — Commit and tag

  • git commit -m "chore(release): vX.Y.Z"
  • git tag vX.Y.Z
  • git push origin vX.Y.Z (after user confirmation)

Phase 6 — Verify

  • @oath-verifier confirms the release commit and tag are correct

Output

Save release notes to workspace/development/research/[C]release-{version}-{date}.md.

Pairs With

  • @flow-git (commits and tags)
  • @oath-verifier (verification)
  • @quill-writer (changelog formatting)
  • dev-verify (pre-flight)

EvoNexus-Specific Note

EvoNexus has its own release skill (custom-release) that handles the git-flow develop→main workflow with EvoNexus-specific gates (CHANGELOG entry, version sync across files, GitHub release creation). Use custom-release for EvoNexus releases. Use dev-release only for projects in workspace/projects/ that have their own release lifecycle.

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/dev-release-mrx3xzs8/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/dev-release-mrx3xzs8' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/dev-release-mrx3xzs8/download' --output '.skill-downloads/dev-release-mrx3xzs8/SKILL.md.part' && mv '.skill-downloads/dev-release-mrx3xzs8/SKILL.md.part' '.skill-downloads/dev-release-mrx3xzs8/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/dev-release-mrx3xzs8/SKILL.md' && test -s '.skill-downloads/dev-release-mrx3xzs8/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/dev-release' && cp -R '.skill-downloads/dev-release-mrx3xzs8' '.claude/skills/dev-release'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/dev-release-mrx3xzs8'

openskills read 'dev-release-mrx3xzs8'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/dev-release-mrx3xzs8/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires