Release notes depuis Conventional Commits

---
name: changelog-release-notes-conventional
description: "Génère des release notes lisibles et un fragment CHANGELOG.md à partir d'une liste de Conventional Commits ou d'un git log entre deux tags. Sortie : version semver détectée (major / minor / patch), bloc CHANGELOG.md avec sections Added / Changed / Fixed / Removed / Security, et note de release publishable, prête pour GitHub Releases, Slack, ou un email équipe. À utiliser quand un dev (tech lead, freelance senior, devops, mainteneur open source) prépare une release et veut éviter 30 minutes de rédaction manuelle."
metadata:
  iaskills_title: "Release notes depuis Conventional Commits"
  metier_slug: dev
  metiers:
    - Devs et tech leads
  secteur: "Tech & DSI"
  tier: free
  compatible:
    - claude-code
    - cowork
    - cursor
    - codex
  version: "1.0.0"
  author: "iaskills"
  editorial:
    pitch: "Release notes claires et CHANGELOG.md généré depuis vos Conventional Commits. Bump semver détecté, sections Keep a Changelog, prêt à publier."
    long_description: "Beaucoup d'équipes utilisent Conventional Commits mais rédigent les release notes à la main parce que les outils auto (release-please, semantic-release) sont configurés à moitié et que la sortie brute n'est pas publishable telle quelle. Ce skill prend votre git log entre deux tags ou une liste de commits, détecte le bump semver applicable (major si BREAKING CHANGE, minor si feat, patch sinon), produit un fragment CHANGELOG.md aux conventions Keep a Changelog (Added, Changed, Fixed, Removed, Security, Deprecated), et une note de release lisible pour vos utilisateurs ou votre équipe interne. Compatible release-please, semantic-release, GitHub Releases, GitLab Releases. Style maison iaskills : pas d'em-dash, pas de superlatif marketing, ton factuel. Vous gardez 30 minutes par release."
    bullets:
      - "Bump semver auto depuis les commits"
      - "Sections Keep a Changelog conformes"
      - "Note de release publishable GitHub"
      - "Regroupe les commits par scope"
      - "Mentionne breaking changes en clair"
      - "Lien direct vers chaque PR ou commit"
    exemple_avant: "Vendredi 17h, vous préparez la release v1.4.0. git log --oneline v1.3.0..HEAD sort 47 commits, dont 12 commits de fixup, 8 commits dependabot, et 4 commits sans Conventional Commits. Vous passez 45 minutes à trier, regrouper, formuler, et vous publiez une release notes baclée que personne ne lit."
    exemple_apres: "Vous collez le git log dans le skill. En 30 secondes, il détecte 2 feat + 4 fix + 1 BREAKING CHANGE, en déduit bump minor (v1.4.0), produit le fragment CHANGELOG.md regroupé par scope, et la note de release lisible pour la team Slack avec le BREAKING CHANGE en évidence. Vous relisez 5 minutes, publiez, partez en week-end."
    recommended_metiers: []
    secteurs:
      - tech-dsi
      - startup-vc
      - conseil-audit
      - finance-comptabilite
    metiers_individuels:
      - dev-backend
      - dev-frontend
      - devops
      - qa-engineer
      - architecte-si
      - mlops
      - chef-de-projet-it
      - cto
      - product-manager
    connecteurs:
      - notion
      - slack
---

# Release notes depuis Conventional Commits

## Quand utiliser ce skill

Déclencher quand un dev (tech lead, fullstack, backend, frontend, devops, freelance senior, mainteneur open source) prépare une release applicative ou un bump de version d'une librairie, et veut produire un CHANGELOG.md propre et une note de release publishable depuis un git log.

À utiliser pour :
- Release applicative web ou SaaS (Next, Rails, Django, Go, etc.)
- Publication d'un package npm, pypi, crates.io, RubyGems, NuGet
- Release notes internes envoyées sur Slack ou Notion à l'équipe
- GitHub Releases ou GitLab Releases publique
- Release d'un SDK ou d'une CLI
- Recap mensuel ou trimestriel d'une product release

Ne pas utiliser pour :
- Commit unique en cours de développement (utiliser `commit-message-conventionnel`)
- Description de PR (utiliser `description-pull-request-claire`)
- Communication marketing produit grand public (les release notes sont techniques, pas marketing)
- ADR ou doc d'architecture (utiliser `adr-decision-architecture`)

## Ce que tu dois faire

### Étape 1, collecter les commits

Demander à l'utilisateur, ou récupérer dans la session :

1. **La liste des commits** : sortie de `git log --pretty=format:"%h %s" <tag>..HEAD` ou `git log <tag>..HEAD --oneline`. Idéalement avec les corps, via `git log <tag>..HEAD --format="%h%n%s%n%b%n---"`.
2. **Le tag de base** : version précédente (ex : `v1.3.0`)
3. **Le tag cible** : version visée, ou laisser le skill le calculer
4. **L'URL du repo** : GitHub, GitLab, Bitbucket, Codeberg, pour générer les liens vers commits et PR
5. **La langue de sortie** : français ou anglais. Par défaut, anglais (convention open source). Si le repo est francophone interne, français.
6. **Le destinataire** : utilisateurs externes (release notes publishables) ou équipe interne (note Slack / Notion). Le ton diffère légèrement.
7. **Le format CHANGELOG.md utilisé** : Keep a Changelog par défaut, ou autre convention si l'équipe en a une.

### Étape 2, parser les commits et détecter le bump semver

Pour chaque commit, identifier le type Conventional Commits dans le sujet :

- `feat` : minor
- `fix` : patch
- `perf` : patch
- `refactor`, `test`, `docs`, `build`, `ci`, `chore`, `style` : pas de bump (mais à lister en Changed ou pas du tout)
- `revert` : selon le commit reverté
- Présence d'un `!` après le type ou d'une section `BREAKING CHANGE:` dans le corps : major

Règle de bump :

1. Au moins un breaking change : **major** (1.3.0 → 2.0.0)
2. Au moins un `feat`, pas de breaking : **minor** (1.3.0 → 1.4.0)
3. Que des `fix` / `perf` / `refactor` / `test` / `docs` / `chore` : **patch** (1.3.0 → 1.3.1)
4. Que des `docs` / `chore` / `ci` (rien d'utilisateur visible) : suggérer pas de release et signaler

Si un commit ne respecte pas Conventional Commits (ex : `wip`, `Update README`), le classer en "Autres" et le mentionner en fin de note.

### Étape 3, regrouper et formater pour le CHANGELOG.md

Format Keep a Changelog (https://keepachangelog.com/fr/1.1.0/) :

```markdown