review

Aperçu de la skill review

Ce que fait la skill review

review est une skill de revue de PR avant intégration, conçue pour vérifier les diffs par rapport à la branche de base avant la fusion du code. Elle s’adresse aux reviewers qui ont besoin de plus qu’un prompt générique : elle se concentre sur des risques structurels concrets comme la sécurité SQL, les violations de périmètre de confiance, les effets de bord conditionnels, l’injection shell et l’exhaustivité des enum.

À qui elle s’adresse

Utilisez la skill review lorsque vous êtes sur le point d’intégrer du code, que l’on vous demande de « review this PR », ou que vous voulez un workflow cohérent de review for PR Review à l’échelle de plusieurs repos. Elle est particulièrement utile pour les agents qui doivent signaler rapidement de vrais défauts tout en évitant les commentaires bruyants centrés uniquement sur le style.

Ce qui la différencie

Cette skill a une opinion claire sur l’ordre de revue et sur la gravité des problèmes. Elle pousse d’abord les vérifications de sécurité critiques, puis les problèmes de gravité moindre, et prend en charge des parcours de revue spécialisés pour des domaines comme les tests, la sécurité, la performance et la maintenabilité. Le review guide devient ainsi plus exploitable qu’un simple prompt du type « scanne le diff ».

Adéquation et limites

Elle est particulièrement efficace pour des changements de code avec un diff git clair et une branche de base pertinente. Elle est moins utile pour les critiques de haut niveau sur l’architecture, les retouches de texte marketing, ou les cas où l’utilisateur veut seulement un avis positif ou un résumé. Si vous avez besoin d’un avis léger plutôt que d’une revue orientée correctifs, un prompt générique peut suffire.

Comment utiliser la skill review

Installer et déclencher la skill

Installez-la avec npx skills add garrytan/gstack --skill review. La skill est conçue pour se déclencher sur des formulations comme « review this PR », « code review », « check my diff » et « pre-landing review » ; l’entrée doit donc, autant que possible, nommer le changement et le point de comparaison.

Donnez à la skill une vraie cible de revue

Le meilleur review usage commence par une demande consciente du diff, pas par une requête vague. De bons inputs indiquent le repo, la branche et l’objectif :

• “Review this PR against origin/main; focus on safety, merge risk, and anything that would block landing.”
• “Review the diff in packages/billing for SQL injection, race conditions, and API contract breaks.”

Lisez d’abord ces fichiers

Pour vérifier concrètement le review install, commencez par SKILL.md, puis checklist.md, design-checklist.md et greptile-triage.md. Si vous adaptez le workflow, inspectez aussi TODOS-format.md et le dossier specialists/ afin de comprendre quelles catégories de problèmes sont envoyées à des sous-agents plutôt qu’à la checklist principale.

Utilisez le workflow attendu par la skill

Le repo repose sur une revue en deux passes : d’abord les vérifications de sécurité critiques, puis les problèmes informatifs. Un bon prompt doit demander une sortie actionnable avec références fichier/ligne et correctifs, pas seulement « trouve des bugs ». Si vous connaissez la zone de changement, précisez-la pour que la skill puisse prioriser le parcours spécialiste pertinent.

FAQ sur la skill review

La skill review est-elle meilleure qu’un prompt normal ?

Oui, quand vous avez besoin d’un comportement de revue de PR reproductible. Un prompt standard peut passer à côté des règles de périmètre, de l’ordre d’escalade ou du routage vers des spécialistes. La skill review intègre tout cela dans le workflow, ce qui réduit les approximations sur ce qu’il faut examiner en premier.

La skill review est-elle adaptée aux débutants ?

Dans l’ensemble, oui, si l’utilisateur peut décrire la branche ou la PR. Les débutants profitent de la checklist guidée, mais ils doivent tout de même fournir un vrai diff et assez de contexte pour distinguer le comportement attendu des régressions.

Quand ne faut-il pas utiliser review ?

Ne l’utilisez pas pour des questions sans code, du brainstorming ou des discussions d’architecture abstraites sans ensemble de changements concret. Ce n’est pas non plus le bon choix si vous voulez seulement une vérification rapide et que vous n’avez pas besoin de constats ligne par ligne.

À quoi faut-il s’attendre avec review for PR Review ?

Attendez-vous à des commentaires concis, orientés correctifs, avec une priorisation par gravité. La skill est conçue pour faire ressortir les bloqueurs d’intégration, pas pour réécrire tout le repo ni produire un résumé de félicitations.

Comment améliorer la skill review

Donnez des inputs plus précis

Les meilleurs inputs pour review skill nomment la branche de base, le sous-système à risque et le niveau d’exigence attendu. Au lieu de « review my PR », utilisez par exemple : « review feature/payment-retry against origin/main; prioritize data safety, idempotency, and any behavior change that could break clients. »

Ajoutez le contexte qui change le jugement

Si le changement est volontairement risqué, dites-le. Si un pattern est autorisé par la politique du projet, mentionnez-le dès le départ. Cela réduit les faux positifs et aide la revue à se concentrer sur les vrais arbitrages plutôt que de rejouer des décisions déjà actées.

Demandez le format dont vous avez besoin

Si vous voulez une sortie orientée intégration, demandez des constats avec file:line, la gravité et des correctifs concrets. Si vous ne voulez que les bloqueurs, dites-le. Si vous voulez une couverture spécialisée, demandez-la explicitement pour que la revue ne s’arrête pas au premier passage.

Itérez après le premier passage

Servez-vous de la première revue pour corriger les problèmes évidents, puis relancez review sur le diff mis à jour. Les gains de qualité les plus importants viennent généralement d’un périmètre mieux défini, d’une branche de comparaison plus précise et d’un signalement explicite de la zone de risque qui vous importe le plus.