Générateur de messages de commit

Que fait Générateur de messages de commit ?

Flux de travail

1. Exécutez git diff --staged pour inspecter les modifications indexées. S'il n'y a rien, demandez à l'utilisateur d'exécuter git add d'abord et arrêtez-vous.
2. Déterminez la langue de description à l'aide de la Politique de langue ci-dessous.
3. Générez le(s) message(s) et affichez-les pour confirmation ; ne validez pas immédiatement. Lorsque plusieurs formulations sont raisonnables, présentez-les sous forme de liste numérotée courte (1), 2), …) afin que l'utilisateur puisse choisir en répondant simplement par le numéro. Un seul message clair peut être affiché seul. L'utilisateur peut également répondre avec une modification ou sa propre formulation.
4. Exécutez git commit -m uniquement après que l'utilisateur a choisi ou confirmé explicitement — un numéro de la liste, "commit" ou "ok" comptent tous. N'exécutez pas git push sauf demande explicite de l'utilisateur.

Politique de langue

Utilisez cet ordre de priorité pour la description en langage humain après type(scope) : :

1. Utiliser la langue explicitement demandée par l'utilisateur dans cet échange.
2. Sinon, utiliser la préférence du dépôt dans .agent-tools/config.jsonc, si elle définit at-commit.language.
3. Sinon, utiliser la préférence globale dans ~/.agent-tools/config.jsonc, si elle définit at-commit.language.
4. Sinon, utiliser la langue du texte d'invocation réel de l'utilisateur lorsqu'il contient une demande en langage naturel claire et indépendante. Ignorez les instructions de compétence injectées, le contenu cité ou collé, les blocs de code, les diffs et la sortie des outils.
5. Sinon, faire correspondre la langue dominante dans les sujets de commit récents du dépôt.
6. Si aucune langue dominante n'est claire, utilisez l'anglais par défaut.

Appliquez cet ordre littéralement et arrêtez-vous à la première correspondance. Vérifiez les points 2 et 3 avant le point 4. Une commande slash nue ou une invocation de compétence n'a pas de langue ; passez au point 5. Inspectez au maximum les 20 sujets les plus récents.

Conservez les jetons syntaxiques Conventional Commits non traduits : type, scope optionnel, ! et BREAKING CHANGE. Conservez les identifiants, les noms de fichiers, les noms de paquets, les commandes, les noms d'API et les scopes dans leur langue d'origine.

Préférence de langue persistante

N'écrivez pas de configuration lors de la génération de commit ordinaire. Si l'utilisateur demande explicitement de mémoriser une langue de description de commit, proposez de la persister. Demandez dépôt vs global lorsque la portée est ambiguë.

Pour une préférence de dépôt, créez ou mettez à jour .agent-tools/config.jsonc ; pour une préférence globale, utilisez ~/.agent-tools/config.jsonc :

{
  "at-commit.language": "fr"
}

Conservez les clés et commentaires non liés dans la mesure du possible. Ne nécessite pas de configuration préalable du programme d'installation.

Règles

Lisez git diff --staged et générez un titre Conventional Commits qui explique CE qui a changé et, lorsque c'est utile, POURQUOI.

• Titre : type(scope) : description, <= 74 caractères, pas de point final, pas de préfixe, pas de guillemets, pas de bloc de code.
• type : choisissez exactement un :
  • feat pour une fonctionnalité, fix pour une correction de bogue
  • refactor pour une restructuration préservant le comportement, perf pour la performance
  • docs pour des modifications de documentation uniquement, style pour des modifications de formatage uniquement
  • test pour l'ajout ou la correction de tests, build pour les systèmes de construction ou les dépendances, ci pour les scripts/configuration CI
  • chore pour des modifications diverses qui ne touchent pas src/test, revert pour des annulations
• scope : nom du module affecté optionnel. Utilisez la convention de ce dépôt. Dans les monorepos, utilisez le nom du répertoire de l'application/du paquet. Omettez-le pour les modifications transversales ou en cas de doute.
• description : une phrase verbe-objet concise dans la langue naturelle sélectionnée. Évitez les remplissages équivalents à "mise à jour des fichiers", "ce commit", "modifications diverses" ou "plusieurs modifications". Conservez les identifiants, les noms de fonctions, les noms de fichiers, les noms de paquets, les commandes et les API tels qu'écrits.
• une seule ligne uniquement : les messages de commit contiennent toujours uniquement la ligne de titre. N'écrivez pas de corps ni de pied de page. Compressez le POURQUOI nécessaire dans le titre.
• changements majeurs : marquez avec type(scope)! : description, toujours sur une seule ligne. N'utilisez pas de pied de page BREAKING CHANGE.
• ponctuation : utilisez la ponctuation ASCII.

Stratégie de génération

Avant d'écrire, identifiez le fil conducteur des modifications indexées.

• Ligne principale : incluez uniquement les informations nécessaires pour comprendre ce commit. N'empilez pas de noms sauf si l'un d'eux est l'objet du changement.
• Modifications significatives : recherchez les modifications de logique, de contrat, de construction, de barrière de qualité ou de comportement visible par l'utilisateur. Utilisez cela pour choisir type et décider si ! est nécessaire.

Discipline de contenu

Le message doit énoncer des faits de code confirmés, pas des intentions devinées.

• Privilégier les changements de comportement dans src et test : la documentation n'est qu'un contexte de support. Ne déduisez pas QUOI à partir de la documentation seule.
• Le contexte utilisateur prime sur la documentation : les objectifs explicites de l'utilisateur peuvent aider à choisir POURQUOI et la formulation, mais QUOI et la portée proviennent toujours du diff indexé. N'incluez pas les modifications de contexte uniquement absentes du diff. Si le contexte et le diff sont en conflit, suivez le diff et demandez une confirmation.
• Suppressions et renommages : lorsque le but ne peut être confirmé à partir des relations de code, indiquez uniquement ce que le diff prouve, comme "supprimer X" ou "renommer X en Y". N'affirmez pas de remplacement, de migration ou de causalité à moins que le code ne le prouve.
• Plusieurs modifications avec un seul objectif : fournissez un message récapitulatif unique lorsque les modifications servent clairement le même objectif, comme une correction de qualité ou de construction. Suggérez de fractionner uniquement si cela améliore significativement la révision ou le rollback.
• Modifications indexées non liées : fournissez des messages séparés pour chaque unité cohérente ainsi qu'un message récapitulatif conservateur. Laissez l'utilisateur choisir entre fractionnement ou résumé au lieu de reporter le résumé à un autre tour.
• Propriété ou intention peu claire : listez les fichiers qui nécessitent une confirmation au lieu de forcer un message vague. Préférez la confirmation ou le fractionnement à des mots faibles comme "mettre à jour", "ajuster" ou "modifier" lorsque l'intention est peu claire.