amanjotx/Agent-Skills

/ship

Valider le travail en cours, pousser et ouvrir une Pull Request. L'invocation de ce skill constitue une autorisation explicite de créer/changer de branches, commiter, pousser et exécuter gh pr create.

Règles strictes

• Respectez le protocole de sécurité Git de l'utilisateur : ne modifiez jamais la configuration Git ; ne sautez jamais les hooks ; ne forcez jamais un push vers main/master ; ne modifiez par amend que lorsque ses règles d'amend sont entièrement satisfaites.
• Ne commitez jamais de secrets (.env, identifiants, clés privées, tokens). Avertissez et excluez-les s'ils sont présents.
• Stagingez uniquement les fichiers qui appartiennent à ce changement. N'utilisez pas git add . / git add -A de manière générale, à moins que l'arbre ne soit clairement intentionnel et propre de déchets.
• Utilisez HEREDOC pour les messages de commit et les corps de PR.
• Gardez ce workflow agnostique au projet. Inférez les commandes de vérification et la disposition depuis le dépôt ; ne codez pas en dur de noms d'application ou de package.
• Retournez l'URL de la PR une fois terminé.

Préfixes de commit conventionnels

Utilisez des Commits Conventionnels de qualité production. Choisissez un type principal :

Préfixe	Quand
feat	Nouvelle fonctionnalité utilisateur
fix	Correction de bogue
refactor	Restructuration interne sans changement de comportement
perf	Amélioration de performance
chore	Maintenance, outils, dépendances, ménage
docs	Documentation uniquement
test	Tests uniquement
ci	Configuration / pipelines CI
build	Changements du système de build ou du bundler
style	Changement de formatage / lint sans modification logique
revert	Annulation d'un commit précédent

Format :

type(scope-optionnel): résumé impératif

Corps optionnel : pourquoi ce changement existe (1–2 phrases).

Exemples : feat(auth): ajouter la rotation du refresh token, fix: empêcher la double soumission lors du paiement, chore: mettre à jour la configuration lint.

Workflow

1. Inspection (exécuter en parallèle)

• git status
• git diff et git diff --staged
• git branch -vv (branche courante + suivi)
• git log -8 --oneline (style des messages)
• Branche de base par défaut (main préféré, sinon master ou la base par défaut du dépôt)
• État de synchronisation distant (git status -sb, commits non poussés)

S'il n'y a rien à commiter et aucun commit non poussé pertinent pour ce travail, arrêtez-vous. N'ouvrez pas de PR vide.

2. Assurer la bonne branche

Objectif : placer le travail sur une branche de fonctionnalité dédiée basée sur la base la plus récente.

1. Déterminez si la branche courante est destinée à ces changements :

   • Oui si c'est déjà une branche thématique descriptive pour ce travail (feat/…, fix/…, chore/…, ou correspondant clairement à l'intention du changement) et qu'elle n'est pas la branche par défaut.
   • Non si elle se trouve sur main/master/default, une branche thématique non correspondante, une branche obsolète sans rapport, ou un HEAD détaché.

2. Si la branche courante n'est pas destinée à ces changements :

   • Si l'arbre de travail est sale, stashez avec un message clair (par défaut ; ne demandez pas sauf si le stash est impossible).
   • git checkout <base>
   • git pull --ff-only (ou mise à jour fast-forward équivalente depuis le suivi distant)
   • Créez et basculez sur une nouvelle branche descriptive, par ex. feat/sujet-court, fix/sujet-court, chore/sujet-court
   • git stash pop sur la nouvelle branche ; résolvez les conflits éventuels.

3. Si la branche courante est destinée à ces changements :

   • Restez dessus.
   • Avant de commiter, mettez à jour depuis la base si nécessaire (rebase ou merge depuis la dernière base selon les normes du dépôt ; préférez les options non destructives ; ne forcez pas le push sauf demande explicite de l'utilisateur).

Ne construisez jamais une PR directement depuis la branche par défaut.

3. Commit

• Préférez un commit cohérent sauf si l'utilisateur a demandé une division.
• Le message utilise un préfixe conventionnel approprié et un résumé impératif.
• Le corps (optionnel) : concentrez-vous sur le pourquoi, pas une liste de fichiers.
• Après le commit, exécutez git status pour confirmer l'état attendu.
• Si un hook échoue : corrigez le problème et créez un nouveau commit. Ne modifiez pas par amend sauf si les règles d'amend sont entièrement remplies.

4. Push

git push -u origin HEAD

Demandez les permissions nécessaires lorsque le bac à sable/réseau/gh bloque l'opération.

5. Ouvrir la PR

Analysez tous les commits qui seront fusionnés dans la base (pas seulement le plus récent).

Titre : dans le même esprit que le résumé du commit — clair, spécifique, conventionnel quand cela aide. Pas de titres vagues.

Corps modèle (obligatoire) :

## Résumé

- 2–5 puces sur ce qui est livré et pourquoi c'est important

## Pourquoi

- Problème, motivation ou déclencheur de ce changement

## Ce qui a changé

- Puces regroupées par préoccupation (comportement, API/contrats, données, UI, infra, tests, docs)
- Signalez explicitement les changements cassants, les migrations ou les changements de comportement d'authentification/session

## Architecture / flux

Incluez au moins un :

1. Diagramme Mermaid (séquence, organigramme ou état) pour le chemin principal
2. Diagramme ASCII pour la structure, la stratification ou avant → après

Utilisez Mermaid pour le flux de contrôle ; ASCII pour les arbres ou les cartes de couches.
Les diagrammes doivent correspondre au diff réel — n'inventez pas d'architecture.

## Risque / retour arrière

- Modes de défaillance probables
- Notes de retour arrière sûr / atténuation

## Plan de test

- [ ] Étapes concrètes qu'un relecteur peut exécuter
- [ ] Commandes de vérification appropriées au dépôt découvertes depuis le projet

Créez avec gh pr create et un corps HEREDOC. Définissez --base explicitement si nécessaire.

6. Rapport

Gardez-le court :

• nom de la branche
• résumé du commit
• titre de la PR
• URL de la PR
• fichiers intentionnellement non commités