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

Wendet Vercels Performance-Richtlinien für React und Next.js auf Komponenten, Datenabruf und Bundles an.

Vercels React-Best-Practices: Hebt eine Next.js-Optimierung von 2.3 auf 3.6/5, aber die Ein-Satz-Version erreicht 4.6 bei 75 % der Tokens

SituativSicher

Codex CLI · gpt-6-astra

24.3 / 30

Lift gegenüber ohne Skill: +0.85 · Situativ · 18 Läufe

Situativ: der Lift +0.85 liegt unter +1.0. Für „Empfohlen“ sind insgesamt 22/30, eine Ausgabequalität von 3.5 und ein Lift von +1.0 nötig.

SOTA

Bestanden

Getestet mit Codex.

Gilt für Codex, Claude Code

Codex CLI 0.166 (SOTA-Stufe): 18 bewertete Läufe. Ein Bestehen hier deckt gemäß unserer Stufenregel auch Claude Code ab; über die zweite Stufe sagt es nichts aus.

Punktzahlen

Jede Dimension reicht von 0 bis 5, und die sechs ergeben zusammen die Gesamtpunktzahl von 30. 5 ist in jeder Dimension besser. Kosten 5 bedeutet günstig und schnell. Installation 5 bedeutet einfach.

Trigger-Zuverlässigkeit: 5.0
Lift gegenüber ohne Skill: 2.9
Ausgabequalität: 4.4
Token- und Zeitkosten: 3.0
Installation und Portabilität: 4.0
Sicherheit: 5.0

Sicherheitsprüfung

Sicher

Statischer Scan: 6 CRITICAL / 0 HIGH / 0 MEDIUM. Manuelle Prüfung: Sicher in einer Sandbox ohne Netzwerk auszuführen (Scanner-Befunde erklärt). Ein sauberer Scan beweist nicht, dass ein Skill sicher ist.

Installieren

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

Quelle

Fixierter Commit: 1a2c79d4e6c4a2283dc2c614b6538cbe1ed5ca62

Getestet: 2026-11-02

Was wir getestet haben

Performance-Review eines Dashboards — OrdersDashboard.tsx und page.tsx (eine Next.js-15-App) auf Performance-Probleme prüfen. Schwerwiegendstes zuerst auflisten, jeweils mit Datei und Änderung. Keine Dateien ändern. Die Liste in der letzten Antwort ausgeben.
Die Dashboard-Komponente direkt optimieren — OrdersDashboard.tsx auf Performance optimieren. Die Datei direkt bearbeiten, Verhalten und Props der Komponente gleich halten. (Kein Netzwerk und kein npm install; nicht versuchen, es auszuführen.)
Eine Dashboard-Server-Seite schreiben — app/dashboard/page.tsx schreiben, eine Next.js-15-Serverkomponente (App Router). Für den angemeldeten Benutzer (getSession() aus '@/lib/auth' liefert { userId }) werden getProfile(userId), getRecentOrders(userId) und getRecommendations(userId) aus '@/lib/data' benötigt…

Vorteile

Hebt den Mittelwert von 3.57 auf 4.43 gegenüber ohne Skill (+0.85).
Der Skill wurde erkannt, ohne genannt zu werden: Skill-Datei in 6/6 Treatment-Läufen gelesen.

Nachteile

Ein Ein-Satz-Prompt erzielte 4.73 gegenüber 4.43 mit dem Skill (-0.30).
Verbraucht 1.53x die Tokens von ohne Skill.
n=2 pro Aufgabe und Variante; Unterschiede unter etwa 1 Punkt sind Rauschen.

Bewertung

Codex CLI 0.166 (gpt-6-astra, niedriges Reasoning) auf einem Mac-Testrechner, einem frischen temporären Projekt und temporären HOME/TMPDIR/Caches pro Lauf; Skill installiert (Treatment) oder nicht vorhanden (Kontrolle) oder nicht vorhanden mit der Kernanforderung des Skills in einem an den Prompt angehängten Satz (One-Liner-Gruppe); 2 Läufe pro Gruppe und Aufgabe; Netzwerk aus; Schreiben nach /tmp blockiert. Die Prompts nennen den Skill nie (außer der unten genannten Formulierung). Drei Aufgaben an kleinen Next.js-15-Fixtures: eine Dashboard-Komponente und -Seite auf Performance prüfen (11 eingebaute Probleme, schwerwiegendstes zuerst); die Komponente direkt optimieren (10 Prüfungen: Promise.all, direkte Importe statt Barrel, kein Ganz-Lodash-Import, next/dynamic für einen schweren Editor, Row aus der Komponente gehoben, abgeleitete Liste statt setFiltered in einem Effect, kein orders.length &&, Lazy-State-Initialisierer, Map-Lookup, passiver Scroll-Listener); eine Server-Seite für einen langsamen und zwei schnelle Datenaufrufe schreiben.

Drei-Arm-Vergleich

Variante	Durchschnittsnote (0-5)	Tokens pro Lauf
Ohne Skill	3.57	67k
Ein-Satz-Prompt	4.73	77k
Mit Skill	4.43	103k

Gemessen mit Codex CLI über 18 Läufe, bewertet durch regelbasierte Prüfungen ohne LLM-Richter. Gesamt 24.3 / 30, Urteil Situativ.

Urteil: Situativ (24.3 / 30). Quelle: vercel-labs/agent-skills, skills/react-best-practices, gepinnt auf Commit 1a2c79d. Installation: npx skills@latest add vercel-labs/agent-skills --skill react-best-practices. Lizenz: MIT (Repo-LICENSE).

Worum es geht

Der Skill vercel-react-best-practices aus vercel-labs/agent-skills (Verzeichnis react-best-practices): 70 Markdown-Regeldateien, nach Wirkung gruppiert (Request-Wasserfälle, Bundle-Größe, serverseitige Performance, Client-Datenabruf, Re-Renders, Rendering, JS-Performance, fortgeschrittene Muster), plus eine kompilierte AGENTS.md. SKILL.md ist ein Index; der Agent lädt die Regeln, die er braucht. Keine Skripte.

So haben wir getestet

Codex CLI 0.166 (gpt-6-astra, niedriges Reasoning) auf einem Mac-Testgerät, pro Lauf ein frisches temporäres Projekt und temporäre HOME/TMPDIR/Caches, Skill installiert (Skill-Gruppe), nicht vorhanden (Kontrollgruppe) oder nicht vorhanden, aber mit der Kernanforderung des Skills als einem an den Prompt angehängten Satz (Ein-Satz-Gruppe), 2 Läufe pro Gruppe und Aufgabe, Netzwerk aus, Schreibzugriffe auf /tmp blockiert. Die Prompts nennen den Skill nie (außer der unten genannten Formulierung).

Drei Aufgaben mit kleinen Next.js-15-Fixtures: eine Dashboard-Komponente und eine Seite auf Performance prüfen (11 eingebaute Probleme, das schwerwiegendste zuerst); die Komponente an Ort und Stelle optimieren (10 Prüfungen: Promise.all, direkte Importe statt eines Barrel, kein Import des ganzen lodash, next/dynamic für einen schweren Editor, Row aus der Komponente herausgehoben, abgeleitete Liste statt setFiltered in einem Effekt, kein orders.length &&, Lazy-State-Initialisierer, Map-Lookup, passiver Scroll-Listener); eine Serverseite für einen langsamen und zwei schnelle Datenabrufe schreiben.

Performance-Review eines Dashboards — Prüfe OrdersDashboard.tsx und page.tsx (eine Next.js-15-App) auf Performance-Probleme. Liste sie mit dem schwerwiegendsten zuerst auf, jeweils mit Datei und der nötigen Änderung. Ändere keine Dateien. Schreibe die Liste in deine letzte Antwort.
Die Dashboard-Komponente an Ort und Stelle optimieren — Optimiere OrdersDashboard.tsx für Performance. Bearbeite die Datei direkt und behalte das Verhalten und die Props der Komponente bei. (Es gibt kein Netzwerk und kein npm install; versuche nicht, sie auszuführen.)
Eine Dashboard-Serverseite schreiben — Schreibe app/dashboard/page.tsx, eine Next.js-15-Serverkomponente (App Router). Für den angemeldeten Nutzer (getSession() aus '@/lib/auth' liefert { userId }) benötigt sie getProfile(userId), getRecentOrders(userId) und getRecommendations(userId) aus @/lib/data …

Die Bewertung ist programmatisch (versteckte Tests / Erkennung eingebauter Probleme / Constraint-Checks / Rendern+OCR, wo relevant), 0–5 pro Lauf. Kein LLM-Richter hat einen Score vergeben.

Ergebnisse

Der Ein-Satz-Prompt für die dritte Gruppe: „Behebe React-/Next.js-Performance in dieser Reihenfolge: Beseitige Request-Wasserfälle (starte unabhängige Abrufe gemeinsam mit Promise.all und streame langsame Teile mit Suspense), reduziere die Bundle-Größe (importiere direkt statt über Barrel-Dateien, teile schwere Komponenten mit next/dynamic auf) und vermeide dann unnötige Re-Renders (leite Werte während des Renderns ab, definiere keine Komponenten in Komponenten, hebe statische Werte heraus, nutze Lazy-State-Initialisierer, Map-Lookups und passive Scroll-Listener).“

Aufgabe	Score Kontrolle	Ein-Satz	Mit Skill	Tokens Kontrolle	Tokens Ein-Satz	Tokens mit Skill	Skill gelesen
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

Durchschnittsscore: 3.57 ohne vs. 4.43 mit dem Skill (Delta +0.85). Tokens pro Lauf: 67k vs. 103k (1.53x); Zeit 47s vs. 52s. Ein-Satz-Gruppe: 4.73 (Gewinn des Skills gegenüber der Ein-Satz-Version: -0.3; Gewinn der Ein-Satz-Version gegenüber ohne Skill: +1.15); Ein-Satz-Version 77k Tokens pro Lauf, der Skill kostet also 1.34x so viel wie die Ein-Satz-Version.

Was passiert ist

Die Optimierung an Ort und Stelle ist der Punkt, an dem es sich zeigt: Score 2.27 Kontrolle, 3.64 Skill, 4.55 Ein-Satz-Version (beide Läufe jeder Gruppe identisch). Kontrolle und Skill ließen beide den Barrel-Import from '@/components' stehen und verzichteten auf Code-Splitting; die Kontrolle ließ außerdem die sequenziellen Awaits und den nicht-passiven Scroll-Listener stehen. Der Skill behob den Wasserfall und den Scroll-Listener, aber nicht den Barrel-Import oder den dynamischen Import des schweren Editors; die Ein-Satz-Version, die genau diese Regeln nennt, behob beides.
Review-Aufgabe: Gefundene eingebaute Probleme: 9 und 7 bei der Kontrolle (im Schnitt 8) gegenüber 10 und 10 bei Skill und Ein-Satz-Version (je 10 von 11; das orders.length &&, das eine 0 rendert, wurde in jedem Lauf jeder Gruppe übersehen). Score 3.91 Kontrolle, 4.64 Skill, 4.64 Ein-Satz.
Schreibaufgabe: Alle Gruppen legten die langsamen Empfehlungen hinter Suspense und behielten die Seite als Server Component; die Kontrolle wartete manchmal alle drei Aufrufe sequenziell ab (Score 4.1 und 5.0, Skill beide 5.0, Ein-Satz beide 5.0).
Keine Gruppe behob orders.length && beim Bearbeiten der Datei, sodass eine Regel, die im Skill steht (rendering-conditional-render), in keine Bearbeitung gelangte.
Der Skill wurde in 6/6 Läufen gelesen und kostete 103k Tokens gegenüber 67k (1.5x) und 77k für die Ein-Satz-Version (1.3x). Gesamtmittel 3.57 Kontrolle, 4.43 Skill, 4.73 Ein-Satz.
Die Bewertung wurde während der Analyse einmal korrigiert: Der erste Durchgang markierte die Seiten- und Map-Prüfungen fälschlich als verfehlt, weil die Datei nach app/dashboard/page.tsx geschrieben wurde und die Map typisiert war (new Map<string, string>()); beide Regexes wurden korrigiert und alle 18 Läufe erneut geprüft.

Dimensionsbewertungen

Dimension	Score	Begründung
1_output_quality	4.43	Durchschnittsscore 4.43/5 mit dem Skill (programmatische Prüfungen, siehe Tabelle pro Aufgabe).
2_lift_vs_no_skill	2.85	+0.85 Punkte gegenüber 3.57 ohne den Skill (n=2 pro Aufgabe; unter etwa 1 Punkt ist Rauschen).
3_trigger	5.0	Skill-Datei in 6/6 Skill-Läufen gelesen.
4_instructions_portability	4	React-/Next.js-spezifisch; reines Markdown, das andere Agenten laden können; folgt dem offenen Skills-Layout.
5_efficiency	3	1.53x Tokens (103k vs. 67k pro Lauf) und 1.10x Zeit (52s vs. 47s).
6_safety_hygiene	5	Nur Markdown-Regeldateien; 6 Scanner-Treffer sind `document.cookie` in Codebeispielen, im Kontext gelesen.

Grenzen dieses Tests

Kleine Fixtures mit bekannten Lehrbuchproblemen; nur eine Komponente wurde optimiert, daher zeigen zwei Läufe pro Gruppe dasselbe Ergebnis aus demselben Grund (zwei Läufe identisch).
Die 70 Regeln des Skills wurden nur über drei Aufgaben geübt; Server-Caching, SWR, Event-Listener und fortgeschrittene Regeln wurden nicht eingebaut.
Die Ein-Satz-Version listet dieselben Regeln, die der Test prüft, sie ist also eine Obergrenze für einen kurzen Prompt, kein fairer Ersatz für einen Nutzer, der die Regeln nicht kennt.
n = 2 pro Gruppe und Aufgabe: Unterschiede unter etwa 1 Punkt sind Rauschen.
Regelbasierte Bewertung misst, was die Prüfungen sehen können; sie kann keinen Geschmack beurteilen oder ob ein Ergebnis das bestmögliche ist.

Sicherheit

Siehe security.md. Scan: 6 CRITICAL / 0 HIGH / 0 MEDIUM. Urteil: sicher ausführbar (Sandbox ohne Netzwerk). Ein sauberer Scan beweist nicht, dass ein Skill sicher ist.

Fazit

Der Skill verbessert ein Performance-Review und eine Optimierung an Ort und Stelle deutlich gegenüber dem Nichtstun, und darum geht es. Ein kurzer Prompt, der dieselben Regeln nennt, schnitt bei der Optimierungsaufgabe besser ab und kostete weniger, der Wert liegt also vor allem im Kennen der Regelnamen; die Regeldateien des Skills ersparten dem Nutzer, sie zu kennen, erreichten aber in diesen Läufen nicht die Regeln zu Barrel-Import und Code-Splitting.

Transkript

Laufprotokoll: vercel-react-best-practices (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.)
Spalten: Aufgabe, Gruppe-Lauf, Punktzahl (0-5), Tokens, Sekunden, bestandene Prüfungen, vom Agenten geöffnete Skill-Dateien.

t1-review control-1: Punkte 4.27, Tokens 65319, Sek. 49.8, Prüfungen 2/2, nichts geöffnet
t1-review control-2: Punkte 3.55, Tokens 65797, Sek. 42.7, Prüfungen 2/2, nichts geöffnet
t1-review oneliner-1: Punkte 4.64, Tokens 45347, Sek. 43.5, Prüfungen 2/2, nichts geöffnet
t1-review oneliner-2: Punkte 4.64, Tokens 45242, Sek. 52.5, Prüfungen 2/2, nichts geöffnet
t1-review treatment-1: Punkte 4.64, Tokens 75664, Sek. 52.7, Prüfungen 2/2, geöffnet react-best-practices
t1-review treatment-2: Punkte 4.64, Tokens 75106, Sek. 52.1, Prüfungen 2/2, geöffnet react-best-practices
t2-optimize control-1: Punkte 2.27, Tokens 81770, Sek. 63.5, Prüfungen 5/10, nichts geöffnet
t2-optimize control-2: Punkte 2.27, Tokens 99616, Sek. 48.7, Prüfungen 5/10, nichts geöffnet
t2-optimize oneliner-1: Punkte 4.55, Tokens 141803, Sek. 75.2, Prüfungen 9/10, nichts geöffnet

18 Läufe, 3 Artefakte

Beispielausgabe

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]

Pro ansehen