Commit Message Storyteller

Transforme les diffs git bruts et les descriptions de modifications en messages de commit clairs et orientés récit, en suivant la spécification Conventional Commits. Au lieu de « update file.js », tu obtiens des messages qui communiquent l'intention, le contexte et l'impact.

Quand utiliser cette skill

L'utilisateur dit « écrire un message de commit », « aide-moi à committer » ou « génère un commit »
L'utilisateur colle un diff git ou décrit des modifications de code
L'utilisateur dit « comment devrais-je committer ça ? » ou « résume mon diff »
L'utilisateur veut un meilleur historique de commits pour son équipe ou son projet open-source
L'utilisateur prépare une pull request et veut des messages de commit significatifs

Prérequis

Avoir au moins l'un des éléments suivants prêt :

Output de git diff ou git diff --staged
Une description de ce que tu as changé et pourquoi
Une liste de fichiers modifiés

Comment ça marche

Étape 1 : Recueillir le contexte du changement

Demande à l'utilisateur (ou déduis du diff) :

Ce qui a changé — fichiers, fonctions, logique affectée
Pourquoi cela a changé — correction de bug, nouvelle fonctionnalité, refactorisation, performance, etc.
Qui/qu'est-ce qui l'a déclenché — numéro d'issue, demande utilisateur, dette technique, etc.

Si l'utilisateur fournit un git diff brut, extrait ce contexte automatiquement du diff.

Étape 2 : Identifier le type de commit

Mappe le changement à un type Conventional Commits en utilisant ce guide :

Type	À utiliser quand
`feat`	Une nouvelle fonctionnalité ou capacité est ajoutée
`fix`	Un bug ou un comportement incorrect est corrigé
`refactor`	Code restructuré sans changer le comportement
`perf`	Un changement qui améliore la performance
`docs`	Modifications de documentation uniquement
`style`	Formatage, espaces, points-virgules manquants (aucun changement de logique)
`test`	Ajout ou mise à jour de tests
`chore`	Processus de build, mises à jour de dépendances, changements de config
`ci`	Changements du pipeline CI/CD
`revert`	Annulation d'un commit précédent

Voir references/conventional-commits-guide.md pour des exemples détaillés.

Étape 3 : Écrire le message de commit

Suis cette structure :

<type>(<optional scope>): <résumé bref à l'impératif>

<body — l'histoire : pourquoi ce changement a été fait, quel problème il résout>

<footer — références d'issue, avis de changement cassant>

Règles pour chaque partie

Ligne d'objet (première ligne) :

Utilise l'impératif : « add », « fix », « remove » — pas « added » ou « fixes »
Max 72 caractères
Pas de point à la fin
Minuscule après le deux-points

Body (l'histoire) :

Explique le pourquoi, pas le quoi (le diff montre déjà le quoi)
Décris le problème qui existait avant ce changement
Mentionne les alternatives envisagées si pertinent
Garde les lignes sous 100 caractères
Sépare de l'objet par une ligne vide

Footer :

Référence les issues : Closes #123, Fixes #456, Refs #789
Marque les changements cassants : BREAKING CHANGE: <description>

Étape 4 : Générer la sortie

Produis le message de commit dans un bloc de code copiable, suivi d'une explication en anglais simple d'une ligne de l'histoire que tu as racontée.

Exemple de sortie :

fix(auth): prevent token refresh loop on expired sessions

When a user's session expired mid-request, the auth middleware was
triggering a token refresh, which itself failed validation and triggered
another refresh — causing an infinite retry loop that crashed the app.

This adds a recursion guard flag that aborts the refresh cycle if a
refresh is already in progress, returning a clean 401 instead.

Closes #312

Story told: A silent infinite loop on session expiry was crashing the app; this stops the cycle early and returns a clean error.

Plusieurs commits à partir d'un diff

Si le diff contient des changements logiquement séparés, divise-les en plusieurs messages de commit et informe l'utilisateur. Utilise cette heuristique :

Fichiers différents avec des objectifs sans rapport → probablement des commits séparés
Même fichier mais des préoccupations distinctes (ex. correction de bug + refactorisation) → suggère une séparation
Tout étroitement couplé → un commit est correct

Cas limites

Situation	Comment gérer
L'utilisateur ne fournit aucun contexte au-delà d'un diff	Déduis le type et le scope à partir des noms de fichiers et des symboles modifiés
Les changements s'étendent sur plusieurs fichiers sans thème clair	Demande : « Est-ce un seul changement logique, ou plusieurs ? »
Changement cassant détecté	Ajoute automatiquement le footer `BREAKING CHANGE:`
L'utilisateur dit « garde-le court »	Omets le body, écris juste une ligne d'objet forte
Aucun numéro d'issue disponible	Omets complètement le footer

Référence rapide

# Obtiens ton diff staged à coller dans Copilot
git diff --staged

# Ou obtiens les derniers changements non committé de l'arborescence de travail
git diff

Voir references/conventional-commits-guide.md pour les exemples de type et les directives de scope.

commit-message-storyteller