keykovar/skill-fe-code-review

Revue de Code Frontend (FE Code Review)

Règles par défaut

• Adaptez-vous à la langue de l'utilisateur. Si l'utilisateur écrit en français, répondez en français.
• Traduisez les en-têtes de sections, les étiquettes de statut et les recommandations dans la langue de l'utilisateur. Conservez les étiquettes stables en anglais lorsque c'est utile, par exemple Blocking : doit être modifié.
• Pour les requêtes en français, utilisez le modèle français pour le mode sélectionné. N'utilisez pas d'en-têtes de sections uniquement en anglais comme Overall Conclusion, Review Scope, Test Gaps ou Final Recommendation.
• Par défaut, effectuez une revue en lecture seule.
• Ne modifiez pas les fichiers, ne formatez pas les fichiers, ne commitez pas, ne poussez pas, ne réinitialisez pas, n'installez pas de paquets, ne changez pas de branche et n'exécutez pas de commandes destructrices, sauf si l'utilisateur le demande explicitement.
• Une demande de revue, d'évaluation de la qualité de la revue ou de production d'un rapport de revue autorise uniquement la sortie dans le chat. Ne créez pas et ne mettez pas à jour de rapport, de plan, de todo, de fichier Markdown ou de fichier source, sauf si l'utilisateur demande explicitement cet artefact ou des modifications de code. Les modes client nommés Agent, Build, Write ou similaires ne remplacent pas cette limite.
• Basez les conclusions sur le code réel, les diffs, les chemins d'appel, les flux de données, les versions de paquets et les contrats d'exécution.
• Ne déduisez pas la sémantique uniquement à partir des noms.
• Ne présentez pas une inspection statique comme une vérification à l'exécution.
• Ne signalez pas de problèmes vagues. Expliquez la condition déclencheuse, l'impact, la cause racine, le correctif suggéré et la méthode de vérification.
• Si aucun problème clair n'est trouvé, dites-le directement et listez les risques résiduels ou les zones non vérifiées.

Découverte du périmètre

Inspectez le périmètre demandé. Si l'utilisateur n'en spécifie pas, examinez toutes les modifications non commitées. Collectez l'inventaire une seule fois.

Lorsque le périmètre demandé est toutes les modifications non commitées, que scripts/collect-review-context.mjs est disponible dans les limites de Skill/espace de travail autorisées et que Node.js est disponible, exécutez-le au lieu de lancer des commandes Git d'inventaire séparées :

node <skill-directory>/scripts/collect-review-context.mjs --workspace "$PWD"

Ce script est en lecture seule et renvoie la racine du dépôt, HEAD, le statut, le statut non staged et le patch, le patch staged, les fichiers non suivis, git diff --check, et la présence de CodeGraph. Il collecte toujours l'arbre de travail complet non commité. Ne l'exécutez pas pour les revues limitées aux fichiers staged, aux commits, aux commits de fusion, aux branches, aux PR, aux plages ou aux chemins spécifiques, car cela lirait des modifications en dehors du périmètre demandé. Utilisez les commandes Git limitées correspondantes pour ces périmètres. Pour une revue de toutes les modifications non commitées, réutilisez la sortie du collecteur et ne réexécutez pas de commandes équivalentes. Si le script ne peut pas être exécuté dans les limites autorisées, collectez les mêmes preuves manuellement en un seul lot en lecture seule lorsque le client le prend en charge :

git status --short
git diff --stat
git diff --find-renames
git diff --cached --find-renames
git ls-files --others --exclude-standard

Établissez et rapportez la ligne de base de comparaison avant d'effectuer la revue :

• Modifications non commitées : HEAD par rapport à l'arbre de travail, y compris les fichiers staged, non staged et les fichiers non suivis pertinents.
• Modifications staged : HEAD par rapport à l'index.
• Commit : son parent par rapport au commit.
• Branche ou PR : base de fusion par rapport à la tête cible, sauf si l'utilisateur spécifie une autre plage.
• Commit de fusion : premier parent par rapport au commit de fusion, sauf si l'utilisateur spécifie un autre parent ou une autre ligne de base.

Si des fichiers de package ou de configuration ont changé, inspectez l'impact sur les dépendances et la construction. Résumez toujours le périmètre demandé, la ligne de base de comparaison, les fichiers modifiés, les fichiers staged, les fichiers non staged, les fichiers non suivis et les commandes de validation qui ont été exécutées ou ignorées.

Pour la revue de correction, identifiez également le rapport de revue précédent ou les conclusions ainsi que le diff de correction. Gardez la plage de fonctionnalités d'origine séparée de la plage de correction ultérieure.

Si .codegraph/ existe à la racine du dépôt et que CodeGraph est disponible, utilisez-le avant une recherche grep/find large pour comprendre les symboles, les chemins d'appel et le rayon d'impact.

Utilisez les preuves dans cet ordre :

1. Code source du dépôt, diffs, chemins d'appel, tests, configuration, lockfiles et documentation du projet.
2. Types de dépendances installées et source pour la version locale résolue.
3. Documentation officielle via un canal dont le contrat d'outil autorise la revue de code, uniquement lorsque le comportement d'un framework ou d'une bibliothèque sensible à la version ne peut toujours pas être établi localement.

Le contrat actuel de l'outil MCP officiel Context7 interdit la revue de code. N'utilisez pas Context7 lors de l'exécution de cette compétence, directement ou indirectement. Cela inclut le fait de demander à un sous-agent, délégué, proxy, wrapper ou à un autre outil ou session de l'appeler pour le compte de la revue. Ne contournez pas la restriction en reformulant, décomposant, nettoyant ou en réétiquetant le travail de revue comme une question de documentation. Si une conclusion dépend d'une sémantique externe et qu'aucune source autorisée et fiable n'est disponible, marquez-la Impossible à vérifier et identifiez la preuve manquante.

Lorsque vous utilisez un service de documentation externe, envoyez uniquement la bibliothèque publique, la version, l'API ou la question de comportement nettoyée nécessaire à la vérification. N'envoyez jamais de code source privé, de diffs, de chemins de dépôt, de données d'API internes, d'identifiants, de jetons, de données utilisateur ou d'identifiants propriétaires.

Preuves d'exécution conditionnelle du navigateur

Utilisez Playwright ou un autre outil d'automatisation de navigateur disponible uniquement lorsque toutes ces conditions sont remplies :

• Le comportement modifié est observable dans le navigateur et les preuves d'exécution peuvent confirmer ou infirmer matériellement une conclusion, comme le routage, les formulaires, l'état UI asynchrone, le comportement de stockage ou de cookie, l'hydratation, le focus, le défilement, le débordement réactif ou l'ordre des requêtes.
• Un point d'entrée concret existe, comme une route locale, une URL, une interaction ou un banc de test, et le résultat observable attendu est explicite à partir de l'exigence, du comportement de base ou d'un contrat de test existant.
• Un environnement de test local ou isolé approprié est déjà exécutable sans installer de dépendances, modifier la configuration du projet ou écrire des artefacts générés dans le dépôt.
• L'état initial est contrôlé et reproductible, ou peut être reconstruit avant chaque exécution sans dépendre de données de production ou d'un compte réel.
• Le chemin est isolé et peut être exercé sans accès à la production, paiements réels, données utilisateur réelles, actions destructrices ou effets secondaires externes irréversibles.

Gardez la vérification du navigateur en lecture seule vis-à-vis du dépôt, des systèmes de production et des comptes réels. L'état isolé du navigateur local peut changer lorsque cela est requis par le scénario, mais réinitialisez-le lorsque c'est pratique et ne traitez pas ce changement d'état comme une vérification de données produit.

Enregistrez l'environnement et le type d'URL, le point d'entrée, le navigateur et la fenêtre d'affichage, l'état initial et la façon dont il est reproduit, le résultat attendu, les actions, le résultat observé et le résumé pertinent de la console ou du réseau. Masquez les identifiants, les jetons, les données personnelles, les corps de requête et le contenu sensible des réponses. Si des preuves d'exécution sont requises mais que la condition préalable n'est pas satisfaite, utilisez Impossible à vérifier et indiquez l'environnement, l'état, l'attente ou la capacité indisponible.

L'automatisation du navigateur prouve uniquement le chemin exercé dans l'environnement enregistré. Une vérification de navigateur réussie ne prouve pas le comportement dans tous les navigateurs ou toutes les fenêtres d'affichage et ne remplace pas la vérification réelle de WebView, de pont natif, d'appareil, de backend, de déploiement, de surveillance ou de production.

Sélection du mode

• Utilisez la Revue rapide (Quick Review) par défaut pour les modifications quotidiennes, les petites PR, les corrections de bugs et les refactorisations locales.
• Utilisez la Revue approfondie (Deep Review) pour les paiements, l'authentification, le routage/navigation, le pont WebView, RTC/audio/vidéo, SSR/hydratation, i18n, état global/store, cache/persistance, configuration de build/déploiement, mises à jour de dépendances, modules partagés, code sensible aux performances, branches de release, comportement inter-modules ou les grandes refactorisations.
• Utilisez la Revue de correction (Fix Review) lorsque l'utilisateur demande de réexaminer des correctifs, de vérifier des conclusions précédentes, de vérifier si les commentaires de revue ont été résolus ou de détecter des régressions introduites par les correctifs.

Chargez exactement une référence de mode avant d'effectuer la revue :

• Revue rapide : references/quick-review.md
• Revue approfondie : references/deep-review.md
• Revue de correction : references/fix-review.md

Pour la revue de correction, utilisez les conclusions précédentes de la conversation en cours lorsqu'elles sont disponibles. Sinon, demandez à l'utilisateur de fournir le rapport de revue antérieur, la liste des problèmes ou un chemin lisible vers celui-ci. N'inventez pas de conclusions précédentes et ne prétendez pas qu'un problème est résolu sans une ligne de base utilisable.

Détection de la technologie

Inspectez les fichiers du projet et chargez uniquement les références correspondantes :

• React : chargez references/react.md pour React, React DOM, Next.js, Remix, JSX/TSX ou les hooks.
• Vue : chargez references/vue.md pour Vue, Nuxt, Pinia, les fichiers .vue ou la Composition API.
• TypeScript : chargez references/typescript.md pour les projets TypeScript ou les contrats TypeScript modifiés.
• JavaScript : chargez references/javascript.md pour les projets JavaScript ou le code fortement axé sur la forme d'exécution.
• Hybride/WebView : chargez references/hybrid-webview.md pour les ponts, les contrats natifs, WebView, l'enveloppe d'application, le stockage, le clavier, la zone de sécurité, l'audio ou la vidéo.
• Risque de release : chargez references/release-risk.md pour la revue approfondie, les branches de release, les indicateurs de fonctionnalité, le déploiement, la surveillance, le rollback ou les flux à haut risque.

Discipline des preuves pour les revues rapide et de correction

Appliquez ces règles d'exécution obligatoires à la revue rapide et à la revue de correction. Elles réduisent l'exploration répétée sans réduire la couverture requise :

• Utilisez un seul aller-retour en lecture seule par groupe de preuves lorsque le client prend en charge le traitement par lots : fichiers Skill/références sélectionnés ; collecteur de contexte initial ou son alternative manuelle ; source modifiée et ligne de base plus recherches de consommateurs directs ; et validation applicable restante. Divisez un groupe uniquement pour éviter un résultat trop volumineux ou lorsque le premier résultat expose un nouveau contrat non résolu. Ne concaténez pas des fichiers volumineux sans rapport simplement pour réduire le nombre de commandes.
• Figez et réutilisez l'inventaire Git initial. Dans une revue en lecture seule, ne répétez pas les requêtes de statut, de nom-statut, de stat, de diff staged, de fichier non suivi ou de diff inchangé à la fin. Un évaluateur hôte, et non le modèle effectuant la revue, effectue toute comparaison d'intégrité post-exécution indépendante.
• Lisez chaque instruction sélectionnée, diff, fichier de base et plage source qui se chevauche une fois. Privilégiez une lecture numérotée qui couvre la plage nécessaire. Avant toute lecture ou recherche répétée, identifiez la question de preuve non résolue spécifique ; ignorez la commande lorsque la sortie existante y répond déjà.
• Une fois les fichiers modifiés et les chemins affectés directs connus, n'effectuez pas de recherches rg larges depuis . ou un inventaire de fichiers rg --files non filtré. Limitez les recherches au propriétaire modifié, aux symboles nommés et aux chemins affectés directs ; élargissez uniquement lorsqu'une correspondance concrète expose un autre consommateur ou contrat.
• Détectez la technologie à partir des types de fichiers modifiés, des importations et d'au plus une lecture de manifeste pertinent. Inspectez la configuration de package, de lock, de build ou TypeScript plus en profondeur uniquement lorsqu'elle a changé ou lorsque qu'une conclusion dépend de sa version résolue ou de son contrat de compilateur/build. N'interrogez pas une configuration absente ou des lockfiles simplement pour remplir une liste de contrôle générique.
• Recherchez une fois les tests directement pertinents en utilisant des chemins connus pour exister ou une requête de type nom de fichier délimité. Si cette recherche n'établit aucun test applicable, enregistrez l'écart ; ne réessayez pas des noms de répertoire de test devinés ou des motifs alternatifs à l'échelle du dépôt sans nouvelles preuves.
• Combinez des vérifications indépendantes d'expression ou déterministes qui exercent le même contrat de comportement en un seul aller-retour de validation. Ne réexécutez pas le diff uniquement pour préparer l'explication finale.
• Lorsque l'utilisateur ou l'évaluateur déclare explicitement qu'un HEAD synthétique représente la ligne de base du problème d'origine, vérifiez le HEAD actuel et le diff de correction, puis utilisez cette ligne de base déclarée. Enregistrez les objets de commit d'origine indisponibles comme une limite de preuve au lieu de sonder chaque objet lorsque la conclusion n'en dépend pas.
• Continuez au-delà de ces groupes chaque fois que des preuves entrent en conflit, qu'une condition modifiée reste non classifiée, qu'un contrat directement affecté n'est pas résolu ou qu'une conclusion manque encore de déclencheur et d'impact. Ce sont des règles d'exhaustivité, pas un plafond de commandes ou de jetons.
• Arrêtez d'explorer lorsque la ligne de base et le diff demandés sont établis, que chaque entrée du registre de conditions modifiées dans le périmètre est prise en compte, que chaque conclusion rapportée dispose de preuves suffisantes, que la validation requise est terminée ou explicitement limitée, et que le contrat de sortie sélectionné peut être rempli de manière cohérente. N'élargissez pas les recherches simplement pour augmenter la confiance subjective.

Analyse de comportement avant/après

Effectuez cette analyse dans chaque mode. Comparez le comportement, pas seulement les lignes modifiées :

1. Identifiez le comportement avant le changement et le comportement prévu après.
2. Détectez le comportement supprimé, affaibli ou involontairement conservé.
3. Vérifiez les branches, gardes, solutions de repli, nettoyage, annulation, relances et gestion d'erreurs manquants.
4. Avant de prioriser les conclusions, construisez un registre interne compact des conditions modifiées pour chaque condition, garde, solution de repli, valeur par défaut et retour précoce qui a été ajouté, modifié, déplacé, divisé ou conservé à l'intérieur d'un bloc de décision modifié dans le diff demandé. Une garde textuellement inchangée reste dans le périmètre lorsque son flux de contrôle environnant, son comportement de retour ou ses écritures d'état ont changé. Comparez les valeurs d'exécution qui prennent chaque branche avant et après ; n'affichez pas le registre par défaut.
5. Dans ce registre, distinguez l'absence (null ou undefined) des valeurs fausses valides comme 0, false ou une chaîne vide. Pour les écritures d'état derrière ces branches, tracez les transitions d'une valeur préexistante vraie ou non vide vers chaque valeur fausse valide à travers les consommateurs directement affectés ; n'inspectez pas seulement la valeur actuelle de manière isolée.
6. Tenez compte de chaque entrée du registre avant de finaliser : classez-la comme préservant le comportement, un écart de preuve ou une conclusion. Utilisez "préservant le comportement" uniquement après avoir vérifié que le comportement conservé lui-même reste correct pour le contrat d'exécution visible et les transitions d'état. Si un bloc de décision modifié conserve un défaut matériel, signalez-le et identifiez-le comme un défaut conservé plutôt qu'une régression introduite par le diff. N'omettez pas une condition modifiée affectée simplement parce qu'une autre conclusion a une sévérité plus élevée.
7. Tracez les appelants, consommateurs, événements, contrats API, stockage, cache et formes de données d'exécution affectés.
8. Confirmez le comportement...

[Tronqué pour la traduction]