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

レビュー

Mac テストマシン上で Codex CLI 0.166（gpt-6-astra、低推論）、実行ごとに新規の一時プロジェクトと一時 HOME/TMPDIR/キャッシュを使用、スキルをインストール（スキルあり群）、スキルなし（対照群）、またはスキルの中核要件をプロンプト末尾に付けた一文に圧縮（一文プロンプト群）、タスクごとに各群 2 実行、ネットワーク無効、/tmp への書き込みはブロック。プロンプトはスキル名に一切言及しません（以下で注記する表現を除く）。小規模な Next.js 15 フィクスチャに対する 3 つのタスク：ダッシュボードのコンポーネントとページのパフォーマンスレビュー（仕込まれた問題点 11 件、最も深刻なものから列挙）、コンポーネントをその場で最適化（チェック 10 項目：Promise.all、バレルではなく直接インポート、lodash 全体のインポートなし、重いエディタには next/dynamic、Row をコンポーネント外へホイスト、effect 内の setFiltered ではなく派生リスト、orders.length && を使わない、遅延 state 初期化子、Map ルックアップ、パッシブスクロールリスナー）、低速 1 件と高速 2 件のデータ呼び出しに対応するサーバーページの作成。

3群の比較

Codex CLI で 18 実行を計測し、LLM 判定なしのルールベースのチェックで採点。合計 24.3 / 30、判定は 状況次第。

判定：状況次第（24.3 / 30）。 出典：vercel-labs/agent-skills、skills/react-best-practices、コミット 1a2c79d に固定。インストール：npx skills@latest add vercel-labs/agent-skills --skill react-best-practices。ライセンス： MIT（リポジトリの LICENSE）。

概要

vercel-labs/agent-skills の vercel-react-best-practices スキル（ディレクトリは react-best-practices）：影響度でグループ化された 70 の Markdown ルールファイル（リクエストウォーターフォール、バンドルサイズ、サーバーサイド性能、クライアントのデータ取得、再レンダリング、レンダリング、JS 性能、高度なパターン）と、コンパイル済みの AGENTS.md。SKILL.md はインデックスで、エージェントは必要なルールを読み込みます。スクリプトなし。

テスト方法

Mac テストマシン上で Codex CLI 0.166（gpt-6-astra、低推論）、実行ごとに新規の一時プロジェクトと一時 HOME/TMPDIR/キャッシュを使用、スキルをインストール（スキルあり群）、スキルなし（対照群）、またはスキルの中核要件をプロンプト末尾に付けた一文に圧縮（一文プロンプト群）、タスクごとに各群 2 実行、ネットワーク無効、/tmp への書き込みはブロック。プロンプトはスキル名に一切言及しません（以下で注記する表現を除く）。

小さな Next.js 15 フィクスチャでの 3 タスク：ダッシュボードコンポーネントとページのパフォーマンスレビュー（11 の仕込み問題、重大な順に列挙）。コンポーネントのその場での最適化（10 チェック：Promise.all、バレルではなく直接インポート、lodash 全体のインポートをしない、重いエディターに next/dynamic、Row をコンポーネント外へホイスト、effect 内の setFiltered ではなく派生リスト、orders.length && を使わない、遅延状態初期化子、Map ルックアップ、パッシブスクロールリスナー）。遅いデータ呼び出し 1 つと速い 2 つのためのサーバーページの作成。

1. ダッシュボードのパフォーマンスレビュー — OrdersDashboard.tsx と page.tsx（Next.js 15 アプリ）のパフォーマンス問題をレビュー。重大な順に、それぞれファイルと変更内容を添えて列挙。ファイルは変更しないでください。リストは最終回答に書いてください。
2. ダッシュボードコンポーネントをその場で最適化 — OrdersDashboard.tsx をパフォーマンスのために最適化。ファイルをその場で編集し、振る舞いとコンポーネントの props は同じに保つ。（ネットワークも npm install もありません。実行は試みないでください。）
3. ダッシュボードのサーバーページを書く — app/dashboard/page.tsx、Next.js 15 のサーバーコンポーネント（App Router）を書く。ログイン中のユーザー（'@/lib/auth' の getSession() が { userId } を返す）には、'@/lib/data' の getProfile(userId)、getRecentOrders(userId)、getRecommendations(userId) が必要で…

採点はプログラム的（隠しテスト／仕込み問題の検出／制約チェック／該当する場合はレンダリング+OCR）で、実行ごとに 0〜5 点。スコアはどの LLM 判定者も決めていません。

結果

第 3 群に与えた一文プロンプト："この順序で React/Next.js のパフォーマンスを修正する：リクエストウォーターフォールを排除し（独立したフェッチを Promise.all で同時に開始し、遅い部分は Suspense でストリーミング）、バンドルサイズを削減し（バレルファイル経由ではなく直接インポート、重いコンポーネントを next/dynamic でコード分割）、不要な再レンダリングを避ける（レンダリング中に値を導出、コンポーネント内でコンポーネントを定義しない、静的値をホイスト、遅延状態初期化子・Map ルックアップ・パッシブスクロールリスナーを使う）。"

平均スコア：スキルなし 3.57 vs スキルあり 4.43（差分 +0.85）。1 実行あたりのトークン：67k vs 103k（1.53 倍）。時間：47s vs 52s。一文プロンプト群：4.73（一文プロンプトに対するスキルの上乗せ：-0.3。一文プロンプト自身のスキルなしに対する上乗せ：+1.15）。一文プロンプトのトークンは 1 実行あたり 77k、つまりスキルのコストは一文プロンプトの 1.34 倍。

何が起きたか

• その場での最適化で差が現れました：対照群 2.27、スキルあり 3.64、一文版 4.55（各群の 2 実行は同一）。対照群とスキルはともにバレルインポート from '@/components' を残し、コード分割も行いませんでした。対照群はさらに、逐次 await と非パッシブのスクロールリスナーも残しました。スキルはウォーターフォールとスクロールリスナーは修正しましたが、バレルインポートと重いエディターの動的インポートは修正せず、まさにそのルールを名指しする一文プロンプトは両方を修正しました。
• レビュータスク：検出した仕込み問題は対照群 9、7（平均 8）、スキルと一文プロンプトはともに 10、10（それぞれ 11 のうち 10。0 を描画する orders.length && はどの群のどの実行も見落とし）。スコアは対照群 3.91、スキルあり 4.64、一文プロンプト 4.64。
• 作成タスク：全群が遅いレコメンデーションを Suspense の後ろに置き、ページをサーバーコンポーネントのままにしました。対照群はときどき 3 つの呼び出しを順番に await しました（スコア 4.1 と 5.0。スキルは両方 5.0、一文プロンプトも両方 5.0）。
• ファイル編集時に orders.length && を修正した群はなく、スキルにあるルール（rendering-conditional-render）はどの編集にも反映されませんでした。
• スキルは 6/6 実行で読み込まれ、103k トークン（対照群 67k、1.5 倍。一文プロンプト 77k、1.3 倍）。全体平均は対照群 3.57、スキルあり 4.43、一文プロンプト 4.73。
• 分析中に採点を 1 度修正しました：最初のパスでは、ファイルが app/dashboard/page.tsx に書かれ、Map が型付けされていた（new Map<string, string>()）ため、ページと Map のチェックを誤って失点と判定していました。両方の正規表現を修正し、18 実行すべてを再チェックしました。

評価項目別スコア

このテストの限界

• 既知の教科書的な問題を持つ小さなフィクスチャ。最適化したコンポーネントは 1 つだけなので、群ごとの 2 実行は同じ理由で同じ結果を示します（2 実行は同一）。
• スキルの 70 ルールは 3 タスクでしか試されていません。サーバーキャッシュ、SWR、イベントリスナー、高度なルールは仕込んでいません。
• 一文版はテストがチェックするのと同じルールを列挙するため、短いプロンプトの上限であり、ルールを知らないユーザーの公平な代替ではありません。
• タスク・群ごとに n=2。約 1 ポイント未満の差はノイズです。
• ルールベースの採点はチェックが捉えられる範囲を測るもので、センスや、その結果が最善かどうかは判定できません。

セキュリティ

security.md を参照。スキャン：CRITICAL 6 / HIGH 0 / MEDIUM 0。判定：実行しても安全（ネットワーク無効のサンドボックス）。クリーンなスキャン結果はスキルの安全性を証明しません。

結論

このスキルは、何もしない場合に比べてパフォーマンスレビューとその場での最適化を明確に改善します。それが目的です。同じルールを名指しする短いプロンプトは最適化タスクでより良く、コストも低かったため、価値の大半はルール名を知っていることにあります。スキルのルールファイルは、ユーザーがルール名を知らなくて済むようにしますが、今回の実行ではバレルインポートとコード分割のルールには届きませんでした。