release

Compétence Release

Un assistant de release léger et conscient du dépôt. Lors de sa première exécution, il inspecte le projet et le CI pour en déduire les règles de release, les stocke dans .omc/RELEASE_RULE.md pour une utilisation ultérieure, puis vous guide tout au long d'une release en respectant ces règles.

Utilisation

/oh-my-claudecode:release [version]

• version est facultative. Si omise, la compétence demandera. Accepte patch, minor, major ou une version semver explicite comme 2.4.0.
• Ajoutez --refresh pour forcer une nouvelle analyse du dépôt même si un fichier de règles en cache existe.

Déroulement

Étape 0 — Charger ou construire les règles de release

Vérifie si .omc/RELEASE_RULE.md existe.

S'il n'existe PAS (ou que --refresh a été passé) : Exécute l'analyse complète du dépôt ci-dessous et écrit le fichier.

S'il EXISTE : Lit le fichier. Effectue ensuite une vérification différentielle rapide — analysez .github/workflows/ (ou les répertoires CI équivalents : .circleci/, .travis.yml, Jenkinsfile, bitbucket-pipelines.yml, gitlab-ci.yml) pour détecter toute modification plus récente que l'horodatage last-analyzed dans le fichier de règles. Si des fichiers de workflow pertinents ont changé, relance l'analyse pour ces sections et met à jour le fichier. Signale ce qui a changé.

---

Étape 1 — Analyse du dépôt (première exécution ou --refresh)

Inspecte le dépôt et répond aux questions suivantes. Écrit les réponses dans .omc/RELEASE_RULE.md.

1a. Sources de version

• Localise tous les fichiers contenant une chaîne de version correspondant à la version actuelle dans package.json / pyproject.toml / Cargo.toml / build.gradle / fichier VERSION / etc.
• Liste chaque fichier ainsi que le champ ou l'expression régulière utilisé pour trouver la version.
• Détecte s'il existe un script d'automatisation de release (ex. scripts/release.*, cible Makefile release, bump2version, release-it, semantic-release, changesets, goreleaser).

1b. Registre / Distribution

• npm (package.json avec publishConfig ou npm publish dans CI), PyPI (pyproject.toml + twine/flit), Cargo (Cargo.toml), Docker (Dockerfile + étape de push), GitHub Packages, autres.
• Y a-t-il une étape CI qui publie automatiquement lors d'un push de tag ? Quel fichier workflow et quelle tâche ?

1c. Déclencheur de release

• Identifie ce qui déclenche la release : push de tag (v*), dispatch manuel (workflow_dispatch), merge sur main/master, merge de branche de release, motif de message de commit.

1d. Test gate

• Identifie la commande de test et où elle s'exécute dans le CI.
• Les tests doivent-ils réussir avant la publication ? Note tout indicateur de contournement.

1e. Notes de version / Changelog

• Un fichier CHANGELOG.md ou CHANGELOG.rst existe-t-il ?
• Quelle convention est utilisée : Keep a Changelog, Conventional Commits, auto-généré par GitHub, aucune ?
• Existe-t-il un fichier de corps de release (ex. .github/release-body.md) commité avant le tag ?

1f. Vérification pour les utilisateurs novices

• Un workflow de release existe-t-il dans .github/workflows/ (ou équivalent) ? Sinon, signale-le et propose d'en générer un.
• Y a-t-il une entrée dans .gitignore empêchant les artefacts de build d'être commités ? Sinon, signale-le.
• Les tags git sont-ils utilisés ? Exécute git tag --list pour vérifier. Si aucun tag n'existe, signale-le et explique la bonne pratique.

---

Étape 2 — Écrire .omc/RELEASE_RULE.md

Crée ou écrase le fichier avec cette structure :

# Règles de release
<!-- last-analyzed: AAAA-MM-JJTHH:MM:SSZ -->

## Sources de version
<!-- liste des fichiers + motifs -->

## Déclencheur de release
<!-- ce qui lance la release -->

## Test gate
<!-- commande + nom de la tâche CI -->

## Registre / Distribution
<!-- npm, PyPI, Docker, etc. + tâche CI qui publie -->

## Stratégie de notes de version
<!-- convention + fichiers -->

## Fichiers de workflow CI
<!-- chemins vers les fichiers workflow pertinents -->

## Lacunes de la configuration initiale
<!-- tout élément manquant détecté lors de l'analyse, ou "aucun" -->

---

Étape 3 — Déterminer la version

Si l'utilisateur a fourni un argument de version, utilise-le. Sinon :

1. Affiche la version actuelle (depuis le fichier de version principal).
2. Affiche ce que produiraient patch, minor et major.
3. Demande à l'utilisateur laquelle utiliser.

Valide que la version choisie est une chaîne semver valide.

---

Étape 4 — Liste de contrôle avant release

Présente une liste de contrôle dérivée des règles de release. Au minimum :

• Toutes les modifications destinées à cette release sont commitées et poussées
• Le CI est vert sur la branche cible
• Les tests passent localement (exécute la commande du test gate)
• L'incrémentation de version est appliquée à tous les fichiers sources de version
• Les notes de version / changelog sont préparés (voir Étape 5)

Demande à l'utilisateur de confirmer avant de continuer, ou exécute chaque étape s'il dit "vas-y".

---

Étape 5 — Guide pour les notes de version

Aide l'utilisateur à rédiger de bonnes notes de version. Applique la convention utilisée par le dépôt. Guide par défaut lorsqu'aucune convention n'est détectée :

Ce qui fait une bonne note de version :

• Commencez par ce qui a changé pour les utilisateurs, pas les détails d'implémentation internes.
• Groupez par type : Nouvelles fonctionnalités, Corrections de bugs, Changements cassants, Dépréciations, Interne / Tâches ménagères.
• Pour chaque élément : une phrase, lien vers la PR ou le problème, créditez l'auteur si externe.
• Les changements cassants passent en premier et doivent inclure un chemin de migration.
• Omettez les modifications que les utilisateurs ne voient jamais (refactoring, ajustements CI, modifications de tests uniquement) sauf si elles affectent la reproductibilité de la build.

Exemple de format d'entrée :

### Corrections de bugs
- Correction de la déconnexion de session à l'expiration du jeton (#123) — @contributeur

Si le dépôt utilise Conventional Commits, génère un projet de changelog à partir de git log <tag-précédent>..HEAD --no-merges --format="%s" groupé par type de commit. Montre-le à l'utilisateur et laisse-le modifier.

---

Étape 6 — Exécuter la release

En utilisant les règles découvertes, parcours :

1. Incrémenter la version — applique à chaque fichier source de version.
2. Exécuter les tests — exécute la commande du test gate.
3. Commiter — git add <fichiers de version> CHANGELOG.md et commiter avec chore(release): bump version to vX.Y.Z.
4. Tagger — git tag -a vX.Y.Z -m "vX.Y.Z" (les tags annotés sont préférés aux tags légers).
5. Pousser — git push origin <branche> && git push origin vX.Y.Z.
6. Le CI prend le relais — si le déclencheur de release est un push de tag, rappelle à l'utilisateur que le CI gérera le reste (publication, création de release GitHub). Montre le fichier workflow CI attendu.
7. Publication manuelle — si aucune automatisation CI n'existe, liste la commande de publication manuelle (ex. npm publish --access public, twine upload dist/*).

---

Étape 7 — Suggestions de configuration initiale

Si des lacunes ont été trouvées à l'Étape 1f, propose une aide concrète :

Aucun workflow de release :

Votre dépôt n'a pas de workflow CI de release. Un workflow GitHub Actions déclenché par un push de tag v* est la meilleure pratique la plus courante. Il peut :

• Exécuter les tests
• Publier sur npm/PyPI/etc.
• Créer une Release GitHub avec vos notes de version

Voulez-vous que je génère un .github/workflows/release.yml pour votre stack ?

Aucun tag git :

Il semble que ce soit la première release. Les tags git permettent à GitHub, npm et d'autres outils de comprendre votre historique de versions. Nous allons créer votre premier tag à l'Étape 6.

Artefacts de build non gitignorés :

Des artefacts de build sont présents dans l'historique git ou ne sont pas dans .gitignore. Cela gonfle la taille du dépôt et crée des conflits de merge. Voulez-vous que je les ajoute à .gitignore ?

---

Étape 8 — Vérification

Après le push :

• Vérifie le statut CI : gh run list --workflow=<workflow de release> --limit=3 (si gh est disponible).
• Vérifie le registre (npm, PyPI) pour la nouvelle version après quelques minutes.
• Confirme qu'une Release GitHub a été créée : gh release view vX.Y.Z.

Signale le succès ou tout échec.

---

Remarques

• Cette compétence ne code en dur aucun fichier de version ou commande spécifique au projet. Tout est dérivé de l'inspection du dépôt.
• .omc/RELEASE_RULE.md est un cache local. Commitez-le dans votre dépôt si vous souhaitez partager les règles dérivées avec votre équipe, ou ajoutez-le à .gitignore si vous préférez qu'il reste local.
• Pour les monorepos complexes ou les espaces de travail multi-packages, la compétence détectera les modèles d'espace de travail (npm workspaces, pnpm workspaces, Cargo workspace) et s'adaptera en conséquence.