Récap Repo

Générer un récapitulatif structuré de l'état du repository : PRs ouvertes, issues ouvertes, releases récentes, et résumé exécutif. La sortie est formatée en Markdown avec des liens GitHub cliquables, prête à partager.

Langue

Vérifier l'argument passé à cette skill
Si en ou english → produire le récapitulatif en anglais
Si fr, french, ou aucun argument → produire le récapitulatif en français (par défaut)

Préconditions

Avant de collecter les données, vérifier :

# Doit être à l'intérieur d'un repository git
git rev-parse --is-inside-work-tree

# Doit avoir gh CLI authentifié
gh auth status

Si l'une échoue, s'arrêter et dire à l'utilisateur ce qui manque.

Étapes

1. Collecter les données

Exécuter ces commandes en parallèle via gh CLI :

# Identité du repo (pour les liens)
gh repo view --json nameWithOwner -q .nameWithOwner

# PRs ouvertes avec métadonnées
gh pr list --state open --limit 50 --json number,title,author,createdAt,changedFiles,additions,deletions,reviewDecision,isDraft

# Issues ouvertes avec métadonnées
gh issue list --state open --limit 50 --json number,title,author,createdAt,labels,assignees

# Releases récentes (pour l'historique des versions)
gh release list --limit 5

# PRs récemment fusionnées (pour l'activité des contributeurs)
gh pr list --state merged --limit 10 --json number,title,author,mergedAt

Note : author dans les résultats JSON est un objet {login: "..."} — toujours extraire .author.login lors du traitement.

2. Déterminer les mainteneurs

Pour distinguer « nos PRs » des contributions externes :

gh api repos/{owner}/{repo}/collaborators --jq '.[].login'

Si cela échoue (permissions), fallback : les auteurs avec accès en écriture/admin sont ceux qui ont fusionné des PRs récemment. En cas de doute, demander à l'utilisateur.

3. Analyser et catégoriser

PRs — Catégoriser en 3 groupes :

Nos PRs (l'auteur est un collaborateur du repo) :

Lister avec le numéro de PR (lié), titre, taille (+additions, nombre de fichiers), status

Externes — Reviewables (taille gérable, pas de bloqueurs majeurs) :

Additions ≤ 1000 ET fichiers ≤ 10
Pas de conflits de fusion, CI ne failant pas
Inclure : lien PR, auteur, titre, taille, status de review, action recommandée

Externes — Problématiques (l'un de : trop volumineux, CI failant, chevauchement, conflit de fusion) :

Additions > 1000 OU fichiers > 10
OU CI failant (reviewDecision = "CHANGES_REQUESTED" ou checks failant)
OU touche les mêmes fichiers qu'une autre PR ouverte (= chevauchement)
Inclure : lien PR, auteur, titre, taille, problème spécifique, action prise/nécessaire

Étiquettes de taille (utiliser dans la colonne « Taille » pour un tri visuel rapide) :

Étiquette	Additions
XS	< 50
S	50-200
M	200-500
L	500-1000
XL	> 1000

Format : +{additions}, {fichiers} fichiers ({étiquette}) — ex. : +245, 2 fichiers (S)

Détecter les chevauchements :

Deux PRs se chevauchent si elles modifient les mêmes fichiers. Utiliser changedFiles des données JSON. Si > 50 % de chevauchement de fichiers entre 2 PRs, les signaler toutes deux comme se chevauchant et faire des références croisées.

Signaler les clusters :

Si un auteur a 3+ PRs ouvertes, le noter comme un « cluster » avec un ordre de review suggéré (plus petit d'abord, ou par ordre de dépendances).

Issues — Catégoriser par status :

En cours : a une PR ouverte associée (correspondance par corps de PR contenant fixes #N, closes #N, ou même sujet)
Correctif rapide : petit scope, actionnable (rapports de bugs, petites améliorations)
Demande de feature : scope plus large, nécessite une discussion de design
Couverte par une PR : une PR existante traite cette issue (la lier)

4. Dériver les releases récentes

À partir de la sortie gh release list, extraire la version, la date et le nom. Lister les 5 plus récentes.

Si aucune release trouvée, vérifier les PRs fusionnées pour le pattern release-please (titre correspondant à chore(*): release *) comme fallback.

5. Résumé exécutif

Produire 5-6 points :

Nombre total de PRs et issues ouvertes
Contributeurs actifs (qui a le plus de PRs/issues)
Risques majeurs (PRs surdimensionnées, failings CI, conflits de fusion)
Quick wins (petites PRs prêtes à fusionner — taille XS/S, pas de bloqueurs)
Correctifs de bugs nécessaires (bugs de hook, régressions)
Status de nos propres PRs

6. Formater la sortie

Structurer le récapitulatif complet en Markdown avec :

# {Nom du Repo} — Récap au {date} comme titre (FR) ou # {Repo Name} — Recap {date} (EN)
Sections séparées par ---
Tous les numéros de PR/issue comme liens cliquables : [#123](https://github.com/{owner}/{repo}/pull/123) pour les PRs, .../issues/123 pour les issues
Tableaux avec la syntaxe pipe Markdown pour tous les listages
Gras pour l'emphase sur les actions et risques
Références croisées entre les PRs et issues connexes (ex. : « Couverte par #131 »)

Gestion des données vides :

0 PR ouverte → afficher « Aucune PR ouverte. » (FR) ou « No open PRs. » (EN) au lieu d'un tableau vide
0 issue ouverte → afficher « Aucune issue ouverte. » (FR) ou « No open issues. » (EN)
0 release → afficher « Aucune release récente. » (FR) ou « No recent releases. » (EN)

7. Copier dans le presse-papiers

Après afficher le récapitulatif, le copier automatiquement dans le presse-papiers :

# Presse-papiers multi-plateforme
clip() {
  if command -v pbcopy &>/dev/null; then pbcopy
  elif command -v xclip &>/dev/null; then xclip -selection clipboard
  elif command -v wl-copy &>/dev/null; then wl-copy
  else cat
  fi
}

cat << 'EOF' | clip
{contenu du récapitulatif formaté}
EOF

Confirmer avec : « Copié dans le presse-papiers. » (FR) ou « Copied to clipboard. » (EN)

Modèle de sortie (FR)

# {Nom du Repo} — Récap au {date}

## Releases récentes

| Version | Date | Highlights |
| ------- | ---- | ---------- |
| ...     | ...  | ...        |

---

## PRs ouvertes ({count} total)

### Nos PRs

| PR | Titre | Taille | Status |
| -- | ----- | ------ | ------ |

### Contributeurs externes — Reviewables

| PR | Auteur | Titre | Taille | Status | Action |
| -- | ------ | ----- | ------ | ------ | ------ |

### Contributeurs externes — Problématiques

| PR | Auteur | Titre | Taille | Problème | Action |
| -- | ------ | ----- | ------ | -------- | ------ |

---

## Issues ouvertes ({count} total)

| # | Auteur | Sujet | Priorité |
| - | ------ | ----- | -------- |

---

## Résumé exécutif

- **Point 1**: ...
- **Point 2**: ...

Modèle de sortie (EN)

Même structure mais avec des en-têtes anglais :

« Recent Releases », « Open PRs », « Our PRs », « External — Reviewable », « External — Problematic », « Open Issues », « Executive Summary »
Étiquettes d'action : « To review », « Rebase requested », « Split requested », « Trim requested », « CI broken », « Waiting on author », « Feature request », « Quick fix », « Covered by PR »

Notes

Toujours utiliser gh CLI (pas l'API GitHub directement, sauf pour la liste des collaborateurs)
Dériver le propriétaire/nom du repo de gh repo view, ne pas le coder en dur
Garder les tableaux compacts — tronquer les titres longs si nécessaire (max ~60 caractères)
Faire des références croisées entre les PRs/issues qui se chevauchent chaque fois que possible
author dans gh JSON est un objet — toujours utiliser .author.login

repo-recap