菜单
Use when profiling, analyzing, reporting, or optimizing Rsbuild performance, including build, dev server, rebuild, static asset serving, memory usage, and CPU profile analysis.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when asked to create a release PR for an official Rsbuild plugin package under `packages/plugin-*`, such as `@rsbuild/plugin-react v2.1.0` or `@rsbuild/plugin-sass v2.0.0`.
Use when asked to release `@rsbuild/core` for a specific version.
Use when adding or updating Rsbuild end-to-end tests in `e2e/cases`, including new feature coverage, bug reproduction, and regression prevention.
Align Rspress heading anchor IDs between English and Chinese docs. Use for MDX `\{#...}` anchors, shortened hashes, redundant anchors, or dead links.
Create or update draft GitHub releases for the current project's main GitHub repository, then organize GitHub-generated release notes into user-friendly sections without rewriting release note items. Use for preparing, formatting, categorizing, creating, or updating GitHub release notes or draft releases, including optional highlights when the user asks for them.
Use when asked to create a pull request for this repository. It helps the PR follow the repository's branch safety rules, title convention, pull request template, and concise English writing style.
| name | rsbuild-performance-profiling |
| description | Use when profiling, analyzing, reporting, or optimizing Rsbuild performance, including build, dev server, rebuild, static asset serving, memory usage, and CPU profile analysis. |
Define the target scenario before collecting data:
Record the baseline first. Keep runtime, package manager, dependencies, environment variables, command flags, and input project unchanged for comparisons.
Save raw artifacts when available, such as CPU profiles, heap snapshots, logs, timing output, and benchmark commands. Do not rely only on subjective observations.
Separate costs by ownership:
Rank findings by measured impact. Prefer self time for direct optimization targets and total time for understanding call-chain impact.
If implementing an optimization, keep behavior unchanged unless the user explicitly asked for a behavior change. Prefer small, measurable changes over broad refactors.
Re-run the same benchmark after changes. Report before/after numbers, absolute delta, percentage delta, and any variance or confidence limits you can observe.
Return a concise report with:
