Commande /changelog pour rédiger vos notes de version

---
description: Rédige une entrée de changelog à partir des commits depuis le dernier tag
argument-hint: "[version]"
allowed-tools: Bash(git log *) Bash(git describe *)
---
 
## Contexte
 
Dernier tag : !`git describe --tags --abbrev=0 || true`
 
Derniers commits (les tags apparaissent entre parenthèses) :
 
!`git log -n 60 --decorate --pretty=format:'- %s (%h)%d'`
 
## Tâche
 
Ne retiens que les commits postérieurs au dernier tag (tous les commits
affichés s'il n'y a aucun tag).
 
Rédige l'entrée de changelog de la version $ARGUMENTS (si vide, propose un
numéro de version en expliquant ton choix).
 
- Regroupe les changements en sections : **Ajouts**, **Corrections**,
  **Modifications**, **Suppressions** (omets les sections vides).
- Reformule chaque commit en une phrase compréhensible par un utilisateur,
  pas par un développeur ; fusionne les commits qui portent sur le même sujet.
- Ignore les commits purement techniques (formatage, CI, dépendances de dev)
  sauf s'ils changent le comportement.
- Signale en tête tout changement incompatible avec la version précédente.
- Ajoute la date du jour au format AAAA-MM-JJ.
 
Affiche l'entrée proposée, puis demande confirmation avant de l'insérer en
haut de `CHANGELOG.md`.

Un fichier Markdown placé dans .claude/commands/ crée une commande slash du même nom : changelog.md devient /changelog. Ce modèle récupère l'historique Git récent, puis demande à Claude de le transformer en une entrée de changelog lisible par des utilisateurs, groupée par type de changement.

Commandes et skills

La documentation officielle indique que les commandes personnalisées ont été fusionnées avec les skills : un fichier .claude/commands/changelog.md et une skill .claude/skills/changelog/SKILL.md produisent la même commande /changelog. Le format commands/ reste pris en charge et accepte le même frontmatter que les skills, à l'exception des champs name et paths. Pour un nouveau projet, une skill offre davantage (fichiers annexes dans le dossier, chargement automatique) ; une commande reste la solution la plus simple pour un prompt d'une page.

Anatomie du fichier

• description : le texte affiché dans le menu des commandes.
• argument-hint : [version], récupéré dans le corps par $ARGUMENTS.
• allowed-tools : autorise git log et git describe sans confirmation.
• Les lignes de la forme !`commande` sont exécutées avant l'envoi du prompt : leur sortie remplace le marqueur. Claude reçoit donc directement le dernier tag et la liste des commits.

Installation et utilisation

1. Placez le fichier dans .claude/commands/ (partagé avec l'équipe) ou ~/.claude/commands/ (personnel).
2. Tapez /changelog 2.4.0 : Claude propose l'entrée, puis demande confirmation avant de modifier CHANGELOG.md.

Comment l'adapter

• Remplacez les sections (Ajouts, Corrections…) par le format de votre projet, par exemple celui de « Keep a Changelog ».
• Si vos commits suivent une convention (préfixes feat:, fix:), dites-le pour que le classement s'appuie dessus.
• Ajustez le nombre de commits récupérés (-n 60) à votre rythme de publication.

Pièges fréquents

• Commande injectée qui échoue : si une commande !`…` renvoie un code d'erreur, toute l'invocation est annulée. D'où le || true après git describe, qui échoue dans un dépôt sans tag.
• Permissions : une commande injectée qui ne correspond à aucune règle d'autorisation fait échouer l'invocation (hors mode auto) ; c'est le rôle de allowed-tools. Une règle deny l'emporte toujours.
• Messages de commit pauvres : « fix » ou « wip » ne donnent rien d'exploitable. La qualité du changelog dépend de celle de l'historique.

La leçon Les commandes essentielles présente les commandes intégrées, et Travailler avec Git les usages de Claude Code autour de l'historique.