Synthèse automatique
Analyse le diff git en cours, regroupe les fichiers par changement logique et rédige un message de commit conforme à la spécification Conventional Commits avant d'exécuter le commit.
Points forts
- Déduit le type, le scope et la description à partir du diff réel plutôt que de devinettes
- Couvre les cas de breaking change (point d'exclamation et footer BREAKING CHANGE)
- Inclut un protocole de sécurité git explicite (pas de --force, pas de --no-verify, pas de modification de config)
- Propose le staging ciblé par fichiers, motifs ou mode interactif
Limites
- Se limite au commit : ni push, ni création de branche, ni résolution de conflits
- Suppose un dépôt git déjà initialisé avec des changements disponibles
- Les conventions de type et de scope restent génériques et peuvent ne pas correspondre au style imposé par l'équipe
Utilisez-le quand vous voulez transformer un ensemble de modifications en un ou plusieurs commits propres et conformes à Conventional Commits sans rédiger les messages à la main.
Ne l'utilisez pas pour des opérations historiques risquées comme un rebase interactif, un amendement ou un revert de commit déjà poussé.
Analyse de sécurité
PrudenceThe skill only invokes normal git commands to inspect, stage, and commit changes. It does not exfiltrate data, disable safety, or use obfuscated payloads, but the Bash capability and repository-modifying actions warrant caution rather than an unconditional safe rating.
- •Declares and uses Bash to run git commands (diff, add, commit), which can modify repository state; however, the commands are standard git workflows and include safety guidance against force/destructive actions.
Exemples
Commit my current changes with a conventional commit message./commit — group the auth middleware edits into a single feat commit with an appropriate scope.Commit the removal of the legacy /v1/users endpoint and mark it as a breaking change in the message.name: git-commit description: 'Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping' license: MIT allowed-tools: Bash
Git Commit with Conventional Commits
Overview
Create standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.
Conventional Commit Format
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Commit Types
| Type | Purpose |
|------------|--------------------------------|
| feat | New feature |
| fix | Bug fix |
| docs | Documentation only |
| style | Formatting/style (no logic) |
| refactor | Code refactor (no feature/fix) |
| perf | Performance improvement |
| test | Add/update tests |
| build | Build system/dependencies |
| ci | CI/config changes |
| chore | Maintenance/misc |
| revert | Revert commit |
Breaking Changes
# Exclamation mark after type/scope
feat!: remove deprecated endpoint
# BREAKING CHANGE footer
feat: allow config to extend other configs
BREAKING CHANGE: `extends` key behavior changed
Workflow
1. Analyze Diff
# If files are staged, use staged diff
git diff --staged
# If nothing staged, use working tree diff
git diff
# Also check status
git status --porcelain
2. Stage Files (if needed)
If nothing is staged or you want to group changes differently:
# Stage specific files
git add path/to/file1 path/to/file2
# Stage by pattern
git add *.test.*
git add src/components/*
# Interactive staging
git add -p
Never commit secrets (.env, credentials.json, private keys).
3. Generate Commit Message
Analyze the diff to determine:
- Type: What kind of change is this?
- Scope: What area/module is affected?
- Description: One-line summary of what changed (present tense, imperative mood, <72 chars)
4. Execute Commit
# Single line
git commit -m "<type>[scope]: <description>"
# Multi-line with body/footer
git commit -m "$(cat <<'EOF'
<type>[scope]: <description>
<optional body>
<optional footer>
EOF
)"
Best Practices
- One logical change per commit
- Present tense: "add" not "added"
- Imperative mood: "fix bug" not "fixes bug"
- Reference issues:
Closes #123,Refs #456 - Keep description under 72 characters
Git Safety Protocol
- NEVER update git config
- NEVER run destructive commands (--force, hard reset) without explicit request
- NEVER skip hooks (--no-verify) unless user asks
- NEVER force push to main/master
- If commit fails due to hooks, fix and create NEW commit (don't amend)
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/conventional-git-commits-ms47vp4g/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/conventional-git-commits-ms47vp4g' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/conventional-git-commits-ms47vp4g/download' --output '.skill-downloads/conventional-git-commits-ms47vp4g/SKILL.md.part' && mv '.skill-downloads/conventional-git-commits-ms47vp4g/SKILL.md.part' '.skill-downloads/conventional-git-commits-ms47vp4g/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Outils déclarés par l’auteur (à vérifier dans votre agent) : Bash
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/conventional-git-commits-ms47vp4g/SKILL.md' && test -s '.skill-downloads/conventional-git-commits-ms47vp4g/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/git-commit' && cp -R '.skill-downloads/conventional-git-commits-ms47vp4g' '.claude/skills/git-commit'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/conventional-git-commits-ms47vp4g'openskills read 'conventional-git-commits-ms47vp4g'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/conventional-git-commits-ms47vp4g/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Bonnes pratiques React Hook Form
Developpement
Maîtrisez React Hook Form : évitez les anti-patterns, gérez les abonnements, et traitez correctement reset, dirty state et entrées contrôlées.
Migration Emotion vers Mantine
Developpement
Migrer les styled-components Emotion vers des composants Mantine avec style props et modules CSS. Pour convertir .styled.tsx ou supprimer les imports @emotion.
Détecteur de dérive de périmètre
Developpement
Analyse les diffs git par rapport à une intention pour détecter la dérive de périmètre, fichiers non liés et PR trop larges, puis suggère de garder, diviser ou justifier.