Générateur de Changelog
Générez automatiquement des changelogs lisibles à partir de l'historique Git. Suit le format Keep a Changelog, affine les messages de commit en langage naturel, et crée optionnellement des Releases GitHub.
Résolution de l'entrée
L'entrée principale est une plage de références Git. Résolvez l'argument (s'il est fourni) :
- Contient
...ou..-> plage de refs Git (ex.v1.0.0...v1.1.0) - Correspond à un tag/référence unique -> depuis cette référence jusqu'à HEAD
- Correspond à une URL GitHub ou à un motif
#\d+-> PR (extraire les changements de cette PR uniquement). Pour une entrée PR unique : lisez le diff et la description de la PR, catégorisez les changements, utilisez le titre de la PR comme entrée. Sautez l'en-tête de version. Demandez à l'utilisateur s'il souhaite ajouter ces entrées à une version existante du changelog ou en créer une nouvelle. - Pas d'argument -> demandez : "Quelle plage le changelog doit-il couvrir ? Vous pouvez fournir une plage de refs Git (ex. v1.0.0...v1.1.0), un tag (changements depuis ce tag), ou un numéro de PR."
Flux de processus
digraph changelog {
rankdir=TB;
"Résoudre l'entrée" [shape=box];
"Phase 1 : Collecter" [shape=box];
"Phase 2 : Catégoriser" [shape=box];
"Phase 3 : Affiner" [shape=box];
"Phase 4 : Réviser" [shape=box];
"Approuvé ?" [shape=diamond];
"Phase 5 : Générer" [shape=box];
"Résoudre l'entrée" -> "Phase 1 : Collecter";
"Phase 1 : Collecter" -> "Phase 2 : Catégoriser";
"Phase 2 : Catégoriser" -> "Phase 3 : Affiner";
"Phase 3 : Affiner" -> "Phase 4 : Réviser";
"Phase 4 : Réviser" -> "Approuvé ?";
"Approuvé ?" -> "Phase 3 : Affiner" [label="révisions"];
"Approuvé ?" -> "Phase 5 : Générer" [label="oui"];
}
Ne SAUTEZ AUCUNE PHASE. Posez les questions à un rythme naturel. Si l'utilisateur répond à plusieurs en même temps, acceptez les réponses groupées et passez à la suite.
Si l'utilisateur dit "choisis les valeurs par défaut" ou similaire, choisissez des valeurs par défaut raisonnables, indiquez ce que vous avez choisi et demandez une seule confirmation.
Phase 1 : Collecter
Étape 1 - Récupérer les commits et les PRs
Exécutez git log entre les deux références pour collecter tous les commits. Si le dépôt utilise des PRs, vérifiez également les PRs fusionnées dans la plage avec gh pr list --state merged.
Pour chaque commit/PR, extrayez :
- Le message du commit (sujet + corps)
- Les fichiers modifiés (pour déterminer la portée)
- Le titre et la description de la PR (si disponibles)
- Tout préfixe de type de commit conventionnel (feat, fix, chore, etc.)
Étape 2 - Lire le contexte produit plus large
Lisez, s'ils existent : README, package.json (ou équivalent). Objectif : comprendre ce qu'est le produit pour rédiger des descriptions conviviales.
Si rien n'est trouvé, demandez : "Pouvez-vous décrire brièvement le produit ? J'ai besoin de contexte pour rédiger des entrées de changelog compréhensibles par les utilisateurs."
Étape 3 - Détecter le format existant
Vérifiez si le dépôt a un fichier CHANGELOG.md existant. Si c'est le cas :
- Détectez le format (Keep a Changelog, personnalisé, etc.)
- Détectez s'il utilise des étiquettes emoji (par exemple emojis pour Nouveau, Correction de bug, Rupture) ou des catégories textuelles
- Adaptez-vous au style existant
S'il n'y a pas de changelog existant :
- Par défaut, utilisez le format Keep a Changelog
- Demandez : "Aucun changelog existant trouvé. Préférez-vous des étiquettes emoji (par exemple pour Nouveau, Correction de bug) ou des catégories textuelles (Added, Fixed, etc.) ?"
Phase 2 : Catégoriser
Classez tous les changements dans les catégories Keep a Changelog. Breaking Changes obtient une section dédiée en haut :
- Breaking Changes - tout changement qui casse le comportement existant, les API, ou nécessite une action de l'utilisateur pour la mise à niveau. Incluez des notes de migration pour chacun. Détectez via
feat!:,fix!:, les pieds de pageBREAKING CHANGE:, ou les API supprimées/renommées dans le diff. - Added - nouvelles fonctionnalités
- Changed - modifications de fonctionnalités existantes
- Deprecated - fonctionnalités qui seront supprimées
- Removed - fonctionnalités qui ont été supprimées
- Fixed - corrections de bugs
- Security - corrections de vulnérabilités
Règles de catégorisation :
- Si les commits suivent les commits conventionnels (
feat:,fix:, etc.), utilisez le type pour catégoriser - Sinon, analysez le diff et le message de commit pour déterminer la catégorie
- Ignorez les changements purement internes (refactorisations, ajouts de tests, modifications CI, mises à jour de dépendances) sauf s'ils affectent le comportement visible par l'utilisateur
- En cas d'incertitude sur la visibilité utilisateur, incluez le changement et laissez l'utilisateur le supprimer lors de la révision
- Pour les plages de 50 commits ou plus, regroupez les changements connexes en entrées de plus haut niveau (par exemple, au lieu de lister 12 corrections API individuelles, écrivez "Amélioration de la gestion des erreurs API sur plusieurs endpoints"). Présentez la version groupée et laissez l'utilisateur développer n'importe quel groupe s'il souhaite plus de détails.
Présentez la liste catégorisée :
"Voici ce que j'ai trouvé dans cette plage :"
Added (3)
- Fonctionnalité A
- Fonctionnalité B
- Fonctionnalité C
Fixed (2)
- Correction de bug A
- Correction de bug B
"Quelque chose à ajouter, supprimer ou recatégoriser ?"
Ne continuez PAS tant que l'utilisateur n'a pas confirmé.
Phase 3 : Affiner
Réécrivez chaque entrée dans un langage compréhensible :
- Mettez en avant le bénéfice utilisateur, pas le détail d'implémentation
- "Les rapports se chargent maintenant 3 fois plus vite" et non "Plan d'exécution de requête SQL optimisé pour le module de reporting"
- "Vous pouvez maintenant exporter les rapports au format PDF" et non "Fonctionnalité d'export PDF ajoutée au service de reporting"
- Gardez chaque entrée sur une ligne (deux maximum pour les changements complexes)
- Incluez les références aux PR/issues lorsque disponibles (par exemple
(#123))
En-tête de version
Format : ## [version] - AAAA-MM-JJ
Si la borne supérieure de la plage est un tag de version (par exemple v1.2.0), utilisez-le comme version. Si la borne supérieure est HEAD ou un nom de branche, demandez : "Quel numéro de version ce changelog doit-il utiliser ?"
Utilisez la date du commit le plus récent dans la plage, au format ISO (AAAA-MM-JJ).
Annexe technique
Après avoir généré le changelog convivial, demandez :
"Souhaitez-vous que je génère également une annexe technique avec les détails d'implémentation ? (utile pour la documentation destinée aux développeurs)"
Si oui, générez une section plus détaillée avec des spécificités techniques, des guides de migration pour les changements cassants et des modifications d'API.
Règles de rédaction
- N'utilisez jamais de tirets cadratins dans le contenu généré. Pas de caractères "---". Utilisez des virgules, deux-points, points ou parenthèses à la place.
- Langage convivial par défaut (pas de jargon, pas de noms de fonctionnalités internes)
- Une ligne par entrée, deux maximum pour les changements complexes
- Temps de verbe cohérent (passé : "Ajouté", "Corrigé", "Supprimé")
- Incluez les références aux PR/issues lorsque disponibles
Phase 4 : Réviser
Présentez l'entrée complète du changelog :
"Voici le changelog :"
## [1.2.0] - 2026-04-11 ### Added - Vous pouvez maintenant exporter les rapports au format PDF (#123) ### Fixed - Le tableau de bord ne scintille plus au chargement de la page (#456)"Souhaitez-vous des modifications ?"
Attendez l'approbation. Passez à la génération uniquement après confirmation de l'utilisateur.
Phase 5 : Générer
CHANGELOG.md
Détectez le fichier CHANGELOG.md existant à la racine du dépôt. S'il est trouvé, lisez l'intégralité du fichier, identifiez le point d'insertion (avant la première ligne ## [), présentez le point d'insertion proposé à l'utilisateur et confirmez avant d'écrire. S'il n'est pas trouvé, créez-en un avec un en-tête standard :
# Changelog
Toutes les modifications notables de ce projet seront documentées dans ce fichier.
Le format est basé sur [Keep a Changelog](https://keepachangelog.com/).
Confirmez toujours avant d'écrire :
"Je vais ajouter ceci au début de
CHANGELOG.md. Bon pour vous ?"
GitHub Release
Après avoir sauvegardé le changelog, demandez :
"Souhaitez-vous que je crée également une GitHub Release avec ce changelog ?"
Si oui, utilisez gh release create <tag> --notes "<contenu du changelog>" pour créer la release. Si gh n'est pas disponible, informez l'utilisateur et passez.
Gestion des erreurs
ghnon disponible -> informez l'utilisateur, ignorez l'enrichissement des PRs et la GitHub Release, basez-vous uniquement sur le log Git- Réf/tag invalide -> demandez à l'utilisateur de vérifier
- Aucun commit dans la plage -> informez l'utilisateur, demandez de vérifier la plage
- Absence de contexte produit -> demandez à l'utilisateur de décrire le produit
- Commits non conventionnels -> recourez à l'analyse du diff pour la catégorisation
Ce que cette compétence ne fait PAS
- Gérer la stratégie de versioning (les décisions de version sémantique sont laissées à l'utilisateur)
- Publier dans des registres de paquets
- Générer des articles de blog ou des newsletters (utilisez
/blog-postou/newsletter) - Gérer les stratégies de branchement ou les workflows de release