differential-review

Vue d’ensemble du skill differential-review

Ce que fait differential-review

Le skill differential-review est un workflow de revue axé sécurité pour examiner des PR, des commits et des diffs avec plus de rigueur qu’un prompt classique. Il est conçu pour les relecteurs qui doivent déterminer si une modification introduit des régressions, en particulier dans les parcours d’authentification, la cryptographie, les appels externes, les changements d’état et d’autres zones à haut risque.

Pour qui il est le plus adapté

Utilisez le skill differential-review si vous passez en revue du code sensible sur le plan sécurité, si vous héritez d’un gros diff, ou si vous avez besoin d’une méthode reproductible qui s’adapte à la taille de la base de code. Il convient particulièrement aux ingénieurs, aux reviewers sécurité et aux auditeurs assistés par IA qui veulent des constats étayés par des preuves plutôt qu’une simple lecture superficielle ligne par ligne.

Ce qui le différencie

La principale valeur de differential-review est qu’il impose de prendre du contexte avant de conclure : historique de base, périmètre d’impact, couverture des tests et limites explicites du niveau de confiance. Le dépôt pousse aussi la sortie vers un rapport markdown structuré, donc le skill n’est pas seulement un prompt d’analyse ; c’est un processus de revue avec un livrable.

Comment utiliser le skill differential-review

Installer et charger le skill

Une installation typique de differential-review install commence par la chaîne d’outillage du dépôt, puis pointe l’agent vers le dossier du skill. Pour ce package, le chemin d’installation est plugins/differential-review/skills/differential-review. Si vous utilisez le repo de skills de Trail of Bits, installez-le avec la commande de skills du projet, puis ouvrez d’abord SKILL.md.

Lui donner une entrée adaptée à une revue

Pour tirer le meilleur parti de differential-review usage, demandez-lui d’examiner une plage base..head, un commit ou une PR précise, et nommez la préoccupation sécurité si vous en avez une. De bonnes demandes ressemblent à : « Revois base..head pour un contournement d’authentification, une réentrance et des tests manquants ; concentre-toi sur les chemins d’appels externes et les transitions d’état. » Des demandes vagues comme « vérifie ce diff » laissent trop de place à l’approximation.

Lire d’abord les bons fichiers

Un bon differential-review guide commence par SKILL.md, puis methodology.md, adversarial.md, patterns.md et reporting.md. Ces fichiers expliquent à l’agent comment construire le contexte de référence, quels modèles d’attaque utiliser, quels motifs rechercher et comment formater le rapport final. Il n’y a ni scripts d’aide ni dossiers de référence supplémentaires dans ce plugin, donc les fichiers du skill font foi.

Conseils de workflow qui changent la qualité du rendu

Utilisez le skill lorsque vous pouvez fournir un diff propre, un commit de base et suffisamment de contexte sur le dépôt pour inspecter les appelants et les tests. Indiquez si la base de code est petite, moyenne ou grande, ou laissez-le déduire l’échelle, mais ne sautez pas l’étape du baseline et de l’historique. Pour differential-review for Code Review, les entrées les plus utiles sont concrètes : fichiers modifiés, frontières de confiance probables, fonctions suspectes et historique de régression déjà connu.

FAQ du skill differential-review

differential-review est-il réservé aux revues de sécurité ?

Oui, principalement. Il est conçu pour une revue différentielle centrée sécurité, pas pour du simple nettoyage stylistique ni pour valider une fonctionnalité. Vous pouvez toujours l’utiliser pour une revue de code classique, mais sa vraie valeur apparaît quand la modification peut toucher aux frontières de confiance, à l’intégrité des données ou à l’exploitabilité.

En quoi est-il différent d’un prompt normal ?

Un prompt normal peut résumer le diff ; differential-review essaie de prouver ou d’infirmer un risque à partir de l’historique, du périmètre d’impact et d’un modèle d’attaquant. Il attend aussi un rapport markdown, ce qui facilite la transmission ou l’archivage du résultat.

Est-il adapté aux débutants ?

Il peut être utilisé par des débutants, mais il suppose que l’utilisateur sache pointer un diff précis et souhaite une analyse structurée. Si vous connaissez mal la base de code, le skill reste utile parce qu’il exige du contexte de référence et rend explicites les zones de couverture manquantes.

Quand ne faut-il pas l’utiliser ?

N’utilisez pas differential-review pour des changements textuels triviaux, des PR à faible risque qui ne touchent qu’au formatage, ou des cas où vous n’avez besoin que d’un résumé d’un paragraphe. C’est excessif lorsqu’il n’y a pas de risque réel de sécurité ou de régression, et son processus n’apporte de valeur que s’il y a quelque chose qui mérite une vérification approfondie.

Comment améliorer le skill differential-review

Fournir un meilleur contexte de revue

L’amélioration la plus importante consiste à donner au skill la surface exacte à examiner : numéro de PR, plage de commits, branche cible et toute zone de risque suspectée. Si vous connaissez le domaine du projet, dites-le d’emblée : une modification Solidity, un flux d’authentification d’API ou un chemin de paiement orientera l’analyse vers le bon modèle d’attaque.

Demander le bon niveau de profondeur dès le premier passage

Pour améliorer differential-review usage, précisez si vous vous souciez davantage de la correction, de l’exploitabilité ou du risque de régression. Par exemple : « Concentre-toi sur les fonctions appelables de l’extérieur, les validations modifiées et les tests manquants pour les nouvelles branches. » Cela recentre la recherche sur les chemins les plus importants et réduit les faux signaux.

Surveiller les modes d’échec les plus courants

Les erreurs les plus fréquentes consistent à considérer les petits diffs comme peu risqués, à ignorer l’historique du code supprimé et à oublier les appelants transitifs lorsqu’on évalue le périmètre d’impact. Le skill est explicitement écrit pour éviter ces pièges, mais il a quand même besoin d’un baseline concret et d’un diff clairement borné pour bien fonctionner.

Itérer après le premier rapport

Servez-vous du premier rapport pour affiner le passage suivant. Si le résultat est trop large, demandez un modèle d’attaquant plus ciblé ou une inspection plus poussée d’un sous-système précis. S’il est trop superficiel, demandez une nouvelle exécution avec davantage d’historique, un contrôle plus strict des tests ou un focus plus serré sur les invariants et les chemins de régression.