메뉴
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:
