Marcussyl/cursor-skills

Commiter par lots

Divisez le travail non versionné en commits logiques. Chaque commit doit être révisable de manière autonome et inclure tous les fichiers nécessaires à la cohérence de cette partie.

Sécurité (toujours)

• Ne jamais mettre à jour la configuration Git.
• Ne jamais forcer le push, faire un hard reset ou toute autre opération destructive Git sauf demande explicite de l'utilisateur.
• Ne jamais sauter les hooks (--no-verify, etc.) sauf demande explicite de l'utilisateur.
• Ne jamais mettre en scène des secrets (.env, identifiants, clés). Avertissez et excluez-les.
• Ne jamais utiliser git commit --amend sauf si les règles de l'utilisateur pour l'amend sont entièrement respectées.
• Si un hook de commit échoue, corrigez le problème et créez un nouveau commit ; ne modifiez pas un commit échoué.
• N'ajoutez pas Co-authored-by: Cursor aux messages de commit.

1. Inspection

Exécutez en parallèle lorsque c'est possible :

• git status
• git diff et git diff --staged
• git log -5 --oneline pour le style du message
• git remote -v et le suivi de branche (git status -sb)

S'il n'y a rien à commiter, arrêtez-vous et dites-le.

2. Planification des lots

Regroupez les modifications par objectif, pas uniquement par type de fichier. Exemples :

• Une fonctionnalité ou un comportement utilisateur + ses tests et sa documentation
• Un correctif de bug + uniquement les fichiers qui le corrigent
• Une refactorisation qui tient seule sans mélanger des fonctionnalités sans rapport
• Une tâche ménagère ou un outillage limité à un domaine (dépendances, CI, configuration)

Règles :

• Ne mélangez pas des fonctionnalités sans rapport dans un même commit.
• Incluez les fichiers compagnons dans le même lot (par exemple schéma + entité + migration + sites d'appel pour une modification).
• Si un fichier touche deux préoccupations, privilégiez le lot dominant ou mentionnez le compromis avant de commiter.
• Listez les lots dans l'ordre : les fondations d'abord (types partagés, configuration), puis les fonctionnalités, puis la documentation seule si elle dépend des commits précédents.

Présentez à l'utilisateur un court plan : numéro du lot, fichiers ou chemins, sujet proposé de commit conventionnel. Continuez ensuite sauf objection.

3. Validation de chaque lot

Pour chaque lot, séquentiellement :

1. Mettez en scène uniquement ce lot (git add chemins spécifiques ; évitez git add -A sauf si tout l'arbre est un seul lot).
2. Revérifiez avec git diff --staged qu'aucun élément non lié ne s'est glissé.
3. Rédigez un sujet de Commit Conventionnel (feat, fix, chore, docs, refactor, test, etc.) axé sur le pourquoi.
4. Si le nom de branche contient un identifiant de problème, ajoutez #<problème> au sujet (style GitLab).
5. Commitez. Sur Windows PowerShell, utilisez git commit -m 'sujet' (ou plusieurs -m pour un corps court). Sur bash, un HEREDOC pour le message est acceptable.
6. Répétez jusqu'à ce que l'arbre de travail soit propre pour les modifications prévues.

4. Pousser vers GitHub (ou distant)

Après tous les lots :

• Si origin (ou le distant nommé par l'utilisateur) existe et la branche doit être publiée, exécutez git push -u origin HEAD lorsque l'amont est manquant, sinon git push.
• Ne forcez jamais le push sur main ou master.
• Si le push est rejeté, signalez l'erreur et suggérez un pull/rebase ; ne forcez pas sauf demande explicite de l'utilisateur.
• S'il n'y a pas de distant, dites que les commits sont uniquement locaux et demandez si l'utilisateur souhaite ajouter un distant.

5. Rapport

Résumez :

• Chaque hash de commit et son sujet (le plus récent en dernier ou sous forme de liste numérotée).
• Résultat du push (URL ou branche si disponible).
• Tout élément intentionnellement non mis en scène (secrets, fichiers locaux uniquement).

Relation avec commit-msg

commit-msg suggère une ligne à partir des fichiers déjà en scène et ne valide pas. Cette compétence planifie, met en scène, valide en plusieurs étapes et pousse.