jaimegago/agent-skills

Workflow

Exécutez ces étapes dans l'ordre. Arrêtez-vous et signalez à l'utilisateur si une étape échoue.

1. Évaluer l'arbre de travail

Exécutez git status et git diff (à la fois indexé et non indexé) pour comprendre ce qui a changé. S'il n'y a aucun changement, indiquez à l'utilisateur qu'il n'y a rien à valider et arrêtez-vous.

2. Nettoyer les sous-modules sales

Si git status montre des sous-modules avec "(modified content)" mais aucun changement de pointeur de sous-module indexé ou intentionnel, ce sont des sous-sous-modules imbriqués qui ont dérivé (généralement après une mise à jour récursive --remote). Pour chaque sous-module sale, exécutez git -C <chemin-sous-module> submodule update --init pour restaurer les références imbriquées aux commits attendus par le sous-module parent. Après le nettoyage, revérifiez git status pour confirmer que la saleté a disparu. N'indexez PAS les changements de pointeur de sous-module sauf si l'utilisateur les a explicitement modifiés.

3. Tout indexer sauf indication contraire de l'utilisateur

Si l'utilisateur n'a pas spécifié de fichiers particuliers, indexez toutes les modifications (suivies et non suivies) avec git add -A. Si l'utilisateur a nommé des fichiers ou chemins spécifiques, indexez uniquement ceux-ci.

4. Lint et correction automatique

Avant de valider, détectez le linter du projet et exécutez-le avec correction automatique sur les fichiers indexés. Ordre de détection :

• Cible de lint au niveau du projet en premier : si le Makefile a une cible lint ou lint:fix, ou si package.json a un script lint ou lint:fix, privilégiez-la — elle respecte les conventions du projet. Passez à la détection par langage uniquement s'il n'existe pas de cible au niveau du projet.
• Go (go.mod présent) : exécutez gofmt -w sur les fichiers .go indexés, puis go vet ./...
• JavaScript/TypeScript (package.json présent) : exécutez npx eslint --fix sur les fichiers JS/TS indexés si une configuration ESLint existe. Si Prettier est configuré, exécutez aussi npx prettier --write sur ces fichiers.
• Python (pyproject.toml, setup.py ou requirements.txt présent) : exécutez ruff check --fix et ruff format sur les fichiers .py indexés si Ruff est configuré. Repliez-vous sur black s'il est installé. Repliez-vous sur flake8 (rapport uniquement, pas de correction automatique).
• Rust (Cargo.toml présent) : exécutez cargo fmt et cargo clippy --fix --allow-dirty
• Aucun linter détecté : ignorez cette étape et continuez.

Après la correction automatique, ré-indexez les fichiers modifiés avec git add -u. Si le linter signale des erreurs qui n'ont pas pu être corrigées automatiquement, arrêtez-vous et signalez-les à l'utilisateur — ne validez pas avec des échecs de lint connus.

Si un linter est détecté mais que le binaire n'est pas installé, prévenez l'utilisateur et demandez s'il faut continuer sans lint ou abandonner.

5. Générer le message de commit

Analysez le diff indexé pour produire un message Conventional Commit :

type(portée): résumé court

Corps optionnel avec contexte sur ce qui a changé et pourquoi.

Règles :

• type : un parmi feat, fix, refactor, docs, test, chore, ci, perf, style, build
• portée : facultatif mais préféré — dérivez du package, module ou répertoire principal touché. Omettez uniquement lorsque les modifications couvrent trop de domaines pour qu'une seule portée soit significative.
• Ligne de résumé : en minuscules, impératif, pas de point, 72 caractères maximum.
• Corps : ajoutez-le uniquement lorsque le diff est non trivial et que le résumé seul ne donnerait pas assez de contexte à un relecteur. Restez concis.
• Plusieurs modifications logiques : choisissez la dominante pour le type/la portée, mentionnez les modifications secondaires dans le corps. Ne divisez PAS en plusieurs commits sauf demande explicite de l'utilisateur.
• Changements cassants : ajoutez un pied de page BREAKING CHANGE ou utilisez le suffixe ! (ex. : feat!: ...).
• Si le linter a corrigé des fichiers automatiquement, mentionnez-le dans le corps (ex. : "Inclut les corrections automatiques de gofmt.").

6. Valider

Exécutez git commit avec le message généré. Utilisez -m pour les messages sans corps. Pour les messages avec un corps, écrivez dans un fichier temporaire et utilisez git commit -F pour préserver les sauts de ligne, puis nettoyez le fichier temporaire.

7. Synchroniser avec le dépôt distant

Déterminez le nom de la branche actuelle. Ensuite :

• Si la branche a une amont, exécutez git push.
• Si la branche n'a pas d'amont, exécutez git push -u origin <nom-de-branche>.
• Si le push est rejeté car le dépôt distant est en avance, exécutez git pull --rebase puis push à nouveau. Si le rebase produit des conflits, arrêtez-vous et signalez — ne résolvez pas automatiquement les conflits de fusion.

8. Confirmer

Signalez à l'utilisateur :

• Hachage du commit (forme courte)
• Message de commit utilisé
• Nom de la branche et état de la synchronisation distante
• Fichiers modifiés, insertions, suppressions (tirés de git diff --stat du commit)
• Quel linter a été exécuté (ou qu'aucun n'a été détecté)

Cas particuliers

• Aucun dépôt distant configuré : validez localement et informez l'utilisateur.
• HEAD détaché : prévenez avant de valider, suggérez de créer une branche d'abord.
• Uniquement des fichiers non suivis : indexez-les et validez-les normalement.
• Respectez .gitignore — n'ajoutez jamais de force des fichiers ignorés sauf demande explicite de l'utilisateur.