Le message de commit qui colle vraiment au diff, testé

Un message de commit est une affirmation sur un diff. « add rate limiting to login » dit que le diff a ajouté une limitation de débit sur la connexion — et soit c'est vrai, soit il a aussi touché trois autres fichiers que le message ne mentionne jamais, soit il « améliore les performances » sans que personne ne l'ait mesuré. Impossible de savoir en lisant seulement le message. Il faut lire le diff, et presque personne ne le fait. Nous dirigeons un annuaire qui teste les skills Claude à longueur de journée, alors nous avons fait la chose la plus ennuyeuse possible : faire écrire à Claude des messages de commit pour 15 vrais diffs open source, deux fois chacun, et vérifier chaque message par rapport aux changements réellement indexés.

Le résultat s'appelle commit-discipline, et il est livré avec les chiffres avant/après attachés : la couverture du diff est passée de 83 % à 97 %, les sujets tiennent sous 50 caractères sur 15 diffs sur 15 (contre 6 sur 15), et les affirmations inventées sont tombées de 1 à 0. Il est gratuit et sous licence MIT : github.com/Skillproofdev/commit-discipline.

Le vide : tout le monde vérifie le format, personne ne vérifie la vérité

Avant d'écrire une ligne, nous avons passé en revue 80 skills centrés sur les commits dans notre index de 16 682 skills, plus les skills de commit autonomes publiés pour Claude Code. La couche format est un espace saturé et résolu. La conformité Conventional Commits est universelle. Le mode impératif, les sujets à 50 caractères, les pieds de page BREAKING CHANGE: — courants, bien documentés, acquis. Si tout ce que vous voulez, c'est un type(scope): subject bien formé, des dizaines de skills le font déjà.

Ce qu'aucun d'eux n'impose, c'est la couche du dessous : le message est-il vrai par rapport au diff ? Rend-il compte de chaque changement logique indexé ? N'invente-t-il rien — aucun motif deviné, aucune « amélioration de performance » non mesurée, aucun changement décrit qui n'existe pas réellement ? C'est la couche d'honnêteté, et elle n'était contestée par personne sur ce terrain. Chaque concurrent exécute git diff --cached comme une suggestion non imposée, ou travaille ouvertement à partir de listes de fichiers — les noms de fichiers, qui indiquent où quelque chose a changé mais jamais quoi ni pourquoi. commit-discipline fait de la lecture du diff complet la règle n° 1 et bannit purement et simplement le raccourci des noms de fichiers.

Huit règles, dont quatre qu'aucun autre ne codifie

Le skill est un ensemble de règles strictes (SKILL.md complet). Les éléments familiers sont appliqués rigoureusement : un type déduit de ce que le diff fait au comportement, un scope qui doit se dériver des chemins (jamais inventé), un sujet impératif ≤50 caractères, les changements cassants dans un pied de page. Les éléments qu'aucun autre n'impose :

1. Complétude de couverture du diff. Une fois le brouillon rédigé, on parcourt le diff face au message : chaque changement logique pris en compte, rien de décrit qui n'est pas indexé. Un contrôle d'hallucination pour les messages de commit.
2. Lire le diff indexé complet, jamais les noms de fichiers. La règle n° 1, raccourci interdit. Le message décrit le diff, donc le diff — en entier — est l'entrée.
3. Une liste concrète de vagueness interdites. update, fix stuff, improve, misc, cleanup sans objet, wip, address feedback — bloqués comme mots porteurs, chacun avec un modèle de remplacement (update deps → bump axios 1.6→1.7).
4. Un contrat de sortie. Le livrable est le message seul dans un bloc de code — pas de préambule, pas de commentaire diff par diff, pas de pied de page Co-Authored-By surprise.

Plus un corps qui explique pourquoi et impact plutôt que de reformuler le diff (avec un test de suppression : si une ligne peut être reconstruite en lisant le diff, on la coupe), et une recommandation de découpage pour les diffs multi-préoccupations — des limites de fichiers concrètes et un sujet de brouillon par commit — au lieu d'un message fourre-tout masquant deux changements.

Le benchmark : 15 vrais diffs, messages d'origine retirés

Nous avons tiré 15 fixtures de curl, redis, express, fastapi, eslint, django, rust-analyzer et astro à des SHA fixés : des fonctionnalités, des corrections de bugs, des refactorisations, deux vrais changements cassants, deux diffs multi-préoccupations implantés, des tâches de documentation et de CI, et des commits de plus de 400 lignes touchant de nombreux fichiers. Chaque diff est allé vers deux agents Claude Sonnet avec des prompts identiques. La seule différence : l'un a lu ce SKILL.md en premier, l'autre non. Nous avons noté de trois façons — conformité mécanique Conventional Commits par script, couverture du diff par rapport à une liste de changements de référence pré-enregistrée, et jugement de préférence A/B en aveugle.

Métrique	Base	Avec skill
Conformité au format (7 contrôles mécaniques, moyenne)	91.4 %	98.1 %
— sujet ≤ 50 caractères	40 % (6/15)	100 % (15/15)
Couverture du diff (vs listes de référence, moyenne)	83.2 %	96.7 %
Affirmations inventées (total sur 15)	1	0
Rappel des changements cassants (2 fixtures)	2/2	2/2
Détection de découpage (2 diffs multi-préoccupations implantés)	0/2	2/2
Préférence A/B en aveugle (skill contre base)	—	9 victoires / 4 défaites / 2 égalités

Deux choses ressortent. D'abord, la conformité mécanique était déjà solide à la base — bons types, mode impératif, pieds de page cassants et verbes non vagues sortaient déjà tout seuls. Tout l'écart de format tenait à la longueur du sujet : la base dépassait les 50 caractères sur 9 diffs sur 15 ; le skill, jamais. Ensuite, la vraie séparation, c'est la couverture. La base laissait régulièrement tomber les changements secondaires — les tests ajoutés, l'entrée de changelog, la seconde préoccupation cachée dans un diff « unique » — là où le skill en rendait compte. Ce bond de 83 % à 97 % est d'où viennent la plupart des victoires en préférence, et c'est ce qu'aucun vérificateur de format ne peut donner.

La détection de découpage en est l'illustration la plus nette. Sur les deux diffs multi-préoccupations implantés (t05, t12), la base a écrit un message fourre-tout à chaque fois ; le skill a proposé le découpage les deux fois. Sur t07 — un commit curl retirant TLS-SRP — le skill a même attrapé un morceau de six setopt sans rapport que la base a silencieusement absorbé dans son message, ce qui était la seule invention de la base sur toute l'exécution : une justification de suppression inventée (« virtuellement inutilisé ») que le diff ne soutenait pas. Le skill a signalé ce morceau comme une question à l'utilisateur plutôt que de deviner.

Là où le skill a perdu — publié quand même

Notre méthodologie exige que les pertes soient publiées à côté des gains, et ce n'était pas un balayage total.

La base a battu le skill sur trois fixtures. Sur t03 (redis), t13 (rust-analyzer) et t15 (fastapi) — tous des diffs étroitement ciblés — la base a attrapé un détail précis que le skill a survolé : une contrainte de trait &mut dyn SourceDatabase élargie (t13), une extraction de déduplication _build_dependant (t15), et l'un des deux algorithmes de comptage de diff (t03). La pression de complétude du skill est réelle mais pas absolue ; sur de petits diffs mono-fichier, la base égale ou bat le skill.

La discipline de découpage du skill a tiré une fois de trop. Sur t14, il a découpé un commit CI-plus-dépendance de deux lignes — ajout de Node 26 à la matrice, mise à jour de mocha — en deux, défendable à la lettre par « un commit, une préoccupation », mais quelque chose que la plupart des relecteurs garderaient comme un seul commit ci:. Trois découpages corrects, un sur-découpage. Compté comme une défaite en préférence, et signalé comme tel.

Et la réserve la plus importante : n=15 est directionnel, pas statistiquement significatif, et la notation de couverture et de préférence a été faite par un juge de la même famille de modèle — aucun juge de classe GPT d'une autre famille n'était configuré sur la machine de test. La préférence en particulier porte un risque d'auto-préférence : le rédacteur et le juge partagent une famille de modèle. Nous avons mélangé les étiquettes avec une graine pré-enregistrée et désaveuglé après notation, mais nous n'allons pas prétendre qu'un score de préférence 9-4-2 venant d'un juge de la même famille est un verdict. C'est un signal. Le protocole complet, les scores par fixture et la divulgation de la méthode de jugement sont dans bench/results/verdict.md.

Installation

git clone https://github.com/Skillproofdev/commit-discipline ~/.claude/skills/commit-discipline

Redémarrez Claude Code. Il se déclenche sur « commit this », « write a commit message », l'indexation de changements à valider, et les demandes de relecture ou de nettoyage de message — et reste en retrait pour les opérations git qui ne concernent pas les messages : branches, rebase, résolution de conflits. Il rejoint notre série discipline aux côtés de token-discipline, qui réduit ce qu'une session coûte, et research-discipline, qui réduit ce qu'une réponse se trompe. Celui-ci réduit ce qu'un message de commit manque.

FAQ

Claude n'écrit-il pas déjà de bons messages de commit ? Pour le format, oui — c'était la surprise du benchmark. La base réussissait déjà le type, le mode et les pieds de page cassants d'entrée de jeu. Là où elle pêchait, c'était la couverture : elle laissait tomber les changements secondaires sur plus de la moitié des diffs multi-préoccupations et multi-fichiers, et dépassait le sujet de 50 caractères sur 9 diffs sur 15. Le travail du skill porte sur cet écart-là, pas sur le format que tout le monde maîtrise déjà.

Est-ce juste un linter Conventional Commits ? Non, et c'est tout l'enjeu. La conformité Conventional Commits est un espace saturé et résolu — des dizaines de skills le font. commit-discipline impose la couche du dessous : que le message rende compte de chaque changement logique du diff et n'invente rien. Le format est un acquis ici ; l'honnêteté face au diff est le produit.

Va-t-il commit ou push pour moi ? Non. Écrire le message est le travail ; lancer git commit est une instruction distincte que le skill ne prend jamais de sa propre initiative. Il n'ajoute pas non plus de pieds de page Co-Authored-By ou « Generated with » sauf si le journal de votre projet ou vos propres instructions montrent que vous les voulez.

Dois-je faire confiance au score de préférence 9-4-2 ? Traitez-le comme directionnel, pas comme un verdict. Il a été jugé par un agent de la même famille de modèle avec les étiquettes en aveugle, faute de juge d'une autre famille disponible sur la machine de test — il porte donc un risque d'auto-préférence, et n=15 n'est pas statistiquement significatif. Les chiffres de couverture (83 %→97 %) reposent sur une liste de changements de référence pré-enregistrée et constituent le résultat le plus solide ; les trois fixtures perdues par le skill sont nommées ci-dessus.