jeffyfung/skills

Commit, Push et Ouvrir une PR

Expédie le travail sur la branche de fonctionnalité courante : commit → push → PR. La porte de confirmation (étape 6) verrouille le push — ne l'ignorez jamais, même si invoqué dos à dos dans le même tour.

Prend un argument optionnel : la branche de base. Sans lui, l'étape 5 résout la base.

1. Protéger la branche

git branch --show-current. Si c'est main/master, arrêtez-vous et dites à l'utilisateur de créer d'abord une branche de fonctionnalité — ne jamais commiter ni pousser directement sur main.

2. Délimiter le commit

git status + git diff. Stager uniquement les fichiers qui appartiennent à la tâche en cours. Les fichiers non suivis qui ressemblent à des sorties temporaires, des données générées ou des fixtures de test locales (CSV, *_results/*, logs) ne sont pas automatiquement stagés — listez-les et demandez à l'utilisateur s'il souhaite les inclure, les ignorer ou les ajouter au gitignore.

3. Vérifications avant commit

Consultez les propres commandes de format/lint du dépôt — vérifiez AGENTS.md, CLAUDE.md et README.md (dans cet ordre) pour un formateur/linter documenté et exécutez celui qui est spécifié là. Ne par défaut pas sur dotnet format ou toute autre supposition spécifique à un outil si aucun de ces documents n'en nomme un — notez qu'aucun formateur/linter n'est documenté et continuez.

Si la modification touche du code testé et qu'une exécution de test ciblée rapide est disponible, exécutez-la ; n'exécutez pas la suite complète juste pour un commit.

4. Message de commit

Commits conventionnels (feat|fix|test|docs|refactor(scope): summary), correspondant au style déjà présent dans git log pour ce dépôt. Corps seulement lorsque le « pourquoi » n'est pas évident d'après le diff.

5. Résoudre la branche de base

La base est main sauf si le travail est empilé — construit sur une branche de fonctionnalité qui n'a pas encore atterri, où baser sur main entraînerait la branche ci-dessous dans ce diff.

1. Argument donné — c'est la base. Vérifiez-la avec git rev-parse --verify origin/<base> ; si la référence n'existe pas, dites-le et utilisez main.
2. Pas d'argument — cherchez un candidat. L'un des éléments suivants :
   • La conversation indique que ce travail repose sur des commits effectués sur une autre branche.
   • Le travail provient d'un ticket qui est bloqué par, ou dépend d'un autre ticket — la branche qui résout ce bloqueur est le candidat.
   • git log --oneline origin/main..HEAD montre des commits que cette tâche n'a pas produits ; git branch -r --contains <sha> nomme d'où ils viennent.
3. Validez le candidat. Il doit exister sur le remote, différer de la branche courante et être absent de git branch -r --merged origin/main — un candidat déjà fusionné dans main est mort.
4. Pas de candidat, ou échec de la validation — main.

Un candidat validé est une suggestion, pas une décision : proposez-le à côté de main à la porte de l'étape 6 et laissez l'utilisateur choisir.

6. Porte de confirmation — push

Montrez à l'utilisateur le message de commit, git diff --stat (ou le commit une fois effectué) et la base de l'étape 5 — les deux options lorsque l'étape 5 a trouvé un candidat. Obtenez un accord explicite avant git push -u origin <branche>. Pousser publie la branche — traitez-le comme à sens unique. La création de la PR repose sur cette même confirmation (voir étape 7) et ne nécessite pas d'approbation séparée.

7. Ouvrir la PR

Vérifiez d'abord si une PR existe déjà pour cette branche : gh pr list --head <branche> --state all.

• PR ouverte trouvée — réutilisez-la, n'en ouvrez pas de doublon. Signalez son URL.
• PR fusionnée trouvée — la branche a déjà été expédiée une fois ; arrêtez-vous et demandez à l'utilisateur ce qu'il souhaite avant de créer une autre PR (des nouveaux commits après une fusion sont inhabituels, pas le cas par défaut).
• Aucune PR existante/fusionnée trouvée — la confirmation du push de l'étape 6 couvre déjà cela : rédigez le corps et exécutez gh pr create --base <base> --head <branche> --title "<titre>" --body "<corps>" directement, sans approbation supplémentaire.

Captures d'écran pour les modifications visibles de l'interface utilisateur. Si la modification modifie quoi que ce soit qu'un utilisateur peut voir — un nouveau champ de texte, une couleur modifiée, une nouvelle disposition ou un nouveau texte, une nouvelle page ou un nouveau composant — capturez des captures d'écran du parcours heureux et des cas limites que la modification introduit (états vides et d'erreur, texte long/débordant, responsive vs bureau le cas échéant). Téléchargez-les avec gh pr create --attach '<chemin>#<texte alternatif>' (répétez par image ; gh pr edit <pr> pour ajouter à une PR existante). Si le corps référence le même chemin — par exemple ![Parcours heureux](./pr-shots/happy.png) sous un titre ## Captures d'écran — gh réécrit la référence vers l'URL téléchargée sur place ; sinon les pièces jointes sont ajoutées à la fin du corps. Cela fonctionne pour les dépôts privés : les pièces jointes sont visibles par toute personne ayant accès au dépôt. Gardez les fichiers hors du commit (un répertoire temporaire) — ils sont téléchargés, pas versionnés. Nécessite gh ≥ 2.99 ; sur les versions plus anciennes, glissez les images dans le corps de la PR dans l'interface web. Ignorez uniquement lorsque la modification est invisible pour l'utilisateur (logique, tests, configuration, documentation, CI).

Avant de rédiger, vérifiez si le dépôt a son propre standard de description de PR — .github/PULL_REQUEST_TEMPLATE.md, .github/pull_request_template.md, docs/* ou les instructions CONTRIBUTING.md sur les corps de PR. Un modèle documenté du dépôt remplace celui ci-dessous ; utilisez-le à la place.

Modèle de corps de PR (solution de repli — la norme du dépôt prévaut si elle existe)

## Résumé
<ce qui a changé et pourquoi, 1 à 6 phrases>

## Modifications
- <modification notable 1>
- <modification notable 2>

## Captures d'écran
<pour les modifications visibles de l'IU : parcours heureux + cas limites pertinents ; omettre pour les modifications invisibles>

## Décisions de conception
<compromis notables ou alternatives rejetées — uniquement pour les grandes modifications fonctionnelles, voir ci-dessous>

## Tests
<commandes exécutées / comment vérifié>

## Suivis
<travail différé, ou "Aucun">

Lorsque la base n'est pas main, ouvrez le Résumé en nommant la branche de base et ce qui doit atterrir en premier — le relecteur doit savoir que le diff est empilé et que la PR recible main une fois la base fusionnée.

Incluez les décisions de conception uniquement lorsque la PR introduit un nouveau comportement fonctionnel d'une taille significative (un nouveau module, un algorithme non trivial, un compromis qu'un relecteur aurait autrement demandé) — omettez complètement la section pour la documentation/configuration/tâches ménagères/petites corrections plutôt que de la laisser vide.

8. Visite guidée de la revue (modifications larges uniquement)

Écrivez une visite guidée HTML autonome lorsque l'un des cas suivants est vrai :

• le diff touche plusieurs modules différents non IU ;
• il modifie un schéma de base de données (migrations, tables, colonnes, index, contraintes) ;
• il s'agit d'une fonctionnalité de bout en bout importante (un nouveau flux traversant plusieurs couches).

Ignorez-la pour la documentation, la configuration, les tâches ménagères, les petites corrections et les modifications confinées à un seul module ou à l'IU uniquement. La visite guidée existe pour raccourcir une revue — ne la générez pas automatiquement pour chaque PR.

Écrivez un fichier, pr-walkthrough.html, dans un répertoire temporaire en dehors du commit (ne le stagez jamais), ouvrez-le localement avec open pr-walkthrough.html et donnez le chemin à l'utilisateur. Ne l'hébergez pas, ne l'attachez pas et ne le versionnez pas.

Structurez-le en sections sous des titres repliables natifs <details>/<summary> — la première section ouverte, les autres repliées — afin que le relecteur parcoure les titres et déplie seulement ce dont il a besoin. Pas de JavaScript.

Écrit pour un relecteur qui n'a pas lu le diff :

• Quoi et pourquoi — la modification en quelques phrases, plus l'ordre dans lequel lire le diff.
• Carte des modifications — quels modules sont touchés et comment ils sont connectés. Un diagramme, pas une liste de fichiers.
• Mécanique — chaque élément de logique ou de flux de données non évident expliqué à côté du code qu'il nomme (chemin:ligne).
• Modifications de schéma — formes de table avant/après, chemin de migration et risque (verrous, backfill, rollback).
• Parties difficiles — les parties sur lesquelles un relecteur aurait autrement dû poser des questions, et ce qu'il faut examiner.

Diagrammes : SVG inline, écrits à la main et dimensionnés au contenu, pour les dépendances de modules, le flux de requêtes/séquences et le schéma. Gardez le fichier autonome — pas de JS, CSS ou URLs d'images externes, afin qu'il s'ouvre hors ligne. Utilisez des images rendues ou des captures d'écran uniquement lorsque la chose expliquée est visuelle.

9. Rapport

Donnez à l'utilisateur l'URL de la PR et la base qu'elle cible. Dites clairement ce qui a été commité, poussé et ouvert — sans hésitation.