Synthèse automatique
Guide l'agent pour inspecter le répertoire de travail, isoler des commits logiquement distincts et rédiger des messages au format Conventional Commits.
Points forts
- Applique une checklist ordonnée : status, diff, découpage, staging sélectif, relecture du diff indexé
- Impose le staging par patch (git add -p) pour séparer les changements mixtes dans un même fichier
- Intègre des contrôles de sûreté avant commit (secrets, logs de debug, bruit de formatage)
- Exige une vérification minimale (test, lint ou build) avant de passer au commit suivant
Limites
- Ne couvre pas la réécriture d'historique, le rebase, la signature ni la création de pull requests
- Suppose que git add -p et git commit -v sont utilisables, ce qui peut être difficile en mode non interactif
- Impose Conventional Commits sans proposer d'alternative si le dépôt suit un autre style
À utiliser quand l'utilisateur demande de committer, de rédiger un message de commit ou de découper son travail en plusieurs commits.
À éviter pour des opérations sur l'historique existant (rebase, amend massif, revert) ou pour ouvrir une pull request.
Analyse de sécurité
SûrThe skill only instructs the agent to run standard read/stage git commands (git status, git diff, git add -p, git restore --staged, git diff --cached, git commit) and to sanity-check for secrets before committing. There is no network exfiltration, no destructive command (no rm -rf, no reset --hard, no force push), no base64 payloads, and no attempt to disable safety controls. The only marginally notable operation is `git restore --staged`, which unstages without touching working-tree content, so overall risk is minimal.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
Review my working tree changes and commit them with a clear Conventional Commits message.My changes mix a refactor and a new feature across several files — split them into separate logical commits with appropriate messages.Look at what's staged with git diff --cached and write a Conventional Commits message with a body explaining what changed and why.description: "Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits."
Commit work
Goal
Make commits that are easy to review and safe to ship:
- only intended changes are included
- commits are logically scoped (split when needed)
- commit messages describe what changed and why
Inputs to ask for (if missing)
- Single commit or multiple commits? (If unsure: default to multiple small commits when there are unrelated changes.)
- Commit style: Conventional Commits are required.
- Any rules: max subject length, required scopes.
Workflow (checklist)
- Inspect the working tree before staging
git statusgit diff(unstaged)- If many changes:
git diff --stat
- Decide commit boundaries (split if needed)
- Split by: feature vs refactor, backend vs frontend, formatting vs logic, tests vs prod code, dependency bumps vs behavior changes.
- If changes are mixed in one file, plan to use patch staging.
- Stage only what belongs in the next commit
- Prefer patch staging for mixed changes:
git add -p - To unstage a hunk/file:
git restore --staged -porgit restore --staged <path>
- Prefer patch staging for mixed changes:
- Review what will actually be committed
git diff --cached- Sanity checks:
- no secrets or tokens
- no accidental debug logging
- no unrelated formatting churn
- Describe the staged change in 1-2 sentences (before writing the message)
- "What changed?" + "Why?"
- If you cannot describe it cleanly, the commit is probably too big or mixed; go back to step 2.
- Write the commit message
- Use Conventional Commits (required):
type(scope): short summary- blank line
- body (what/why, not implementation diary)
- footer (BREAKING CHANGE) if needed
- Prefer an editor for multi-line messages:
git commit -v - Use
references/commit-message-template.mdif helpful.
- Use Conventional Commits (required):
- Run the smallest relevant verification
- Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on.
- Repeat for the next commit until the working tree is clean
Deliverable
Provide:
- the final commit message(s)
- a short summary per commit (what/why)
- the commands used to stage/review (at minimum:
git diff --cached, plus any tests run)
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/create-high-quality-git-commits-mtzb838s/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/create-high-quality-git-commits-mtzb838s' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/create-high-quality-git-commits-mtzb838s/download' --output '.skill-downloads/create-high-quality-git-commits-mtzb838s/SKILL.md.part' && mv '.skill-downloads/create-high-quality-git-commits-mtzb838s/SKILL.md.part' '.skill-downloads/create-high-quality-git-commits-mtzb838s/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.
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
Le fichier ne fournit pas un en-tête name/description exploitable pour cette procédure native. Le téléchargement reste disponible pour lecture ; utilisez le mode manuel ci-dessous.
Mode 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/create-high-quality-git-commits-mtzb838s/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.