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

Review

Codex CLI 0.166 (gpt-6-astra, low reasoning) on a Mac test machine, a fresh temporary project and temporary HOME/TMPDIR/caches per run, skill installed (treatment) or absent (control) or absent with the skill's core requirement squeezed into one sentence appended to the prompt (one-liner group), 2 runs per group per task, network off, /tmp writes blocked. The prompts never mention the skill (except the wording noted below). Three tasks on small Next.js 15 fixtures: review a dashboard component and page for performance (11 planted problems, listed most serious first); optimise the component in place (10 checks: Promise.all, direct imports instead of a barrel, no whole-lodash import, next/dynamic for a heavy editor, Row hoisted out of the component, derived list instead of setFiltered in an effect, no orders.length &&, lazy state initialiser, Map lookup, passive scroll listener); write a server page for a slow and two fast data calls.

Three-arm comparison

Measured with Codex CLI over 18 runs, scored by rule-based checks with no LLM judge. Total 24.3 / 30, verdict Situational.

Verdict: Situational (24.3 / 30). Source: vercel-labs/agent-skills, skills/react-best-practices, pinned at commit 1a2c79d. Install: npx skills@latest add vercel-labs/agent-skills --skill react-best-practices. Licence: MIT (repo LICENSE).

What it is

The vercel-react-best-practices skill from vercel-labs/agent-skills (directory react-best-practices): 70 Markdown rule files, grouped by impact (request waterfalls, bundle size, server-side performance, client data fetching, re-renders, rendering, JS performance, advanced patterns), plus a compiled AGENTS.md. SKILL.md is an index; the agent loads the rules it needs. No scripts.

How we tested

Codex CLI 0.166 (gpt-6-astra, low reasoning) on a Mac test machine, a fresh temporary project and temporary HOME/TMPDIR/caches per run, skill installed (treatment) or absent (control) or absent with the skill's core requirement squeezed into one sentence appended to the prompt (one-liner group), 2 runs per group per task, network off, /tmp writes blocked. The prompts never mention the skill (except the wording noted below).

Three tasks on small Next.js 15 fixtures: review a dashboard component and page for performance (11 planted problems, listed most serious first); optimise the component in place (10 checks: Promise.all, direct imports instead of a barrel, no whole-lodash import, next/dynamic for a heavy editor, Row hoisted out of the component, derived list instead of setFiltered in an effect, no orders.length &&, lazy state initialiser, Map lookup, passive scroll listener); write a server page for a slow and two fast data calls.

1. Performance review of a dashboard — Review OrdersDashboard.tsx and page.tsx (a Next.js 15 app) for performance problems. List them most serious first, each with the file and what to change. Do not change any files. Write the list in your final answer.
2. Optimise the dashboard component in place — Optimise OrdersDashboard.tsx for performance. Edit the file in place, keep the behaviour and the component's props the same. (There is no network and no npm install; do not try to run it.)
3. Write a dashboard server page — Write app/dashboard/page.tsx, a Next.js 15 server component (App Router). For the logged-in user (getSession() from '@/lib/auth' returns { userId }) it needs getProfile(userId), getRecentOrders(userId) and getRecommendations(userId) from '@/lib/data'…

Scoring is programmatic (hidden tests / planted-issue recall / constraint checks / render+OCR where relevant), 0–5 per run. No LLM judge decided any score.

Results

The one-liner given to the third group: "Fix React/Next.js performance in this order: remove request waterfalls (start independent fetches together with Promise.all and stream slow parts with Suspense), cut bundle size (import directly instead of through barrel files, code-split heavy components with next/dynamic), then avoid needless re-renders (derive values during render, do not define components inside components, hoist static values, use lazy state initialisers, Map lookups, passive scroll listeners)."

Mean score: 3.57 without vs 4.43 with the skill (delta +0.85). Tokens per run: 67k vs 103k (1.53x); time 47s vs 52s. One-liner group: 4.73 (the skill's gain over the one-liner: -0.3; one-liner's own gain over no skill: +1.15); one-liner tokens 77k per run, so the skill costs 1.34x the one-liner.

What happened

• Optimising in place is where it shows: score 2.27 control, 3.64 skill, 4.55 one-sentence version (both runs of each group identical). Control and skill both left the barrel import from '@/components' and kept no code-splitting; control also left the sequential awaits and the non-passive scroll listener. The skill fixed the waterfall and the scroll listener but not the barrel import or the dynamic import of the heavy editor; the one-liner, which names exactly those rules, fixed both.
• Review task: planted problems found 9, 7 for control (8 average) against 10, 10 for both the skill and the one-liner (10 of 11 each; the orders.length && rendering a 0 was missed by every run in every group). Score 3.91 control, 4.64 skill, 4.64 one-liner.
• Write task: all groups put the slow recommendations behind Suspense and kept the page a server component; control sometimes awaited all three calls in sequence (score 4.1 and 5.0, skill 5.0 both, one-liner 5.0 both).
• No group fixed orders.length && when editing the file, so a rule that is in the skill (rendering-conditional-render) did not make it into any edit.
• The skill was read in 6/6 runs and cost 103k tokens against 67k (1.5x) and 77k for the one-liner (1.3x). Overall mean 3.57 control, 4.43 skill, 4.73 one-liner.
• The scoring was corrected once during analysis: the first pass wrongly marked the page and Map checks as misses because the file was written to app/dashboard/page.tsx and the Map was typed (new Map<string, string>()); both regexes were fixed and all 18 runs re-checked.

Dimension scores

Limits of this test

• Small fixtures with known textbook problems; only one component was optimised, so two runs per group show the same result for the same reason (two runs identical).
• The skill's 70 rules were exercised only through three tasks; server caching, SWR, event-listener and advanced rules were not planted.
• The one-sentence version lists the same rules the test checks, so it is an upper bound for a short prompt, not a fair stand-in for a user who does not know the rules.
• n = 2 per group per task: differences under about 1 point are noise.
• Rule-based scoring measures what the checks can see; it cannot judge taste or whether a result is the best possible.

Security

See security.md. Scan: 6 CRITICAL / 0 HIGH / 0 MEDIUM. Verdict: safe to run (no-network sandbox). A clean scan does not prove a skill safe.

Bottom line

The skill clearly improves a performance review and an in-place optimisation compared with doing nothing, which is the point of it. A short prompt that names the same rules did better on the optimise task and cost less, so the value is mostly in knowing the rule names; the skill's rule files saved a user from having to know them but did not reach the barrel-import and code-splitting rules in these runs.