Gitmoji

Génère des messages de commit qui suivent la convention gitmoji : chaque commit commence par un emoji qui identifie l'intention du changement au premier coup d'œil. À partir d'une diff, d'une liste de fichiers en staging ou d'une description simple d'un changement, cette skill choisit le gitmoji le plus approprié et rédige un message de commit concis et bien formé autour de lui.

Cette skill génère uniquement le message — elle n'exécute jamais git commit ni aucune autre commande git. La sortie est un message copiable que l'utilisateur peut utiliser.

Quand utiliser cette skill

• L'utilisateur dit « écris un commit gitmoji », « ajoute un gitmoji à ce changement », ou « ajoute un emoji à mon message de commit »
• L'utilisateur demande « quel gitmoji devrais-je utiliser pour cela ? »
• L'utilisateur colle une diff git ou décrit un changement dans un projet qui utilise un historique de commits en style gitmoji
• L'utilisateur veut un historique de commits expressif et facile à scanner avec des emojis

Quand ne pas l'utiliser : si le projet suit les Conventional Commits simples (feat:, fix:, ...) sans emojis, utilisez plutôt la skill conventional-commit ou commit-message-storyteller. Si vous ne savez pas quelle convention le projet utilise, demandez à l'utilisateur de fournir l'historique récent des commits (par exemple, la sortie de git log --oneline -10).

Format du message

La spécification gitmoji :

<intention> [scope?][:?] <message>

• intention — exactement un gitmoji exprimant l'objectif du commit
• scope (optionnel) — la section du codebase affectée, entre parenthèses
• message — une brève explication impérative du changement

Exemples :

✨ add multi-tenant support to the billing service
🐛 (auth) prevent token refresh loop on expired sessions
♻️ (api): extract pagination logic into shared helper

Style d'emoji : Unicode vs Shortcode

Gitmoji supporte deux notations équivalentes :

Respectez l'historique existant du repository. Si les commits récents utilisent des shortcodes de style :sparkles:, générez des shortcodes ; sinon, utilisez par défaut les emojis unicode.

Comment ça marche

Étape 1 : Comprendre le changement

Travaillez à partir de ce que l'utilisateur fournit :

1. Une diff git — lisez-la et identifiez ce qui a changé et pourquoi
2. Une liste de fichiers en staging/modifiés — déduisez l'intention des noms et chemins de fichiers
3. Une description simple — utilisez-la directement

Si l'intention est véritablement ambiguë (par ex. « mis à jour auth.js » pourrait être un correctif, une fonctionnalité ou une refonte), posez une seule question de clarification courte plutôt que de deviner.

Étape 2 : Identifier l'intention dominante

Déterminez l'objectif principal du changement. Intentions courantes et leurs gitmojis :

Ceci n'est que le sous-ensemble le plus courant — consultez toujours references/gitmoji-reference.md pour la liste officielle complète des 75 gitmojis avant de fixer votre choix ; un emoji plus spécifique existe souvent (par ex. 🩹 pour un correctif trivial, ✏️ pour une typo, 🚚 pour un déplacement de fichier).

Étape 3 : Choisir exactement un emoji

Règles pour les cas ambigus :

• Le spécifique prime sur le générique — une correction de typo est ✏️, pas 🐛 ; déplacer des fichiers c'est 🚚, pas ♻️ ; un correctif trivial non critique c'est 🩹, pas 🐛
• Tests : ✅ pour ajouter/mettre à jour des tests réussissants ; 🧪 uniquement pour les tests intentionnellement échouants (par ex. étape rouge du TDD)
• Fix vs hotfix : 🚑️ uniquement pour les correctifs urgents en production ; les corrections de bugs ordinaires sont 🐛
• Correctif de sécurité : 🔒️ prime sur 🐛 quand le bug est un problème de sécurité
• Changements de formatage uniquement : 🎨 pour la structure/formatage du code ; 💄 uniquement pour les fichiers UI/style (CSS, thèmes)
• Un emoji par commit — ne pas empiler les emojis ; si deux intentions semblent également dominantes, consultez la section changements mixtes ci-dessous

Étape 4 : Rédiger le message

• Mode impératif : « add », « fix », « remove » — pas « added » ou « fixes »
• Garder la ligne d'objet sous 72 caractères, emoji inclus
• Minuscule au début, pas de point à la fin
• Ajouter un scope entre parenthèses quand l'historique du projet utilise des scopes
• Ajouter un corps (séparé par une ligne vide) uniquement quand le pourquoi n'est pas évident dans l'objet

Étape 5 : Sortie

Produisez le message de commit dans un bloc de code copiable, suivi d'une ligne expliquant pourquoi ce gitmoji a été choisi. Ne pas exécuter git commit.

Exemple de sortie :

🐛 (auth) prevent token refresh loop on expired sessions

Expired sessions triggered a refresh that failed validation and
re-triggered itself, crashing the app. A recursion guard now aborts
the cycle and returns a clean 401.

Pourquoi 🐛 : le changement corrige un comportement d'exécution incorrect — une correction de bug, pas assez urgent pour 🚑️.

Cas limites

Référence rapide

# Obtenez votre diff en staging à coller dans Copilot
git diff --staged

# Vérifiez quel style d'emoji le repo utilise déjà
git log --oneline -10

Consultez references/gitmoji-reference.md pour la liste officielle complète des gitmojis.