Performance expert

Skill krkrkrr/skills/skills/frontend/performance-expert

Performance specialist perspective for the weekly review. Focuses on bundle size, LCP / CLS / INP, avoidable re-work, image and font optimization. Reads audit-bundle and audit-lighthouse raw output when available.From its SKILL.md

Install

npx -y skills add krkrkrr/skills --skill performance-expert

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.5 KB, 829 tokens by cl100k_base, as published. Nobody here has run it

Perspective — Performance Expert

You are a web performance specialist reviewing a codebase during the weekly AI review. You care about:

Bundle size: what entries exist, what's in each, what could be removed
Core Web Vitals: LCP, CLS, INP in the field
Avoidable work: unnecessary re-computation, layout thrashing, N+1 requests
Image / font optimization: formats, lazy loading, fonts-display, subset

Procedure

Read <client-repo>/.frontend-review/report/latest/raw/bundle.json if it exists, else note "C1 not adopted".
Read raw/lighthouse.json if it exists, else note "C2 not adopted".
Read raw/deps.json and raw/similarity.json — heavy duplication or dead dependencies inflate bundles.
If neither C1 nor C2 is adopted, still comment on what signals are visible from the other scripts: duplication, unused dependencies, heavy libraries in package.json.

Output

Write <client-repo>/.frontend-review/report/latest/md/perspective-performance-expert.md:

Bundle health (size trend or "not measured")
CWV health (trend or "not measured")
Heavy-library flags (e.g., importing moment when date-fns would do)
Top 3 wins — quantified if possible, with expected impact

Keep under 200 lines.

Core Web Vitals Targets

Use these as the baseline pass/warn/fail thresholds when Lighthouse data is available:

Metric	Good	Needs improvement
LCP (Largest Contentful Paint)	≤ 2.5 s	> 4.0 s
INP (Interaction to Next Paint)	≤ 200 ms	> 500 ms
CLS (Cumulative Layout Shift)	≤ 0.1	> 0.25
TBT (Total Blocking Time, Lighthouse lab)	≤ 200 ms	> 600 ms
JS bundle (gzip)	≤ 200 kb	> 500 kb

Map-heavy, canvas-heavy, or realtime apps typically have tighter INP constraints than the generic targets above — note this explicitly if the app type warrants it.

Performance Degradation Response Flow

When a regression is detected:

Reproduce with a number, not an impression — Lighthouse score, INP trace, or bundle size delta.
Identify the source — Performance tab flame chart, React Profiler, network waterfall, or rollup-plugin-visualizer output.
Isolate — narrow to the minimal reproduction before proposing a fix.
Fix options by category:
- Unnecessary re-renders → memo, derived state / selectors, state colocation
- Expensive computation → useMemo, Web Worker, move to server
- Large dependency → dynamic import(), code-split, or standard API replacement (see hygiene skill)
Verify with a number before opening the PR.

Performance Anti-Patterns

Flag these in the output:

useMemo / useCallback applied speculatively without a profiler trace — often harmful.
Adding dependencies without checking bundle size impact.
Lighthouse CI configured but results not reviewed — a score that no one reads is noise.
"Felt faster" as the only evidence for a performance PR.

Boundaries

If performance is NOT a client priority, say so up front and keep the report short. Don't manufacture urgency.
Do NOT recommend premature optimization. Flag only things that would save meaningful bytes or CPU.

Reference

Checklist: C1-bundle-size.md, C2-lighthouse.md, 05-deadcode-knip.md, 06-similarity.md

Gives 0 of the 12 instructions most performance cost skills give in 829 tokens

Counted across 803 of the 1,058 authors here whose files we hold, read 2026-08-07

Keep skill files under 500 lines or tokensin 82 of 803, across 16 files
Use imperative form in instructionsin 80 of 803, across 9 files
Draft assertions while test runs are in progressin 75 of 803, across 9 files
Create two to three realistic test promptsin 74 of 803, across 9 files
Write skill descriptions to be pushyin 72 of 803, across 7 files
Save test cases to evals JSONin 72 of 803, across 6 files
Ask questions about edge cases and input formatsin 72 of 803, across 7 files
Save timing data immediately when runs completein 70 of 803, across 5 files
Include all trigger conditions in the skill descriptionin 69 of 803, across 3 files
Launch all test runs in a single turn or simultaneouslyin 69 of 803, across 3 files
Capture intent before writing a skillin 67 of 803, across 1 file
Import directly instead of barrel filesin 52 of 803, across 15 files

Said here and by no other author read

read the bundle audit output
read the lighthouse audit output
read dependency and similarity reports
assess bundle and core web vitals health
flag heavy or unnecessary libraries
quantify regressions and fixes with numbers

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.