vercel-react-best-practices (vercel-labs/agent-skills)

Name: vercel-react-best-practices (vercel-labs/agent-skills) review
Item: vercel-react-best-practices (vercel-labs/agent-skills)
Rating: 24.3
Author: Agent Skills

Applique les recommandations de performance React et Next.js de Vercel aux composants, au chargement de données et aux bundles.

Les bonnes pratiques React de Vercel : font passer une optimisation Next.js de 2.3 à 3.6/5, mais la version en une phrase atteint 4.6 pour 75 % des tokens

Selon les casSûr

Codex CLI · gpt-6-astra

24.3 / 30

Gain par rapport à sans skill : +0.85 · Selon les cas · 18 exécutions

Selon les cas : le gain +0.85 est inférieur à +1.0. Pour être recommandé, il faut un total de 22/30, une qualité de sortie de 3.5 et un gain de +1.0.

SOTA

Réussi

Testé avec Codex.

Couvre Codex, Claude Code

Codex CLI 0.166 (palier SOTA) : 18 exécutions notées. Une réussite ici couvre aussi Claude Code selon notre règle de palier ; elle ne dit rien du second palier.

Scores

Chaque dimension va de 0 à 5 et les six forment le total sur 30. 5 est la meilleure note dans chaque dimension. Coût 5 signifie bon marché et rapide. Installation 5 signifie facile.

Fiabilité du déclenchement: 5.0
Gain par rapport à sans skill: 2.9
Qualité de sortie: 4.4
Coût en tokens et en temps: 3.0
Installation et portabilité: 4.0
Sécurité: 5.0

Revue de sécurité

Sûr

Scan statique : 6 CRITIQUE / 0 ÉLEVÉ / 0 MOYEN. Revue manuelle : sûr à exécuter dans un bac à sable sans réseau (résultats du scanner expliqués). Un scan propre ne prouve pas qu'un skill est sûr.

Installer

npx skills@latest add vercel-labs/agent-skills --skill react-best-practices

Source

Commit épinglé: 1a2c79d4e6c4a2283dc2c614b6538cbe1ed5ca62

Testé: 2026-11-02

Ce que nous avons testé

Revue de performance d'un tableau de bord — Relisez OrdersDashboard.tsx et page.tsx (une app Next.js 15) pour des problèmes de performance. Listez-les du plus grave au moins grave, avec pour chacun le fichier et ce qu'il faut changer. Ne modifiez aucun fichier. Écrivez la liste dans votre réponse finale.
Optimiser le composant de tableau de bord sur place — Optimisez OrdersDashboard.tsx pour la performance. Modifiez le fichier sur place, conservez le comportement et les props du composant. (Il n'y a ni réseau ni npm install ; n'essayez pas de l'exécuter.)
Écrire une page serveur de tableau de bord — Écrivez app/dashboard/page.tsx, un composant serveur Next.js 15 (App Router). Pour l'utilisateur connecté (getSession() de '@/lib/auth' renvoie { userId }), il faut getProfile(userId), getRecentOrders(userId) et getRecommendations(userId) de '@/lib/data'…

Points forts

Fait passer le score moyen de 3.57 à 4.43 par rapport à sans skill (+0.85).
Le skill a été détecté sans être nommé : son fichier a été lu dans 6/6 exécutions avec skill.

Points faibles

Un prompt d'une phrase obtient 4.73, contre 4.43 avec le skill (-0.30).
Consomme 1.53 fois plus de tokens que sans skill.
n=2 par tâche et par bras ; les écarts inférieurs à environ 1 point sont du bruit.

Avis

Codex CLI 0.166 (gpt-6-astra, low reasoning) sur un Mac de test, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (traitement) ou absent (contrôle) ou absent avec l'exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « prompt d'une phrase »), 2 exécutions par groupe et par tâche, réseau coupé, écritures dans /tmp bloquées. Les prompts ne mentionnent jamais le skill (sauf la formulation indiquée ci-dessous). Trois tâches sur de petits fixtures Next.js 15 : relire un composant de tableau de bord et sa page pour la performance (11 problèmes plantés, listés du plus grave au moins grave) ; optimiser le composant sur place (10 contrôles : Promise.all, imports directs au lieu d'un barrel, pas d'import de tout lodash, next/dynamic pour un éditeur lourd, Row remonté hors du composant, liste dérivée au lieu de setFiltered dans un effet, pas de orders.length &&, initialiseur d'état paresseux, lookup par Map, écouteur de scroll passif) ; écrire une page serveur pour un appel de données lent et deux rapides.

Comparaison à trois bras

Bras	Score moyen (0-5)	Tokens par exécution
Sans le skill	3.57	67k
Prompt d'une phrase	4.73	77k
Avec le skill	4.43	103k

Mesuré avec Codex CLI sur 18 exécutions, noté par des contrôles basés sur des règles, sans juge LLM. Total 24.3 / 30, verdict Selon les cas.

Verdict : Selon le cas (24.3 / 30). Source : vercel-labs/agent-skills, skills/react-best-practices, épinglé au commit 1a2c79d. Installation : npx skills@latest add vercel-labs/agent-skills --skill react-best-practices. Licence : MIT (LICENSE du dépôt).

Présentation

Le skill vercel-react-best-practices de vercel-labs/agent-skills (dossier react-best-practices) : 70 fichiers de règles Markdown, regroupés par impact (cascades de requêtes, taille du bundle, performance côté serveur, récupération de données côté client, re-rendus, rendu, performance JS, patterns avancés), plus un AGENTS.md compilé. SKILL.md est un index ; l’agent charge les règles dont il a besoin. Aucun script.

Méthode de test

Codex CLI 0.166 (gpt-6-astra, raisonnement faible) sur une machine de test Mac, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (groupe avec skill), absent (groupe témoin), ou absent avec l’exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « prompt en une phrase »), 2 exécutions par groupe et par tâche, réseau désactivé, écritures dans /tmp bloquées. Les prompts ne mentionnent jamais le skill (sauf la formulation indiquée plus bas).

Trois tâches sur de petits projets Next.js 15 : relire un composant et une page de tableau de bord pour la performance (11 problèmes implantés, listés du plus grave au moins grave) ; optimiser le composant sur place (10 vérifications : Promise.all, imports directs au lieu d’un barrel, pas d’import lodash complet, next/dynamic pour un éditeur lourd, Row remonté hors du composant, liste dérivée au lieu de setFiltered dans un effet, pas de orders.length &&, initialiseur d’état paresseux, recherche par Map, écouteur de scroll passif) ; écrire une page serveur pour un appel de données lent et deux rapides.

Revue de performance d’un tableau de bord — Relisez OrdersDashboard.tsx et page.tsx (une application Next.js 15) pour des problèmes de performance. Listez-les du plus grave au moins grave, avec pour chacun le fichier et ce qu’il faut changer. Ne modifiez aucun fichier. Rédigez la liste dans votre réponse finale.
Optimiser le composant du tableau de bord sur place — Optimisez OrdersDashboard.tsx pour la performance. Modifiez le fichier sur place, conservez le comportement et les props du composant. (Il n’y a pas de réseau ni de npm install ; n’essayez pas de l’exécuter.)
Écrire une page serveur de tableau de bord — Écrivez app/dashboard/page.tsx, un composant serveur Next.js 15 (App Router). Pour l’utilisateur connecté (getSession() de '@/lib/auth' renvoie { userId }), il faut getProfile(userId), getRecentOrders(userId) et getRecommendations(userId) de '@/lib/data'…

Le scoring est programmatique (tests cachés / détection des problèmes implantés / vérifications de contraintes / rendu + OCR le cas échéant), de 0 à 5 par exécution. Aucun juge LLM n’a attribué de score.

Résultats

Le prompt en une phrase donné au troisième groupe : « Corrige la performance React/Next.js dans cet ordre : supprime les cascades de requêtes (lance les requêtes indépendantes ensemble avec Promise.all et streame les parties lentes avec Suspense), réduis la taille du bundle (importe directement au lieu de passer par des barrel files, code-splitte les composants lourds avec next/dynamic), puis évite les re-rendus inutiles (dérive les valeurs pendant le rendu, ne définis pas de composants dans des composants, remonte les valeurs statiques, utilise des initialiseurs d’état paresseux, des recherches par Map, des écouteurs de scroll passifs). »

Tâche	Score témoin	Prompt en une phrase	Avec skill	Tokens témoin	Tokens du prompt en une phrase	Tokens avec skill	Skill lu
t1-review	3.91	4.64	4.64	65k	45k	75k	2/2
t2-optimize	2.27	4.55	3.64	90k	130k	163k	2/2
t3-write	4.54	5.0	5.0	45k	53k	69k	2/2

Score moyen : 3.57 sans le skill contre 4.43 avec (écart +0.85). Tokens par exécution : 67k contre 103k (1.53x) ; temps 47s contre 52s. Groupe « prompt en une phrase » : 4.73 (gain du skill sur ce prompt : -0.3 ; gain du prompt par rapport à l’absence de skill : +1.15) ; tokens du prompt : 77k par exécution, donc le skill coûte 1.34x le prompt en une phrase.

Ce qui s’est passé

C’est sur l’optimisation sur place que cela se voit : score 2.27 témoin, 3.64 skill, 4.55 version en une phrase (les deux exécutions de chaque groupe étant identiques). Le témoin et le skill ont tous deux laissé l’import barrel from '@/components' et n’ont pas mis de code-splitting ; le témoin a aussi laissé les awaits séquentiels et l’écouteur de scroll non passif. Le skill a corrigé la cascade et l’écouteur de scroll, mais pas l’import barrel ni l’import dynamique de l’éditeur lourd ; le prompt, qui nomme exactement ces règles, a corrigé les deux.
Tâche de revue : 9 puis 7 problèmes implantés trouvés pour le témoin (8 en moyenne), contre 10 et 10 pour le skill et le prompt (10 sur 11 chacun ; le orders.length && qui affiche un 0 a été manqué par toutes les exécutions de tous les groupes). Score 3.91 témoin, 4.64 skill, 4.64 prompt.
Tâche d’écriture : tous les groupes ont placé les recommandations lentes derrière Suspense et gardé la page en composant serveur ; le témoin a parfois attendu les trois appels en séquence (score 4.1 et 5.0, skill 5.0 dans les deux, prompt 5.0 dans les deux).
Aucun groupe n’a corrigé orders.length && lors de l’édition du fichier, donc une règle présente dans le skill (rendering-conditional-render) n’a été intégrée dans aucune modification.
Le skill a été lu dans 6/6 exécutions et a coûté 103k tokens contre 67k (1.5x) et 77k pour le prompt (1.3x). Moyenne globale 3.57 témoin, 4.43 skill, 4.73 prompt.
Le scoring a été corrigé une fois pendant l’analyse : la première passe a marqué à tort les vérifications de la page et de la Map comme manquées parce que le fichier était écrit dans app/dashboard/page.tsx et que la Map était typée (new Map<string, string>()) ; les deux regex ont été corrigées et les 18 exécutions revérifiées.

Scores par dimension

Dimension	Score	Pourquoi
1_output_quality	4.43	Score moyen de 4.43/5 avec le skill (vérifications programmatiques, voir le tableau par tâche).
2_lift_vs_no_skill	2.85	+0.85 point par rapport à 3.57 sans le skill (n=2 par tâche ; un écart inférieur à ~1 point relève du bruit).
3_trigger	5.0	Fichier du skill lu dans 6/6 exécutions avec skill.
4_instructions_portability	4	Spécifique React/Next.js ; du Markdown simple que d’autres agents peuvent charger ; suit la disposition ouverte des skills.
5_efficiency	3	1.53x tokens (103k contre 67k par exécution) et 1.10x temps (52s contre 47s).
6_safety_hygiene	5	Uniquement des fichiers de règles Markdown ; 6 hits du scanner sont des `document.cookie` dans des exemples de code, lus en contexte.

Limites de ce test

Petits projets avec des problèmes de manuel connus ; un seul composant a été optimisé, donc deux exécutions par groupe montrent le même résultat pour la même raison (deux exécutions identiques).
Les 70 règles du skill n’ont été exercées que par trois tâches ; le cache serveur, SWR, les écouteurs d’événements et les règles avancées n’ont pas été implantés.
La version en une phrase énumère les mêmes règles que le test vérifie, c’est donc une borne supérieure pour un prompt court, pas un équivalent équitable pour un utilisateur qui ne connaît pas les règles.
n = 2 par groupe et par tâche : un écart inférieur à ~1 point relève du bruit.
Le scoring par règles mesure ce que les vérifications peuvent voir ; il ne peut juger du goût ni du caractère optimal d’un résultat.

Sécurité

Voir security.md. Scan : 6 CRITICAL / 0 HIGH / 0 MEDIUM. Verdict : exécution sans danger (sandbox sans réseau). Un scan propre ne prouve pas qu’un skill est sûr.

En résumé

Le skill améliore clairement une revue de performance et une optimisation sur place par rapport à ne rien faire, ce qui est son objectif. Un prompt court qui nomme les mêmes règles a fait mieux sur la tâche d’optimisation et coûté moins : la valeur réside donc surtout dans la connaissance des noms de règles ; les fichiers de règles du skill ont évité à l’utilisateur de les connaître, mais n’ont pas atteint les règles d’import barrel et de code-splitting dans ces exécutions.

Transcription

Journal d'exécution : vercel-react-best-practices (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.)
Colonnes : tâche, groupe-exécution, score (0-5), tokens, secondes, vérifications réussies, fichiers de la skill ouverts par l'agent.

t1-review control-1: score 4.27, tokens 65319, s 49.8, vérifications 2/2, rien ouvert
t1-review control-2: score 3.55, tokens 65797, s 42.7, vérifications 2/2, rien ouvert
t1-review oneliner-1: score 4.64, tokens 45347, s 43.5, vérifications 2/2, rien ouvert
t1-review oneliner-2: score 4.64, tokens 45242, s 52.5, vérifications 2/2, rien ouvert
t1-review treatment-1: score 4.64, tokens 75664, s 52.7, vérifications 2/2, ouvert react-best-practices
t1-review treatment-2: score 4.64, tokens 75106, s 52.1, vérifications 2/2, ouvert react-best-practices
t2-optimize control-1: score 2.27, tokens 81770, s 63.5, vérifications 5/10, rien ouvert
t2-optimize control-2: score 2.27, tokens 99616, s 48.7, vérifications 5/10, rien ouvert
t2-optimize oneliner-1: score 4.55, tokens 141803, s 75.2, vérifications 9/10, rien ouvert

18 exécutions, 3 artefacts

Exemple de sortie

SOTA · With the skill: final message (t1-review, run 1, Codex)

Ranked by likely impact; no files changed. 1. **`OrdersDashboard.tsx:16` — Storage access breaks server rendering and repeats on every render.** `localStorage` is unavailable during Next.js prerendering; `'use client'` doesn’t prevent that. Initialize settings with a stable default, then read and safely parse storage once after mounting. A lazy initializer alone won’t fix server access. [Next.js rendering guidance](https://nextjs.org/docs/app/getting-started/server-and-client-components) 2. **`page.tsx:8–11` — Independent server requests run sequentially.** After `getUser`, start settings, invoices, and notifications together using `Promise.all()`. Their latency currently adds up unnecessarily. 3. **`OrdersDashboard.tsx:19–28` — Initial data waits for hydration, then follows a request waterfall.** Fetch initial data in a server parent where practical. Otherwise, after fetching `me`, request orders and customers concurrently with `Promise.all()`. Neither depends on the other. 4. **`OrdersDashboard.tsx:45–47` — Every dashboard render remounts every row.** Defining `Row` inside the component creates a new component type each render, including during scrolling and typing. Move it to module scope; consider `React.memo` with stable props. 5. **`OrdersDashboard.tsx:17,34–38,55` — Scrolling rerenders the entire dashboard.** Each scroll update repeats filtering, sorting, joins, and rendering. Move scroll state into a small standalone indicator component; throttle updates if exact continuous tracking isn’t necessary. 6. **`OrdersDashboard.tsx:7,54` — The markdown preview is eagerly loaded even for an empty footer.** Use `next/dynamic` for the preview and render it only when footer content exists. Defer mounting until needed if it is below the fold. 7. **`OrdersDashboard.tsx:40–43` — Repeated expensive calculations and quadratic customer lookups.** Memoize derived results, build a customer-ID `Map` when customers change, and parse dates once before sorting instead of inside every comparison. The join then costs O(orders + customers), rather than O(orders × customers). 8. **`OrdersDashboard.tsx:15,30–32` — Derived state causes an extra render per search/data change.** Remove `filtered` state and its effect; derive it with `useMemo`. For large datasets, use `useDeferredValue(query)` with memoized results to keep typing responsive. 9. **`page.tsx:9–15` — All sections wait for the slowest request.** Start requests together, then await them inside separate async sections under `Suspense`. This allows the sidebar to appear without waiting for feed data; wrapping JSX after all awaits won’t help. 10. **`OrdersDashboard.tsx:53` — Every matching row is mounted.** For large order collections, paginate or virtualize the table. Prefer server pagination/filtering when fetching the entire collection also becomes expensive. 11. **`OrdersDashboard.tsx:3–6` — Import cleanup and a potential barrel-import cost.** Remove unused lodash, icons, `Modal`, and `isAfter`; import used local components directly rather than through `@/components`. Confirm bundle impact before claiming unused imports ship to clients. Named `date-fns` and `lucide-react` imports already rece [... excerpt: first 3200 of 3335 characters]

Voir Pro