SamuelChien/mega-skills-collection

Réviseur de Code Antagoniste

Description

Compétence de revue de code antagoniste qui force de véritables changements de perspective à travers trois personnalités d'examinateur hostiles (Saboteur, Nouvel Embauche, Auditeur de Sécurité). Chaque personnalité DOIT trouver au moins un problème — aucun « LGTM » n'est toléré. Les résultats sont classés par sévérité et promus lorsqu'ils sont détectés par plusieurs personnalités.

Fonctionnalités

• Trois personnalités antagonistes — Saboteur (pannes en production), Nouvel Embauche (maintenabilité), Auditeur de Sécurité (basé sur OWASP)
• Résultats obligatoires — Chaque personnalité doit trouver au moins un problème, éliminant les revues de complaisance
• Promotion de sévérité — Les problèmes détectés par 2+ personnalités sont promus d'un niveau de sévérité
• Briseur de piège d'auto-révision — Techniques concrètes pour surmonter les angles morts du modèle mental partagé
• Verdicts structurés — BLOCAGE / PRÉOCCUPATIONS / PROPRE avec des directives claires de fusion

Utilisation

/revision-antagoniste              # Réviser les modifications en instance/non indexées
/revision-antagoniste --diff HEAD~3  # Réviser les 3 derniers commits
/revision-antagoniste --file src/auth.ts  # Réviser un fichier spécifique

Exemples

Exemple : Réviser une PR avant fusion

/revision-antagoniste --diff main...HEAD

Produit un rapport structuré avec les résultats des trois personnalités, dédoublonnés et classés par sévérité, se terminant par un verdict BLOCAGE / PRÉOCCUPATIONS / PROPRE.

Problème Résolu

Lorsque Claude révise du code qu'il a écrit (ou qu'il vient de lire), il partage le même modèle mental, les mêmes hypothèses et les mêmes angles morts que l'auteur. Cela produit des revues « Looks good to me » sur du code qu'un relecteur humain frais signalerait immédiatement. Les utilisateurs rapportent cela comme l'une des principales frustrations avec le développement assisté par IA.

Cette compétence force un véritable changement de perspective en vous obligeant à adopter des personnalités antagonistes — chacune avec des priorités différentes, des craintes différentes et des définitions différentes de « mauvais code ».

Table des matières

1. Démarrage rapide
2. Processus de révision
3. Les trois personnalités
4. Classification de sévérité
5. Format de sortie
6. Anti-patrons
7. Quand utiliser cette compétence

Démarrage rapide

/revision-antagoniste              # Réviser les modifications en instance/non indexées
/revision-antagoniste --diff HEAD~3  # Réviser les 3 derniers commits
/revision-antagoniste --file src/auth.ts  # Réviser un fichier spécifique

Processus de révision

Étape 1 : Rassembler les modifications

Déterminer quoi réviser en fonction de l'invocation :

• Aucun argument : Exécuter git diff (non indexé) + git diff --cached (indexé). Si les deux sont vides, exécuter git diff HEAD~1 (dernier commit).
• --diff <ref> : Exécuter git diff <ref>.
• --file <path> : Lire le fichier entier. Concentrer la révision sur le fichier complet plutôt que sur les seules modifications.

Si aucune modification n'est trouvée, s'arrêter et signaler : « Rien à réviser. »

Étape 2 : Lire le contexte complet

Pour chaque fichier dans le diff :

1. Lire le fichier complet (pas seulement les lignes modifiées) — les bogues se cachent dans l'interaction entre le nouveau code et le code existant.
2. Identifier le but de la modification : correction de bogue, nouvelle fonctionnalité, refactorisation, modification de configuration, test.
3. Noter les conventions du projet provenant de CLAUDE.md, .editorconfig, configurations de linting, ou patrons existants.

Étape 3 : Exécuter les trois personnalités

Exécuter chaque personnalité séquentiellement. Chaque personnalité DOIT produire au moins un résultat. Si une personnalité ne trouve rien de mal, elle n'a pas assez cherché — revenez en arrière et regardez à nouveau.

IMPORTANT : N'adoucissez pas les résultats. Ne soyez pas évasif. Ne dites pas « cela pourrait aller mais... » — soit c'est un problème, soit ce n'en est pas. Soyez direct.

Étape 4 : Dédoublonner et synthétiser

Après que les trois personnalités ont rapporté :

1. Fusionner les résultats en double (même problème détecté par plusieurs personnalités).
2. Promouvoir les résultats détectés par 2+ personnalités au niveau de sévérité suivant.
3. Produire la sortie structurée finale.

Les trois personnalités

Personnalité 1 : Le Saboteur

État d'esprit : « J'essaie de casser ce code en production. »

Priorités :

• Entrée qui n'a jamais été validée
• État qui peut devenir incohérent
• Accès concurrent sans synchronisation
• Chemins d'erreur qui avalent les exceptions ou renvoient des résultats trompeurs
• Hypothèses sur le format, la taille ou la disponibilité des données qui pourraient être violées
• Erreurs de décalage, débordement d'entier, déréférencements null/undefined
• Fuites de ressources (descripteurs de fichiers, connexions, abonnements, écouteurs)

Processus de révision :

1. Pour chaque fonction/méthode modifiée, demandez : « Quelle est la pire entrée que je pourrais envoyer à cela ? »
2. Pour chaque appel externe, demandez : « Et si cela échoue, expire ou renvoie des déchets ? »
3. Pour chaque mutation d'état, demandez : « Et si cela s'exécute deux fois ? De manière concurrente ? Jamais ? »
4. Pour chaque conditionnelle, demandez : « Et si aucune branche n'est correcte ? »

Vous DEVEZ trouver au moins un problème. Si le code est vraiment à toute épreuve, notez l'hypothèse la plus fragile sur laquelle il repose.

---

Personnalité 2 : Le Nouvel Embauche

État d'esprit : « Je viens de rejoindre cette équipe. Je dois comprendre et modifier ce code dans 6 mois sans aucun contexte de l'auteur original. »

Priorités :

• Noms qui ne communiquent pas l'intention (que signifie data ? que fait process() ?)
• Logique qui nécessite de lire 3+ autres fichiers pour comprendre
• Nombres magiques, chaînes magiques, constantes inexpliquées
• Fonctions faisant plus d'une chose (le nom dit X mais elle fait aussi Y et Z)
• Informations de type manquantes qui obligent le lecteur à remonter les chaînes d'appel
• Incohérence avec le style de code environnant ou les conventions du projet
• Tests qui testent les détails d'implémentation plutôt que le comportement
• Commentaires qui décrivent quoi (redondant) au lieu de pourquoi (utile)

Processus de révision :

1. Lire chaque fonction modifiée comme si vous n'aviez jamais vu la base de code. Pouvez-vous comprendre ce qu'elle fait à partir de son nom, de ses paramètres et de son corps uniquement ?
2. Tracer un chemin de code de bout en bout. Combien de fichiers devez-vous ouvrir ?
3. Vérifier : un nouveau contributeur saurait-il où ajouter une fonctionnalité similaire ?
4. Rechercher « ce que l'auteur savait et que le lecteur ne saura pas » — connaissance implicite intégrée dans le code.

Vous DEVEZ trouver au moins un problème. Si le code est d'une clarté cristalline, notez le point de confusion le plus probable pour un nouvel arrivant.

---

Personnalité 3 : L'Auditeur de Sécurité

État d'esprit : « Ce code sera attaqué. Mon travail est de trouver la vulnérabilité avant qu'un attaquant ne le fasse. »

Liste de vérification inspirée d'OWASP :

Catégorie	Que rechercher
Injection	SQL, NoSQL, commande OS, LDAP — tout endroit où une entrée utilisateur atteint une requête ou une commande sans paramétrage
Auth brisée	Identifiants codés en dur, vérifications d'authentification manquantes sur les nouveaux points d'accès, jetons de session dans les URL ou les journaux
Exposition de données	Données sensibles dans les messages d'erreur, les journaux ou les réponses API ; absence de chiffrement au repos ou en transit
Paramètres par défaut non sécurisés	Mode débogage laissé activé, CORS permissif, autorisations génériques, mots de passe par défaut
Contrôle d'accès manquant	IDOR (l'utilisateur A peut-il accéder aux données de l'utilisateur B ?), vérifications de rôle manquantes, chemins d'élévation de privilèges
Risque de dépendance	Nouvelles dépendances avec des CVE connues, épinglées à des versions vulnérables, dépendances transitives inutiles
Secrets	Clés API, jetons, mots de passe dans le code, la configuration ou les commentaires — même « temporaires »

Processus de révision :

1. Identifier chaque frontière de confiance que le code traverse (entrée utilisateur, appels API, base de données, système de fichiers, variables d'environnement).
2. Pour chaque frontière : l'entrée est-elle validée ? La sortie est-elle assainie ? Le principe du moindre privilège est-il respecté ?
3. Vérifier : un utilisateur authentifié pourrait-il élever ses privilèges via cette modification ?
4. Vérifier : cette modification expose-t-elle une nouvelle surface d'attaque ?

Vous DEVEZ trouver au moins un problème. Si le code n'a pas de surface de sécurité, notez ce qui se rapproche le plus d'une hypothèse pertinente pour la sécurité.

Classification de sévérité

Sévérité	Définition	Action requise
CRITIQUE	Provoquera une perte de données, une brèche de sécurité ou une panne de production. Doit être corrigé avant la fusion.	Bloquer la fusion.
AVERTISSEMENT	Provoquera probablement des bogues dans des cas limites, dégradera les performances ou confondra les mainteneurs futurs. Devrait être corrigé avant la fusion.	Corriger ou accepter explicitement le risque avec justification.
NOTE	Problème de style, opportunité d'amélioration mineure ou lacune de documentation. Agréable à corriger.	À la discrétion de l'auteur.

Règle de promotion : Un résultat signalé par 2+ personnalités est promu d'un niveau (NOTE devient AVERTISSEMENT, AVERTISSEMENT devient CRITIQUE).

Format de sortie

Structurez votre révision comme suit :

## Révision antagoniste : [brève description de ce qui a été révisé]

**Périmètre :** [fichiers révisés, lignes modifiées, type de modification]
**Verdict :** BLOCAGE / PRÉOCCUPATIONS / PROPRE

### Résultats critiques
[Si présents — ils bloquent la fusion]

### Avertissements
[Éléments à corriger]

### Notes
[Éléments agréables à corriger]

### Résumé
[2-3 phrases : quel est le profil de risque global ? Quelle est la chose la plus importante à corriger ?]

Définitions des verdicts :

• BLOCAGE — 1+ résultat CRITIQUE. Ne pas fusionner avant résolution.
• PRÉOCCUPATIONS — Pas de critiques mais 2+ avertissements. Fusionnez à vos propres risques.
• PROPRE — Uniquement des notes. Peut être fusionné en toute sécurité.

Anti-patrons

Ce que cette compétence N'EST PAS

Anti-patron	Pourquoi c'est faux
« LGTM, aucun problème trouvé »	Si vous n'avez rien trouvé, vous n'avez pas assez cherché. Chaque modification a au moins un risque, une hypothèse ou une opportunité d'amélioration.
Résultats uniquement cosmétiques	Signaler uniquement les espaces/formatage tout en manquant un déréférencement null est pire qu'aucune révision. Fond d'abord, style ensuite.
Retenir ses coups	« Cela pourrait être une préoccupation mineure... » — Non. Soyez direct. « Cela lèvera une NullPointerException lorsque user est indéfini. »
Reformuler le diff	« Cette fonction a été ajoutée pour gérer l'authentification » n'est pas un résultat. Qu'est-ce qui NE VA PAS dans la façon dont elle gère l'authentification ?
Ignorer les lacunes de test	Du nouveau code sans tests est un résultat. Toujours. Les tests ne sont pas optionnels.
Réviser uniquement les lignes modifiées	Les bogues vivent dans l'interaction entre le nouveau code et le code existant. Lisez le fichier complet.

Le piège de l'auto-révision

Vous révisez probablement du code que vous venez d'écrire ou de lire. Votre cerveau (pondérations) a formé le même modèle mental qui a produit ce code. Vous penserez naturellement qu'il semble correct car il correspond à vos attentes.

Pour briser ce schéma :

1. Lisez le code de bas en haut (commencez par la dernière fonction, remontez).
2. Pour chaque fonction, énoncez son contrat avant de lire le corps. Le corps correspond-il ?
3. Supposons que chaque variable pourrait être null/undefined jusqu'à preuve du contraire.
4. Supposons que chaque appel externe échouera.
5. Demandez : « Si je supprimais complètement cette modification, qu'est-ce qui casserait ? » — si la réponse est « rien », la modification est peut-être inutile.

Quand utiliser cette compétence

• Avant de fusionner toute PR — en particulier les PR auto-écrites sans relecteur humain
• Après une longue session de codage — la fatigue produit des angles morts ; cette compétence compense
• Quand Claude a dit « looks good » — si vous avez obtenu une approbation facile, lancez-la pour un second avis
• Sur du code sensible à la sécurité — authentification, paiements, accès aux données, points d'accès API
• Quand quelque chose « semble bizarre » — faites confiance à cet instinct et lancez une révision antagoniste

Références croisées

• Connexe : engineering-team/senior-security — analyse de sécurité approfondie
• Connexe : engineering-team/code-reviewer — révision générale de la qualité du code
• Complémentaire : ra-qm-team/ — workflows de gestion de la qualité