vercel-react-best-practices (vercel-labs/agent-skills)
Aplica las guías de rendimiento de React y Next.js de Vercel a componentes, carga de datos y bundles.
Buenas prácticas de React de Vercel: eleva una optimización de Next.js de 2.3 a 3.6/5, pero la versión de una frase llega a 4.6 con el 75% de los tokens
Codex CLI · gpt-6-astra
24.3 / 30
Mejora frente a sin skill: +0.85 · Según el caso · 18 ejecuciones
Según el caso: la mejora +0.85 está por debajo de +1.0. Para ser recomendada hace falta un total de 22/30, una calidad de salida de 3.5 y una mejora de +1.0.
SOTA
AprobadaProbada con Codex.
Cubre Codex, Claude Code
Codex CLI 0.166 (nivel SOTA): 18 ejecuciones puntuadas. Una pasada aquí también cubre Claude Code según nuestra regla de niveles; no dice nada sobre el segundo nivel.
Puntuaciones
Cada dimensión va de 0 a 5 y las seis suman el total sobre 30. 5 es mejor en todas las dimensiones. Coste 5 significa barato y rápido. Instalación 5 significa fácil.
- Fiabilidad de activación
- 5.0
- Mejora frente a sin skill
- 2.9
- Calidad de salida
- 4.4
- Coste en tokens y tiempo
- 3.0
- Instalación y portabilidad
- 4.0
- Seguridad
- 5.0
Revisión de seguridad
SeguraEscaneo estático: 6 CRITICAL / 0 HIGH / 0 MEDIUM. Revisión manual: Segura para ejecutar en un sandbox sin red (hallazgos del escáner explicados). Un escaneo limpio no demuestra que una skill sea segura.
Instalar
npx skills@latest add vercel-labs/agent-skills --skill react-best-practices
Commit fijado: 1a2c79d4e6c4a2283dc2c614b6538cbe1ed5ca62
Probada: 2026-11-02
Qué probamos
- Revisión de rendimiento de un panel — Revisa OrdersDashboard.tsx y page.tsx (una app Next.js 15) en busca de problemas de rendimiento. Enuméralos del más grave al menos, cada uno con el archivo y qué cambiar. No cambies ningún archivo. Escribe la lista en tu respuesta final.
- Optimiza el componente del panel in situ — Optimiza el rendimiento de OrdersDashboard.tsx. Edita el archivo in situ, mantén el comportamiento y las props del componente iguales. (No hay red ni npm install; no intentes ejecutarlo.)
- Escribe una página de servidor de panel — Escribe app/dashboard/page.tsx, un componente de servidor de Next.js 15 (App Router). Para el usuario con sesión iniciada (getSession() de '@/lib/auth' devuelve { userId }), necesita getProfile(userId), getRecentOrders(userId) y getRecommendations(userId) de '@/lib/data'…
Ventajas
- Eleva la puntuación media de 3.57 a 4.43 frente a sin skill (+0.85).
- La skill se activó sin nombrarla: se leyó el archivo de la skill en 6/6 ejecuciones con skill.
Inconvenientes
- Un prompt de una frase obtuvo 4.73, frente a 4.43 con la skill (-0.30).
- Usa 1.53 veces los tokens de sin skill.
- n=2 por tarea y rama; las diferencias de menos de aproximadamente 1 punto son ruido.
Reseña
Codex CLI 0.166 (gpt-6-astra, razonamiento bajo) en una máquina de pruebas Mac, un proyecto temporal nuevo y HOME/TMPDIR/cachés temporales en cada ejecución, skill instalada (grupo con skill), ausente (control) o ausente con el requisito central de la skill comprimido en una frase añadida al prompt (grupo del prompt de una frase), 2 ejecuciones por grupo y tarea, red desactivada, escrituras en /tmp bloqueadas. Los prompts nunca mencionan la skill (salvo la redacción indicada abajo). Tres tareas sobre pequeños proyectos de ejemplo de Next.js 15: revisar el rendimiento de un componente y una página de panel (11 problemas plantados, enumerados del más grave al menos); optimizar el componente in situ (10 comprobaciones: Promise.all, importaciones directas en lugar de un barrel, sin importar lodash entero, next/dynamic para un editor pesado, Row elevado fuera del componente, lista derivada en lugar de setFiltered en un efecto, sin orders.length &&, inicializador de estado perezoso, búsqueda en Map, listener de scroll pasivo); escribir una página de servidor para una llamada de datos lenta y dos rápidas.
Comparación de tres ramas
| Rama | Puntuación media (0-5) | Tokens por ejecución |
|---|---|---|
| Sin la skill | 3.57 | 67k |
| Prompt de una frase | 4.73 | 77k |
| Con la skill | 4.43 | 103k |
Medido con Codex CLI en 18 ejecuciones, puntuado con comprobaciones basadas en reglas y sin juez LLM. Total 24.3 / 30, veredicto Según el caso.
Veredicto: Situacional (24.3 / 30). Fuente: vercel-labs/agent-skills, skills/react-best-practices, fijado en el commit 1a2c79d. Instalación: npx skills@latest add vercel-labs/agent-skills --skill react-best-practices. Licencia: MIT (LICENSE del repositorio).
Qué es
El skill vercel-react-best-practices de vercel-labs/agent-skills (directorio react-best-practices): 70 archivos de reglas en Markdown, agrupados por impacto (cascadas de peticiones, tamaño del bundle, rendimiento del servidor, obtención de datos en el cliente, re-renderizados, renderizado, rendimiento de JS, patrones avanzados), más un AGENTS.md compilado. SKILL.md es un índice; el agente carga las reglas que necesita. Sin scripts.
Cómo lo probamos
Codex CLI 0.166 (gpt-6-astra, razonamiento bajo) en un Mac de pruebas, un proyecto temporal nuevo y HOME/TMPDIR/cachés temporales en cada ejecución, skill instalado (grupo con skill), ausente (grupo de control) o ausente con el requisito central del skill comprimido en una frase añadida al prompt (grupo de una frase), 2 ejecuciones por grupo y tarea, red desactivada, escrituras en /tmp bloqueadas. Los prompts nunca mencionan el skill (salvo la formulación indicada abajo).
Tres tareas sobre pequeños fixtures de Next.js 15: revisar un componente de panel y una página en busca de rendimiento (11 problemas sembrados, ordenados de más grave a menos); optimizar el componente in situ (10 comprobaciones: Promise.all, importaciones directas en lugar de un barrel, no importar todo lodash, next/dynamic para un editor pesado, Row elevado fuera del componente, lista derivada en lugar de setFiltered en un efecto, no orders.length &&, inicializador de estado perezoso, búsqueda con Map, listener de scroll pasivo); escribir una página de servidor para una llamada de datos lenta y dos rápidas.
- Revisión de rendimiento de un panel — Revisa OrdersDashboard.tsx y page.tsx (una app de Next.js 15) en busca de problemas de rendimiento. Enuméralos de más grave a menos, cada uno con el archivo y qué cambiar. No cambies ningún archivo. Escribe la lista en tu respuesta final.
- Optimizar el componente del panel in situ — Optimiza OrdersDashboard.tsx para mejorar el rendimiento. Edita el archivo in situ, mantén el comportamiento y las props del componente iguales. (No hay red ni npm install; no intentes ejecutarlo.)
- Escribir una página de servidor del panel — Escribe app/dashboard/page.tsx, un componente de servidor de Next.js 15 (App Router). Para el usuario conectado (
getSession()de '@/lib/auth' devuelve{ userId }) necesitagetProfile(userId),getRecentOrders(userId)ygetRecommendations(userId)de '@/lib/data'…
La puntuación es programática (tests ocultos / detección de problemas sembrados / comprobaciones de restricciones / renderizado+OCR cuando corresponde), de 0 a 5 por ejecución. Ningún juez LLM decidió ninguna puntuación.
Resultados
La frase única que recibió el tercer grupo: "Corrige el rendimiento de React/Next.js en este orden: elimina las cascadas de peticiones (inicia las peticiones independientes juntas con Promise.all y transmite las partes lentas con Suspense), reduce el tamaño del bundle (importa directamente en lugar de a través de archivos barrel, divide en código los componentes pesados con next/dynamic), y luego evita re-renderizados innecesarios (deriva valores durante el renderizado, no definas componentes dentro de componentes, eleva los valores estáticos, usa inicializadores de estado perezosos, búsquedas con Map y listeners de scroll pasivos)."
| Tarea | Puntuación sin skill | Una frase | Con skill | Tokens sin skill | Tokens una frase | Tokens con skill | Skill leído |
|---|---|---|---|---|---|---|---|
| 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 |
Puntuación media: 3.57 sin vs 4.43 con el skill (delta +0.85). Tokens por ejecución: 67k vs 103k (1.53x); tiempo 47s vs 52s. Grupo de una frase: 4.73 (la mejora del skill frente a la frase: -0.3; la mejora de la frase frente a no usar skill: +1.15); la frase usa 77k tokens por ejecución, así que el skill consume 1.34 veces sus tokens.
Qué ocurrió
- Optimizar in situ es donde se nota: puntuación 2.27 control, 3.64 skill, 4.55 versión de una frase (ambas ejecuciones de cada grupo idénticas). Control y skill dejaron la importación barrel
from '@/components'y no aplicaron división de código; el control también dejó los awaits secuenciales y el listener de scroll no pasivo. El skill corrigió la cascada y el listener de scroll, pero no la importación barrel ni la importación dinámica del editor pesado; la frase, que nombra exactamente esas reglas, corrigió ambas. - Tarea de revisión: problemas sembrados encontrados 9, 7 en el control (8 de media) frente a 10, 10 tanto en el skill como en la frase (10 de 11 cada uno; el
orders.length &&que renderizaba un 0 lo pasaron por alto todas las ejecuciones de todos los grupos). Puntuación 3.91 control, 4.64 skill, 4.64 frase. - Tarea de escritura: todos los grupos pusieron las recomendaciones lentas detrás de Suspense y mantuvieron la página como componente de servidor; el control a veces esperó las tres llamadas en secuencia (puntuación 4.1 y 5.0, skill 5.0 en ambas, frase 5.0 en ambas).
- Ningún grupo corrigió
orders.length &&al editar el archivo, así que una regla que está en el skill (rendering-conditional-render) no llegó a ninguna edición. - El skill se leyó en 6/6 ejecuciones y costó 103k tokens frente a 67k (1.5x) y 77k de la frase (1.3x). Media global 3.57 control, 4.43 skill, 4.73 frase.
- La puntuación se corrigió una vez durante el análisis: la primera pasada marcó por error las comprobaciones de página y de Map como fallos porque el archivo se escribió en app/dashboard/page.tsx y el Map estaba tipado (
new Map<string, string>()); se corrigieron ambas regex y se volvieron a comprobar las 18 ejecuciones.
Puntuación por dimensiones
| Dimensión | Puntuación | Motivo |
|---|---|---|
| 1_output_quality | 4.43 | Puntuación media de 4.43/5 con el skill (comprobaciones programáticas; véase la tabla por tarea). |
| 2_lift_vs_no_skill | 2.85 | +0.85 puntos frente a 3.57 sin el skill (n=2 por tarea; menos de ~1 punto es ruido). |
| 3_trigger | 5.0 | Skill leído en 6/6 ejecuciones con skill. |
| 4_instructions_portability | 4 | Específico de React/Next.js; Markdown plano que otros agentes pueden cargar; sigue la estructura abierta de skills. |
| 5_efficiency | 3 | 1.53x tokens (103k vs 67k por ejecución) y 1.10x tiempo (52s vs 47s). |
| 6_safety_hygiene | 5 | Solo archivos de reglas en Markdown; 6 hallazgos del escáner son
|
Límites de esta prueba
- Fixtures pequeños con problemas de manual conocidos; solo se optimizó un componente, así que dos ejecuciones por grupo muestran el mismo resultado por la misma razón (dos ejecuciones idénticas).
- Las 70 reglas del skill solo se ejercitaron mediante tres tareas; no se sembraron la caché de servidor, SWR, los listeners de eventos ni las reglas avanzadas.
- La versión de una frase enumera las mismas reglas que comprueba el test, así que es un límite superior para un prompt corto, no un sustituto justo de un usuario que no conoce las reglas.
- n = 2 por grupo y tarea: las diferencias de menos de ~1 punto son ruido.
- La puntuación basada en reglas mide lo que las comprobaciones pueden ver; no puede juzgar el gusto ni si un resultado es el mejor posible.
Seguridad
Véase security.md. Escaneo: 6 CRITICAL / 0 HIGH / 0 MEDIUM. Veredicto: seguro de ejecutar (sandbox sin red). Un escaneo limpio no demuestra que un skill sea seguro.
Conclusión
El skill mejora claramente una revisión de rendimiento y una optimización in situ comparado con no hacer nada, que es su objetivo. Un prompt corto que nombra las mismas reglas lo hizo mejor en la tarea de optimización y costó menos, así que el valor está sobre todo en conocer los nombres de las reglas; los archivos de reglas del skill evitaron que un usuario tuviera que conocerlas, pero no llegaron a las reglas de importación barrel y división de código en estas ejecuciones.
Transcripción
Registro de ejecuciones: vercel-react-best-practices (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.) Columnas: tarea, grupo-ejecución, puntuación (0-5), tokens, segundos, comprobaciones superadas, archivos de la skill que abrió el agente. t1-review control-1: puntuación 4.27, tokens 65319, s 49.8, comprobaciones 2/2, no abrió nada t1-review control-2: puntuación 3.55, tokens 65797, s 42.7, comprobaciones 2/2, no abrió nada t1-review oneliner-1: puntuación 4.64, tokens 45347, s 43.5, comprobaciones 2/2, no abrió nada t1-review oneliner-2: puntuación 4.64, tokens 45242, s 52.5, comprobaciones 2/2, no abrió nada t1-review treatment-1: puntuación 4.64, tokens 75664, s 52.7, comprobaciones 2/2, abrió react-best-practices t1-review treatment-2: puntuación 4.64, tokens 75106, s 52.1, comprobaciones 2/2, abrió react-best-practices t2-optimize control-1: puntuación 2.27, tokens 81770, s 63.5, comprobaciones 5/10, no abrió nada t2-optimize control-2: puntuación 2.27, tokens 99616, s 48.7, comprobaciones 5/10, no abrió nada t2-optimize oneliner-1: puntuación 4.55, tokens 141803, s 75.2, comprobaciones 9/10, no abrió nada
18 ejecuciones, 3 artefactos
Resultado de ejemplo
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]