agentkitco/agentkit-dev-skills

Rédige le titre et la description d'une pull request à partir du diff réel et des commits, avec ce qui a changé, pourquoi, comment cela a été testé et quoi examiner. À utiliser lorsqu'on vous demande d'écrire ou d'améliorer une description de PR.

Qu'est-ce que agentkit-dev-skills ?

Cette compétence permet à un agent IA de générer automatiquement une description de pull request (PR) de haute qualité, en analysant le diff réel et les commits entre la branche courante et la branche de base. Son objectif principal est de fournir à un relecteur (reviewer) les informations nécessaires pour comprendre rapidement les changements, leur motivation, les risques associés et les instructions de test. Elle s'appuie sur une méthodologie structurée en plusieurs étapes : collecte des informations (logs, diff, ticket associé), organisation des sections (Pourquoi, Quoi, Comment relire, Tests, Déploiement/risque), et respect de règles strictes comme l'absence de remplissage inutile, l'interdiction d'énumérer tous les fichiers et l'obligation de décrire exactement ce que le diff fait. Cette compétence est conçue pour fonctionner avec des agents comme Claude Code, Cursor, Codex, et tout outil capable d'exécuter des commandes shell et de lire le contenu des fichiers. Elle utilise le fichier `SKILL.md` comme documentation, et peut également exploiter un éventuel modèle de PR dans le dépôt (.github/pull_request_template.md).

Compatible avec~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/agentkitco/agentkit-dev-skills/tree/HEAD/skills/pr-description

Documentation

Rédiger une description de PR qu'un relecteur peut utiliser

Objectif : permettre à un relecteur de décider en deux minutes ce qu'il doit regarder, et permettre à un futur lecteur de comprendre pourquoi la modification existe.

Collecte

Trouvez la branche de base et exécutez git log --oneline <base>..HEAD et git diff --stat <base>...HEAD, puis lisez le diff.
Cherchez la raison : un numéro de ticket ou d'issue lié dans les commits ou le nom de la branche, la demande de l'utilisateur, des commentaires ajoutés dans le diff. Si la raison ne se trouve dans aucun de ces éléments, demandez à l'utilisateur ; n'inventez pas de motivation.
Vérifiez ce qui a été testé : les fichiers de test dans le diff, et les commandes que l'utilisateur a exécutées. Si les tests n'ont pas été lancés, dites-le clairement.
Recherchez un fichier .github/pull_request_template.md ou PULL_REQUEST_TEMPLATE. S'il en existe un, remplissez-le au lieu d'utiliser la structure ci-dessous.

Structure

<Titre : impératif, moins de 70 caractères, nomme le changement de comportement, pas les fichiers>

## Pourquoi
<Le problème ou la demande, en 1 à 3 phrases. Liez l'issue s'il y en a une.>

## Quoi de changé
- <Points au niveau du comportement regroupés par domaine, pas une liste de fichiers.>

## Comment relire
- Commencez par <fichier ou domaine> ; le reste en découle.
- Partie risquée : <la partie la plus susceptible d'être erronée, et pourquoi>.
- Pas changé volontairement : <tout ce qu'un relecteur pourrait attendre et ne trouvera pas>.

## Tests
- <Commandes exactes exécutées et résultats.>
- <Étapes manuelles et ce qui a été observé. "Non testé : ..." le cas échéant.>

## Déploiement/risque
<Migrations, configuration, feature flags, compatibilité, comment revenir en arrière. "Aucun" seulement si c'est vrai.>

Règles

Décrivez ce que le diff fait, pas ce que vous souhaitez qu'il fasse. Relisez le diff après avoir rédigé et supprimez toute affirmation qu'il ne soutient pas.
Ne listez pas chaque fichier. Listez les changements de comportement, la nouvelle configuration, les nouvelles dépendances et le code supprimé.
Pas de remplissage ("Cette PR vise à..."). Pas d'émojis sauf si le dépôt en utilise.
Captures d'écran ou exemples de sortie : dites où cela serait utile ; ne décrivez jamais une capture d'écran que vous n'avez pas vue.
Affichez le titre et le corps dans un bloc de code afin qu'ils puissent être copiés. N'exécutez pas gh pr create sauf si on vous le demande.