| name | changelog |
| description | À utiliser au moment de préparer une Pull Request (ou un commit) qui apporte un changement visible sur NX Academy — nouvelle page, fonctionnalité, correction, travail en cours. Propose d'ajouter ou de mettre à jour l'entrée du changelog du mois courant (fichier YAML dans src/content/changelog/) à partir des changements. Toujours proposer d'abord, Thomas valide avant écriture. Ne pas bloquer la PR s'il préfère passer. |
Mise à jour du changelog lors d'une PR
Ce skill se déclenche au moment de préparer une PR (ou juste avant, quand
les changements sont prêts). L'objectif : ne plus laisser le changelog prendre
du retard, en proposant l'entrée du mois pendant que le contexte du changement
est frais. Souple par principe : c'est une proposition, pas un passage
obligé.
La mécanique complète du changelog (schéma, fichiers, rendu) est documentée dans
docs/changelog-migration-content-collections.md — s'y référer en cas de doute.
Étape 1 — Juger si une entrée est pertinente
Regarde le diff de la branche. Une entrée changelog a du sens pour un changement
visible ou notable : nouvelle page/fonctionnalité (done), correction de
bug ou mise à jour de sécurité/dépendances (fix), chantier en cours qu'on veut
annoncer (in-progress).
Elle n'en a pas pour du bruit interne pur : refacto invisible, tweak de CI,
formatage. Dans le doute, propose quand même — Thomas tranchera.
Si aucune entrée n'est pertinente, dis-le en une phrase et n'insiste pas.
Étape 2 — Déterminer le fichier du mois courant
Trouve la date du jour (le contexte de session la fournit ; sinon
date +%Y-%m). Le fichier cible est src/content/changelog/AAAA-MM.yaml (ex.
juillet 2026 → src/content/changelog/2026-07.yaml).
- Le fichier existe déjà → on ajoutera une entrée dans son tableau
tasks.
- Le fichier n'existe pas → on le créera avec l'en-tête
month / year /
order (le numéro du mois), voir le doc pour le squelette exact.
Étape 3 — Rédiger une proposition (ne rien écrire encore)
Pour chaque changement retenu, prépare :
- un
kind : done (🟢 sorti/terminé), in-progress (🟡 en cours) ou
fix (🔴 correction) ;
- un
content : une phrase en HTML, à la première personne, dans le
ton perso et direct des entrées existantes (relis quelques .yaml du
dossier pour t'en imprégner — c'est un journal, pas des release notes
corporate). Ajoute un lien <a href="…" target="_blank">…</a> vers la page
concernée quand c'est pertinent.
Étape 4 — Soumettre à validation
Présente la ou les entrées proposées à Thomas (kind + texte + fichier cible)
avant toute écriture. Il valide, ajuste le ton, retire ou reformule. C'est
lui qui décide du contenu ; toi tu proposes et tu formates.
Étape 5 — Écrire, puis vérifier
Une fois validé :
- Édite (ou crée) le
.yaml. Le content doit utiliser un bloc littéral
YAML |- avec le texte indenté de 6 espaces — ça préserve le HTML verbatim
sans problème de quoting (apostrophes, guillemets " des href, etc.).
- Ordonne les nouvelles entrées en haut du tableau
tasks (plus récent
d'abord).
- Lance
npm run check (validation zod du schéma) et npm run prettier:check
— les deux doivent passer avant de committer.
Garde-fous
- Ne jamais bloquer une PR parce que le changelog n'est pas rempli : si
Thomas préfère passer, on passe.
- Ne pas réécrire les entrées existantes des mois passés sans qu'il le
demande — on ajoute, on ne réécrit pas l'historique.
- Ne pas inventer de lien ou de fonctionnalité qui ne serait pas dans le
diff.
