Message de commit conventionnel

---
name: commit-message-conventionnel
description: "Génère un message de commit Git au format Conventional Commits à partir d'un diff ou d'une description courte. Sortie en 3 parties : ligne sujet typée (feat, fix, refactor, chore, docs, test, perf, build, ci), corps qui explique le pourquoi en 2 à 5 lignes, footer avec breaking changes ou refs d'issue. À utiliser quand un dev (fullstack, backend, frontend, DevOps, freelance senior) doit écrire un commit propre avant push, sans réfléchir 5 minutes à la formulation."
metadata:
  iaskills_title: "Message de commit conventionnel"
  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: "Message de commit Conventional Commits propre, généré à partir de votre diff. Sujet typé, corps qui explique le pourquoi, footer breaking changes ou refs."
    long_description: "Beaucoup de devs écrivent des messages de commit type 'fix bug' ou 'wip' parce que la formulation prend 5 minutes par commit et que la motivation tombe vite. Résultat : un git log inutilisable, des release notes manuelles à rédiger à la fin du sprint, et un debug git bisect qui pleure. Ce skill prend votre diff (ou une description courte), détecte le type Conventional Commits adapté (feat, fix, refactor, chore, docs, test, perf, build, ci), formule un sujet sous 72 caractères à l'impératif présent, ajoute un corps de 2 à 5 lignes qui explique le pourquoi, et un footer avec les breaking changes ou les refs d'issue. Calibré sur les conventions GitHub, GitLab et Jira. Style maison iaskills : pas d'em-dash, ton direct, sujet en français ou anglais selon votre repo."
    bullets:
      - "Conventional Commits standard, type détecté"
      - "Sujet impératif présent, sous 72 caractères"
      - "Corps qui explique le pourquoi, pas le quoi"
      - "Footer breaking change et refs d'issue"
      - "Compatible release-please et changelog auto"
    exemple_avant: "Vous tapez 'git commit -m fix' au pas de course, le 4e commit de la journée. Le sprint suivant, le PO vous demande la liste des changements pour la release notes : git log donne 'fix', 'wip', 'addresses comments', 'really fix this time'. Vous reconstruisez tout à la main."
    exemple_apres: "Le skill produit 'fix(auth): expire les sessions inactives après 30 minutes' avec un corps qui pointe l'incident SEC-142, le breaking change documenté en footer. Release notes générées par release-please en un coup, debug git bisect propre, PR descriptions auto-remplies."
    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
      - data-analyst
      - data-scientist
---

# Message de commit conventionnel

## Quand utiliser ce skill

Déclencher quand un dev (fullstack, backend, frontend, mobile, DevOps, data, freelance senior, tech lead) doit rédiger un message de commit Git avant `git push` ou avant d'ouvrir une PR sur GitHub, GitLab ou Bitbucket.

À utiliser pour :
- Commit unique avant push direct sur une branche feature
- Squash de plusieurs commits avant merge en main, où le message squash devient la trace finale
- Commit d'un PR review qui a généré des changements (addressed review feedback)
- Commit de migration ou de bump de dépendance
- Commit de release préparé pour release-please ou semantic-release

Ne pas utiliser pour :
- Commits temporaires `wip` ou `fixup` qui seront squashés (un message bref suffit)
- Hotfix prod en urgence absolue (le message peut attendre, fixer d'abord)
- Commits sur un repo sans convention établie où le ton est différent (style libre du repo)