Commit message quality
Skill sharklandy/claude-code-starter-kit/skills/process/commit-message-quality
Skills, subagents et templates /goal//loop//schedule prêts à l'emploi pour Claude Code — installables en une commande via /plugin marketplace add
npx -y skills add sharklandy/claude-code-starter-kit --skill commit-message-qualityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Enforce clear, atomic commit messages before committing. Trigger whenever about to run `git commit`, or when asked to clean up / split a commit or commit history.
SKILL.md
2.5 KB, as published. Nobody here has run it
Qualité des messages de commit (générique)
- Avant de committer, vérifier que le changement staged correspond à
une seule idée logique. Si
git diff --stagedmélange plusieurs préoccupations indépendantes (ex. un correctif de bug et un renommage sans rapport), proposer de découper en plusieurs commits plutôt que de tout committer d'un bloc. - Rédiger le message selon la convention déjà en usage dans le projet
— la détecter dans les 30-50 derniers commits de
git logplutôt que de la supposer. À défaut de convention détectable, utiliser Conventional Commits :<type>(<scope optionnel>): <résumé au présent, impératif, < 72 car.>Types courants :feat,fix,refactor,test,docs,chore. - Le résumé doit décrire le pourquoi ou l'effet observable du changement, pas une paraphrase du diff ("fix bug" est insuffisant ; "fix: prevent duplicate submit on double-click of the form button" est correct).
- Si le changement le justifie, ajouter un corps de message expliquant le contexte, sans dépasser ce qui n'est pas déjà lisible dans le diff lui-même.
- Vérifier qu'aucun message ne référence un état temporaire ou interne à la session ("suite au commentaire de review", "comme demandé") — ce contexte doit vivre dans la description de la PR, pas dans l'historique git qui doit rester compréhensible hors contexte.
Gotchas
- Un commit qui touche à la fois
src/et des fichiers de config générés (lockfiles, build artifacts) donne l'impression d'un gros commit alors que l'intention est petite — séparer le commit de contenu du commit de régénération d'artefacts quand c'est possible. - Le type
fixest souvent utilisé à tort pour des changements qui sont en réalité desrefactorsans changement de comportement observable — vérifier qu'unfixcorrige bien un comportement incorrect constaté, pas juste "amélioré". - Si les messages récents du
git logcontiennent un identifiant de ticket (ex.JIRA-123: ...), reproduire exactement ce format — la convention réelle d'un projet se lit dans son historique, pas dans une supposition.