页面慢时，到处加 useMemo 很容易产生大量改动，却没有减少用户真正等待的那段时间。这个 Skill 把检查顺序放在前面：先看异步等待是否串行、首屏是否加载过多 JavaScript，再看服务端工作和组件更新。
安装与首次使用
在项目根目录、已具备 Node.js 与 npm 的终端运行以下命令，给 Claude Code 安装这一项技能。使用 Codex 时，把 --agent claude-code 换成 --agent codex。这是项目级安装；安装完成后刷新或重开 Agent 会话，并在任务里明确写出技能名。
npx skills@latest add vercel-labs/agent-skills --skill vercel-react-best-practices --agent claude-code
让一次审查回答一个性能问题
以下是可按项目调整的首次输入：
使用 vercel-react-best-practices 检查 app/dashboard 与相关数据读取。目标是减少首次打开的等待。先画出请求依赖，找出可以并发的独立操作及首屏不需要的依赖，给出前三项修改和验证方法，确认后只实现第一项。保留权限检查和错误状态。
给出具体路由、慢操作和可以重复的访问方式。能够提供浏览器性能记录、包体分析或请求时间线时，一并交给 Agent；没有测量数据时，先得到候选问题与测量方案，而不是直接接受“更快了”的结论。登录用户与匿名用户的数据边界也应写进范围。
先理清依赖，再改异步代码
官方并发规则针对彼此独立的操作。例如用户资料和不依赖它的公告可以同时读取，但需要用户 ID 或权限判断的查询不能机械地一起启动。让 Agent 说明每个等待为何可以提前、是否改变错误传播，以及失败时页面会显示什么。
第二类值得检查的是首屏包体：大型图表、编辑器和第三方脚本是否都在进入页面时加载，服务端可以完成的工作是否跨到了客户端。动态加载会改变加载状态，拆边界会影响传递的数据；修性能时仍要保留占位、失败处理和必要的交互。
用同一场景比较改动前后
第一次交付可以只是一处消除串行等待的修改，以及对应测试、时间线和影响说明。再次使用同样的数据量、登录状态和网络条件检查，区分开发模式额外开销与实际发布构建。已有基线异常应单独记录，避免把偶然波动写成优化成果。
缓存同样需要边界：请求内去重和跨请求共享不是一回事，包含用户身份的数据不能因“减少重复”被错误共享。该技能提供审查顺序与写法建议，不会替代性能剖析。若当前瓶颈在数据库或外部服务，前端改几个渲染 Hook 通常不能回答原来的问题。
区分三种不同的“慢”
首屏白屏、点击后等待和输入时卡顿往往不是同一个问题。首屏先看网络瀑布与 JavaScript 包体：是否串行请求、是否把只在打开弹窗时才用的编辑器放进首包。点击慢要看该交互触发的请求与状态更新。输入卡顿才更可能进入组件重渲染分析。让 Agent 先指出它要解决哪段等待，以及能复现的路径。
消除瀑布前画出依赖图：查询 A 需要登录用户 ID，就必须等身份结果；公告 B 与身份无关，才可能提前并发。改变并发时还要说明部分失败后的界面状态。拆包也有代价：延迟加载编辑器后首次打开弹窗可能变慢，加载占位和预取策略要一起设计。不要把“请求数减少”直接等同于用户体验改善。
另一个场景：首屏加载了不需要的图表
产品详情页如果只有点击“查看趋势”才显示图表，可要求：“检查图表库是否进入产品详情首包；保持数据权限和弹窗加载状态，提出把图表相关代码推迟到展开时加载的最小改动，并说明首次展开会增加什么等待。” 这对应官方的包体和动态加载规则，但不是说拆包一定更快。验收时至少比较首屏包体或下载时间、首次打开图表的等待、慢网络占位与失败提示；如果用户多数会立刻打开图表，还应考虑预取，不能只凭首包变小判断体验。
把规则用于一次具体审查
在组件库或页面项目里，可以把它放进代码审查流程，而不是只在性能变差时调用。一个 shadcn registry 作者会用它提醒 Agent 避免把可直接计算的值再写进 useEffect，并检查能否并行的数据请求。每次只挑当前页面确实存在的一类问题，先记录加载或渲染现状，再改动并复测；“符合规则”本身不能证明用户可感知的速度提升。
安装后为什么没触发
安装好却没有触发时，检查目录 react-best-practices 与文件声明的 vercel-react-best-practices 是否被当前 Agent 当成同一个 Skill。一个用户在其运行环境中发现，这种不一致会使 Skill 已挂载却无法解析。让 Agent 明确打开对应 SKILL.md，然后再让它审查一个具体组件，才能确认规则真的参与了任务。