setup-pre-commit

Présentation de la compétence setup-pre-commit

Ce que fait setup-pre-commit

La compétence setup-pre-commit aide un agent à ajouter une barrière de validation Git concrète dans un dépôt JavaScript ou TypeScript avec husky, lint-staged, Prettier, et éventuellement des scripts typecheck et test. En pratique, elle met en place le formatage sur les fichiers indexés et peut bloquer les commits problématiques avant qu’ils n’entrent dans l’historique.

Pour qui cette compétence est la plus adaptée

Cette compétence convient surtout aux équipes ou aux développeurs solo qui veulent une configuration pre-commit simple à déployer dans un dépôt existant, sans concevoir à la main une première configuration Husky. Elle est particulièrement adaptée si vous avez déjà un projet basé sur Node et que vous souhaitez un formatage au moment du commit, avec quelques contrôles qualité légers.

Le vrai besoin auquel elle répond

La plupart des utilisateurs ne veulent pas seulement « installer Husky ». Ils veulent un dépôt dans lequel les contributeurs peuvent commit en confiance, avec un hook prévisible qui :

• formate les fichiers indexés,
• lance les scripts typecheck et test existants lorsqu’ils sont présents,
• n’ajoute pas d’outillage superflu,
• respecte le gestionnaire de paquets du dépôt.

C’est là toute la valeur pratique de setup-pre-commit.

Ce qui distingue setup-pre-commit d’un prompt générique

Un prompt générique peut proposer de nombreux modèles possibles pour les hooks Git. La setup-pre-commit skill est plus ciblée, donc plus utile dans un cas courant : mettre en place le trio Husky + lint-staged + Prettier, détecter le gestionnaire de paquets, créer les bons fichiers, et éviter d’ajouter des commandes typecheck ou test que le dépôt ne prend pas réellement en charge.

Ce qu’elle configure par défaut

D’après la source de la compétence, le résultat attendu comprend :

• l’initialisation de husky
• un fichier .husky/pre-commit
• un .lintstagedrc
• un .prettierrc uniquement si aucune configuration Prettier n’existe déjà
• des commandes de hook pour lint-staged, avec typecheck et test si ces scripts existent déjà

Dépôts bien adaptés et cas moins pertinents

Cas bien adaptés :

• dépôts Node.js
• applications TypeScript frontend ou full-stack
• dépôts qui utilisent déjà package.json
• projets avec des scripts test et typecheck existants

Moins adapté :

• monorepos polyglottes avec orchestration de hooks sur mesure
• dépôts qui utilisent déjà un autre gestionnaire de hooks
• équipes qui veulent des pipelines de commit très rapides, très sélectifs ou spécifiques à certains langages au-delà des valeurs par défaut
• projets où lancer les tests à chaque commit est trop lent

Comment utiliser la compétence setup-pre-commit

Contexte d’installation pour la compétence setup-pre-commit

Si vous utilisez le système Skills, ajoutez la compétence depuis le dépôt source :

npx skills add mattpocock/skills --skill setup-pre-commit

Ensuite, invoquez-la quand vous voulez que l’agent modifie le dépôt courant, et non qu’il explique les hooks Git de manière abstraite.

Les entrées dont la compétence a besoin dans votre dépôt

La qualité d’utilisation de setup-pre-commit dépend fortement du contexte du dépôt. Avant de l’appeler, assurez-vous que l’agent peut inspecter :

• package.json
• un lockfile tel que package-lock.json, pnpm-lock.yaml, yarn.lock ou bun.lockb
• les fichiers de configuration Prettier existants
• une éventuelle configuration .husky/ ou un autre système de hooks Git
• l’existence ou non de scripts typecheck et test

Sans ce contexte, l’agent peut produire des commandes qui ne correspondent pas à votre gestionnaire de paquets ou à vos scripts réels.

Le premier fichier du dépôt à lire

Commencez par SKILL.md. Cette compétence est simple, autonome, et toute la logique importante s’y trouve :

• détecter le gestionnaire de paquets
• installer husky, lint-staged et prettier
• exécuter npx husky init
• écrire .husky/pre-commit
• écrire .lintstagedrc
• ajouter .prettierrc uniquement s’il manque
• vérifier le résultat

Pour cette compétence précise, il n’y a pas de fichiers d’aide supplémentaires qui cacheraient une logique importante.

Comment bien formuler un prompt pour setup-pre-commit

Un prompt faible :

Set up pre-commit hooks.

Un prompt plus solide :

Use the setup-pre-commit skill in this repo. Detect the package manager from lockfiles, inspect package.json, add Husky with lint-staged and Prettier, and only include typecheck or test in .husky/pre-commit if those scripts already exist. Do not overwrite any existing Prettier config. Show me the files you changed and the exact commands you ran.

Pourquoi c’est mieux :

• cela fixe clairement la règle liée au gestionnaire de paquets,
• cela évite d’inventer des scripts,
• cela préserve les conventions de formatage déjà en place,
• cela demande un diff facile à relire.

Transformer un objectif vague en demande complète

Si votre vrai objectif est « rendre notre workflow Git plus sûr », traduisez-le en contraintes propres au dépôt :

• le gestionnaire de paquets utilisé
• si les tests sont assez rapides pour le pre-commit
• si vous voulez uniquement du formatage ou du formatage plus validation
• si le dépôt utilise déjà Prettier ou Husky
• si vous voulez un hook minimal pour préserver la rapidité côté contributeurs

Exemple :

Use setup-pre-commit for Git Workflows in this React TypeScript repo. We use pnpm, already have a test script, and have typecheck in package.json. Keep the hook simple and fast. Reuse existing Prettier config if present. If tests look expensive, explain whether they should stay in pre-commit or move to pre-push.

Ce prompt donne à l’agent des éléments utiles pour décider correctement, pas seulement une étiquette de tâche.

Fichiers et commandes attendus

Pour un dépôt npm classique, la compétence mène généralement à :

• installer les dépendances de développement : husky, lint-staged, prettier
• exécuter npx husky init
• créer .husky/pre-commit
• créer .lintstagedrc
• éventuellement créer .prettierrc

Le contenu du hook doit être adapté au gestionnaire de paquets. La compétence source indique explicitement de remplacer npm par le gestionnaire détecté quand c’est nécessaire.

Comportement concret selon le gestionnaire de paquets

La règle de détection du gestionnaire de paquets dans la compétence est simple :

• package-lock.json → npm
• pnpm-lock.yaml → pnpm
• yarn.lock → yarn
• bun.lockb → bun
• si ce n’est pas clair → npm

C’est important, car beaucoup de tentatives d’installation de setup-pre-commit ratent non pas à cause de Husky lui-même, mais à cause d’un mélange de commandes provenant de plusieurs gestionnaires de paquets dans la documentation ou les fichiers générés.

Ce que la compétence n’ajoutera volontairement pas

Point de cadrage utile : la compétence n’est pas censée inventer des scripts que votre dépôt ne prend pas déjà en charge. Si package.json ne contient ni typecheck ni test, ces lignes ne doivent pas apparaître dans .husky/pre-commit, et l’utilisateur doit en être informé explicitement.

Cela rend la compétence plus sûre que des prompts trop larges qui supposent que chaque projet dispose d’une vérification TypeScript et d’un lanceur de tests.

Workflow conseillé après l’exécution de la compétence

Après application de la compétence par l’agent :

1. inspectez package.json
2. inspectez .husky/pre-commit
3. inspectez .lintstagedrc
4. vérifiez qu’aucune configuration Prettier existante n’a été écrasée
5. faites un commit de test avec une petite modification de formatage sur un fichier indexé
6. décidez si test a sa place en pre-commit ou doit être déplacé ailleurs

Cette dernière étape est importante : la justesse technique ne suffit pas à garantir une bonne expérience. Un hook qui lance des tests longs peut être valide sur le papier tout en nuisant à son adoption.

Une bonne checklist de revue par défaut

Avant de fusionner les changements, vérifiez que :

• le gestionnaire de paquets correspond bien au dépôt
• .husky/pre-commit utilise des commandes que les contributeurs peuvent lancer localement
• le hook n’appelle pas de scripts absents
• le formatage des fichiers indexés est bien limité via lint-staged
• la configuration Prettier n’a été ajoutée que si elle manquait
• la latence au commit reste acceptable au quotidien

FAQ sur la compétence setup-pre-commit

setup-pre-commit est-il adapté aux débutants ?

Oui, si le dépôt est un projet Node standard. La compétence a des choix assumés, mais elle reste simple, et elle évite une grande partie des frictions classiques lors d’une première mise en place de Husky et du branchement de base avec lint-staged.

Que ne couvre pas setup-pre-commit ?

La compétence ne cherche pas à définir une stratégie qualité complète. Elle ne choisit pas de règles ESLint, n’optimise pas l’exécution des hooks dans un monorepo, et ne construit pas des commandes lint-staged sophistiquées selon les types de fichiers. Son périmètre est la mise en place initiale du hook de commit.

Quand ne faut-il pas utiliser setup-pre-commit ?

Mieux vaut l’éviter si :

• votre dépôt dispose déjà d’un système de hooks Git mature,
• vous avez besoin de hooks multi-étapes spécifiques à certains langages hors outillage Node,
• vous voulez des patterns de fichiers indexés très personnalisés,
• lancer les tests à chaque commit ralentirait manifestement les développeurs.

Dans ces cas-là, un prompt plus ciblé ou un standard interne déjà existant sera souvent préférable.

Est-ce mieux que de demander à une IA de « configurer Husky » ?

En général oui, pour ce cas d’usage précis. La valeur de setup-pre-commit ne tient pas à l’originalité, mais à son cadre d’exécution. Elle encode un chemin par défaut raisonnable et réduit les approximations autour de la détection du lockfile, des scripts manquants et du moment opportun pour créer une configuration Prettier.

setup-pre-commit fonctionne-t-il pour les monorepos ?

Parfois, mais avec prudence. Il peut rester utile si le dépôt a un package.json racine clairement identifié et une seule stratégie de hooks. Il est moins fiable lorsque les packages ont des scripts indépendants, des politiques de formatage distinctes ou des commandes de test propres à chaque workspace.

Force-t-il Prettier même si le dépôt a déjà une configuration de formatage ?

Non. Les instructions source indiquent de créer .prettierrc seulement si aucune configuration Prettier n’existe déjà. C’est un comportement important pour favoriser l’adoption sans perturber les conventions en place.

Puis-je utiliser setup-pre-commit pour des workflows Git au-delà du formatage ?

Oui, mais dans une mesure limitée. La compétence permet d’ajouter typecheck et test au workflow de commit lorsque ces scripts existent déjà. Ce n’est pas un outil complet de protection de branche ou de conception CI.

Comment améliorer la compétence setup-pre-commit

Donnez dès le départ à la compétence des faits plus solides sur le dépôt

Le moyen le plus rapide d’améliorer l’utilisation de setup-pre-commit est de fournir dans votre prompt des signaux concrets sur le dépôt :

• le gestionnaire de paquets
• si typecheck existe
• si test existe
• si les tests sont rapides
• si une configuration Prettier existe déjà
• si .husky/ existe déjà

La compétence devient nettement plus fiable lorsqu’elle s’appuie sur des faits vérifiés plutôt que sur des suppositions.

Demandez une implémentation pensée pour le diff

Un bon prompt d’amélioration serait :

Use the setup-pre-commit skill, but minimize changes. Reuse existing config where possible, avoid replacing current hook behavior, and show the exact file diff before writing anything risky.

C’est particulièrement utile dans les dépôts qui contiennent peut-être déjà une partie de l’outillage.

Évitez le mode d’échec le plus fréquent

Le problème le plus courant consiste à ajouter des commandes que le dépôt ne peut pas exécuter. Pour améliorer le résultat, indiquez explicitement à l’agent :

Only add typecheck and test to the hook if those scripts already exist in package.json. Otherwise omit them and explain why.

Cette consigne est alignée avec la compétence source et évite de casser les commits.

Optimisez pour la vitesse des développeurs, pas seulement pour la correction

Beaucoup d’équipes constatent que npm run test en pre-commit est trop lourd. Si la rapidité compte, demandez à l’agent d’évaluer le coût du hook :

Use setup-pre-commit, but if tests appear slow or broad, explain whether they should move to pre-push or CI instead of pre-commit.

Vous faites ainsi évoluer la compétence d’un simple « installer des outils » vers un vrai ajustement au workflow.

Demandez des commandes sûres pour votre gestionnaire de paquets

Si votre équipe utilise pnpm, yarn ou bun, dites-le explicitement même si le lockfile est présent. Cela réduit l’ambiguïté et améliore la cohérence des commandes dans les fichiers de hook générés et les instructions de suivi.

Demandez à l’agent de préserver les standards existants

Si votre dépôt contient déjà des fichiers de formatage ou de hooks, ajoutez :

Do not overwrite existing Prettier or Husky config without comparing and explaining the merge strategy.

C’est plus important qu’il n’y paraît. Les outils pre-commit échouent souvent sur le plan humain parce qu’ils remplacent trop agressivement les conventions locales.

Améliorez la qualité de sortie avec une étape de validation

Un meilleur prompt final inclut :

After applying setup-pre-commit, verify that the hook files exist, dependencies are in devDependencies, and the hook references only valid scripts. Then tell me how to test it with one staged file.

Cela pousse l’agent au-delà de la simple création de fichiers vers un résultat réellement exploitable.

Itérez après le premier passage

Si le premier résultat est techniquement correct mais peu pratique, affinez avec l’un de ces suivis :

• “Make the hook faster.”
• “Adapt this for pnpm.”
• “Remove test from pre-commit but keep typecheck.”
• “Keep existing Prettier settings and only add missing pieces.”
• “Adjust for a monorepo root package.”

C’est généralement plus efficace que de repartir de zéro avec un tout nouveau prompt trop large.

Ce qui compte le plus pour les utilisateurs

Pour la plupart des adoptants, le meilleur setup-pre-commit guide ne consiste pas à savoir « combien d’outils il installe », mais à vérifier s’il :

• fonctionne immédiatement avec le dépôt actuel,
• évite de casser les commits,
• respecte la configuration existante,
• reste assez rapide pour que les développeurs le laissent activé.

Utilisez la compétence avec ces résultats en tête, et elle aura bien plus de chances d’apporter une valeur durable.