Changelog from commits
Skill sharklandy/claude-code-starter-kit/skills/process/changelog-from-commits
Skills, subagents et templates /goal//loop//schedule prêts à l'emploi pour Claude Code — installables en une commande via /plugin marketplace add
npx -y skills add sharklandy/claude-code-starter-kit --skill changelog-from-commitsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generate or update CHANGELOG.md from git history since the last tag or entry. Trigger whenever asked to prepare a release, update the changelog, or summarize changes since the last version.
SKILL.md
2.6 KB, as published. Nobody here has run it
<!-- Skill générique de la "vague 2" (par opposition aux skills orientés cas d'usage de la vague 1) -->
Générer un CHANGELOG à partir de l'historique git (générique)
- Déterminer le point de départ : le dernier tag git (
git describe --tags --abbrev=0) si le projet en utilise, sinon la date/le commit de la dernière entrée déjà présente dansCHANGELOG.md. - Lister tous les commits depuis ce point de départ
(
git log <dernier-tag>..HEAD --oneline), en excluant les commits de merge sans contenu propre. - Respecter le format déjà utilisé dans le
CHANGELOG.mdexistant du projet (souvent inspiré de "Keep a Changelog") :## [version] - date, avec des sous-sections### Ajouté,### Corrigé,### Modifié(ou l'équivalent anglaisAdded/Fixed/Changedsi c'est la langue déjà utilisée dans le fichier). - Classer chaque commit dans la bonne sous-section à partir de son
contenu réel (pas uniquement son préfixe de type de commit, qui peut
être absent ou incorrect) — un commit
fix: ...qui en réalité ajoute une fonctionnalité doit être classé dans "Ajouté", pas "Corrigé". - Regrouper les commits qui décrivent la même unité de travail vue par l'utilisateur final (ex. plusieurs commits "wip" successifs sur la même fonctionnalité) en une seule ligne de changelog, plutôt que de lister chaque commit brut.
- Ne jamais lister un commit purement interne (renommage de variable, config CI, formatage) dans le changelog destiné aux utilisateurs, sauf si le projet distingue explicitement une section technique.
Gotchas
- Un projet sans tags git rend la détection du "dernier point de
départ" ambiguë — se rabattre sur la date de la dernière entrée du
CHANGELOG.mdexistant plutôt que de remonter tout l'historique du dépôt par défaut. - Des commits de type
chore(release): ...ou de bump de version automatique ne doivent pas apparaître comme une entrée de changelog à part entière — les exclure explicitement. - Avant d'écrire quoi que ce soit, vérifier si le changelog est généré
automatiquement par un outil de release (config
.releaserc,release-please-config.json, sectionsemantic-released'un manifeste...) : dans ce cas ne jamais l'éditer à la main — la modification serait écrasée à la release suivante.