BWBYB/agent-skills

Commit Git Minimal

Objectif

Crée un ou plusieurs commits atomiques pour la tâche en cours de l'agent. Chaque message de commit généré suit les Conventional Commits. Conservez les soumissions ordinaires en contexte bas ; réservez l'analyse complète du diff à une demande explicite en mode complet.

Sélection du mode

• Utilisez le mode rapide par défaut.
• Utilisez le mode complet uniquement lorsque l'utilisateur dit full, demande de scanner ou analyser le diff complet, ou demande explicitement de vérifier chaque modification.
• Ne passez pas silencieusement du mode rapide au mode complet. Si le mode rapide manque d'informations suffisantes, demandez un résumé des modifications ou demandez à l'utilisateur de choisir le mode complet.

Mode rapide

Utilisez d'abord le résumé explicite de la tâche en cours fourni par l'agent. Si nécessaire, inspectez uniquement :

git status --short
git diff --stat

Ne lisez pas le diff complet ni l'historique. Ne devinez pas les modifications absentes du résumé. Regroupez les modifications déclarées en commits atomiques et générez leurs messages. Si l'utilisateur demande explicitement de commiter, montrez les fichiers/messages prévus avant de modifier l'index ou de créer des commits lorsque la limite des fichiers n'est pas claire.

Mode complet

Lisez l'intégralité des diffs pertinents de l'arbre de travail et de l'index, inspectez tous les fichiers modifiés, et lisez la référence Conventional Commits. Vérifiez les fonctionnalités omises, les tests, la documentation, la configuration, les fichiers non liés, les fichiers sensibles, les fichiers générés et les modifications logiques indépendantes. Confirmez que les fichiers générés doivent être versionnés : conservez les sorties nécessaires au projet telles que les lockfiles ou les migrations, et excluez les artefacts de build et les sorties locales. Séparez les fonctionnalités indépendantes, les corrections de bugs, les refactorisations et les modifications de formatage en commits atomiques ; conservez les modifications ensemble lorsqu'elles sont étroitement couplées et ne peuvent pas être testées ou annulées indépendamment. Exécutez les vérifications pertinentes pour les fichiers modifiés en utilisant les commandes existantes du projet. N'exécutez pas la suite complète de tests, lint et vérification de types par défaut ; réutilisez les vérifications déjà effectuées pendant la tâche et étendez la vérification uniquement sur demande ou si nécessaire pour les modifications. N'inspectez pas l'historique sauf demande explicite.

Avant git add ou git commit, préservez les modifications utilisateur qui sont en dehors de la tâche en cours. N'exécutez ces modifications que lorsque l'utilisateur demande explicitement de commiter. Ne jamais pousser (push) dans le cadre de cette compétence.

Règles de commit

Utilisez cette forme :

<type>[portée optionnelle] : <description>

[corps optionnel]

[pied de page optionnel]

• Utilisez feat pour une nouvelle fonctionnalité et fix pour une correction de bug.
• Préférez les types du projet docs, style, refactor, perf, test, build, ci, chore et revert lorsqu'ils décrivent précisément la modification.
• Utilisez une portée nominale entre parenthèses uniquement lorsqu'elle ajoute un contexte utile.
• Marquez les changements cassants avec ! avant les deux-points ou un pied de page BREAKING CHANGE: en majuscules.
• Gardez la description concise, au présent, impérative, et de préférence sous 72 caractères.
• Un commit représente une seule modification logique. Séparez les fonctionnalités indépendantes, les corrections, les tests, la documentation et les refactorisations chaque fois que possible.
• fix correspond à SemVer PATCH, feat à MINOR, et tout changement cassant à MAJOR ; ne modifiez pas les fichiers de version sauf demande distincte.

Sécurité et confirmation

• N'utilisez jamais git add . par défaut ; n'ajoutez que les fichiers appartenant à la tâche en cours.
• Ne commitez jamais .env, identifiants, jetons, clés privées ou autres secrets.
• En mode complet, examinez le contenu de l'index pour détecter les secrets et confirmez que les fichiers générés ou de build sont attendus par le projet avant de les inclure.
• Ne modifiez jamais la configuration Git, ne sautez pas les hooks, ne forcez pas le push et ne modifiez pas un commit existant sauf si l'utilisateur demande explicitement cette action précise.
• Ne mélangez pas les modifications utilisateur préexistantes avec les modifications de l'agent.
• Arrêtez-vous et demandez lorsque la limite de la tâche, la propriété du fichier, la séparation logique ou le statut de fichier sensible n'est pas clair.
• Créer un message n'est pas une autorisation de créer un commit ; exigez une demande explicite de commit avant git add ou git commit.

Référence

Lisez references/conventional-commits.md en mode complet ou lorsqu'un type, un pied de page, un changement cassant, un revert, SemVer ou une question FAQ nécessite un traitement détaillé.