Skill de Résumé de Pull Request

Objectif

Générer une description de pull request qui suit le format du fichier .github/pull_request_template.md du projet. Analyse tous les changements sur la branche actuelle comparés à main et produit un corps de PR concis, prêt à être copié-collé.

Workflow

Étape 1 : Rassembler le contexte

# Nom de la branche actuelle
git branch --show-current

# Commits sur cette branche vs main
git log main..HEAD --oneline

# Fichiers modifiés avec statistiques
git diff main...HEAD --stat

# Diff complet pour analyse
git diff main...HEAD

Étape 2 : Détecter le numéro de ticket

Chercher le numéro de ticket associé depuis (par ordre de priorité) :

1. Argument passé au skill
2. Nom de la branche (ex : fix/explore-hashtags-empty-view -> chercher les tickets)
3. Messages de commit (ex : Closes #1461)

Étape 3 : Analyser les changements

Lire la diff et identifier :

• Ce que le changement fait (1-3 phrases max)
• Quel type de changement c'est (correction de bug, fonctionnalité, refactoring, etc.)
• Les décisions architecturales clés (couches affectées, nouveaux fichiers, patterns utilisés)

Étape 4 : Sortie

Afficher le corps de la PR comme un bloc de code markdown brut afin que l'utilisateur puisse le copier-coller directement dans le champ de description GitHub.

Envelopper l'intégralité de la sortie dans un bloc de code avec la balise de langage markdown :

```markdown
<le corps de la PR ici>
```

Template de sortie

Le contenu à l'intérieur du bloc de code doit suivre exactement cette structure :

## Description

[Résumé en 1-3 phrases de ce qui a changé et pourquoi]

**Related Issue:** Closes #[numéro]

## Type of Change

- [ ] New feature (non-breaking change which adds functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Code refactor
- [ ] Build configuration change
- [ ] Documentation
- [ ] Chore

Cocher uniquement le type applicable ([x]). Garder la description courte et axée sur le « quoi » et le « pourquoi », pas les détails d'implémentation. Les relecteurs peuvent lire la diff pour le « comment ».

Règles

• Afficher comme bloc de code : Toujours envelopper le corps complet de la PR dans un bloc de code fenced ```markdown afin que l'utilisateur puisse le copier-coller directement sur GitHub.
• Être concis : 1-3 phrases pour la description. Aucun détail d'implémentation.
• Suivre le template exactement : Utiliser les cases à cocher du pull_request_template.md.
• Un seul type : Cocher un seul type de changement sauf si c'est vraiment multi-catégories.
• Lier le ticket : Toujours inclure Closes #N si un ticket est connu.
• Pas d'emoji dans la description : Le template a déjà des emoji dans les cases à cocher de type.
• Pas de liste de fichiers ou tableaux : La diff est disponible pour les relecteurs. Ne pas la dupliquer.