用途：react-scan 用于捕获并分析 Remotion Studio 的 React 渲染性能，适合诊断不必要的重渲染、缓慢提交等性能问题。官方建议针对可复现的 Studio 交互做定向捕获，不要仅凭源码推断性能问题。
主要能力：在开发捕获模式下注册 WebMCP 工具，可通过 start_react_scan_recording、stop_react_scan_recording 和 get_react_scan_recording 记录并返回原始事件与面向智能体的摘要。摘要包含提交事件、profilingHooksStatuses、组件自身耗时、渲染原因等信息，便于定位高自身耗时、重复昂贵渲染或明显缓慢提交的组件。
使用方式：从仓库根目录运行 bun run react-scan:capture；Brand Studio 使用 bun run react-scan:capture:brand。等待 Studio 构建完成，用浏览器打开打印的 Studio URL 并让页面稳定。调用 start_react_scan_recording 后，用 browser-use 将某个具名交互执行三次，随后立即调用 stop_react_scan_recording，保持录制简短，再调用 get_react_scan_recording 获取结果。完成后用 Ctrl+C 停止 Studio。
分析要点：先读摘要，确认包含提交事件并查看 profilingHooksStatuses，不要把缺少 profiling 通道误判为空闲。优先关注自身耗时长、重复昂贵渲染或用户可见缓慢提交的组件。inclusive duration 含子组件工作，可能重复计算子树，应先定位昂贵边界，再用 self duration 和原始树确认实际工作。渲染原因应作为证据而非自动处方：父组件渲染次数高但无相关 prop、state、context 或 hook 变化，可能说明存在稳定的 memo 边界；重复变化的 props 应先检查源位置的引用稳定性；hook、state 或 context 变化需追踪所属更新，memo() 无法阻止。源码位置指向 JSX 调用点，编辑前先搜索组件定义。
验证：保留基线捕获，改代码后用相同交互次数和相同视口录制并比较，要求相关提交或组件指标改善且行为无回归。不要为每个重渲染都做优化，廉价且必要的渲染往往优于增加 memo 复杂度。报告前后测量变化及所做检查。
限制：WebMCP 工具仅在开发捕获模式下注册；录制仅存在于 WebMCP 结果中，不会发送到独立 HTTP 收集器；激活时 React Scan 会替换 React DevTools profiling hook 通道，不要同时使用 React DevTools Timeline Profiler。有关时间线定位的发现，改订阅或 memo 边界前还需阅读 ../studio-perf/SKILL.md。