git:20260621.2caaecc to git:20260905.f7824ba

10 added, 13 removed. Audit A to A.

---

name: performance-audit-websites

- description: "Audit website performance. Use for Core Web Vitals, LCP, INP, CLS, Lighthouse or browser performance checks, bundle and asset weight, image/video loading, font loading, third-party scripts, animation cost, hydration cost, and production-readiness performance review."

+ description: "Diagnose measured runtime and Core Web Vitals."

---

# Performance Audit Websites

- Use this skill to keep premium sites fast enough that visual ambition does not punish users.

+ Use this skill to keep premium sites fast enough that visual ambition does not punish users. Measure first and optimize the dominant constraint; do not apply framework folklore as proof.

+ Own measured diagnosis and implementation. Route pre-build numeric budgets, acceptance thresholds, and visual-richness policy to `$performance-budget-lab`.

## Workflow

- 1. Inspect the project, scripts, routes, local/deployed URL, production surfaces, and available QA/deployment tooling.

- 2. Read [Performance Audit Websites Guide](references/performance-audit-websites-guide.md) before claiming the site is ready.

+ 1. Inspect the affected surface, relevant project scripts, target URL and available inspection tooling; reuse existing context.

+ 2. Read [Performance Audit Websites Guide](references/performance-audit-websites-guide.md) before claiming the site is ready. For React or Next.js implementation work, also read [React and Next.js performance](references/react-next-performance.md).

3. Run the narrowest meaningful checks for the risk: visual, mobile, accessibility, performance, forms, media, SEO, analytics, deployment, or handoff.

4. Fix issues when they are in scope; otherwise record exact evidence and remaining risk.

5. Summarize commands, URLs, screenshots/checks, changed files, and what was not tested.

- ## Always Protect

+ Separate field data, controlled lab data, source inspection, and inference. A Lighthouse score from one machine is not a field-performance guarantee; an optimized source pattern is not a measured user improvement.

- - Inspect before changing or shipping: framework, package scripts, build output, routes, forms, media, animation stack, deployment target, environment variables, analytics, SEO metadata, accessibility risks, and available browser QA tooling.

- - Do not claim something was tested unless it was actually tested; report exact commands, URLs, screenshots, viewports, failures, skipped checks, and remaining risk.

- - Verify desktop and mobile rendered output, not only source code. For visual or motion work, inspect screenshots, browser behavior, console errors, network failures, and responsive layout.

- - Treat forms, checkout, booking, CMS content, analytics, environment variables, and deployments as production surfaces with error, loading, empty, success, and rollback states.

- - Respect accessibility, performance, reduced-motion, and no-JavaScript/no-WebGL/no-autoplay fallbacks where relevant.

- - Keep secrets out of code, logs, screenshots, summaries, widgets, and committed files.

- - Prefer project-local tooling and existing scripts before adding dependencies. Explain any new dependency before installing it.

- - End with a concise handoff: changed files, commands run, checks passed, checks not run, deployment URL if any, and next risks.

+ ## Scoped execution

+ Apply the [shared web contract](../website-operating-rules/references/scoped-web-contract.md) once when execution crosses phases; reuse it if already read. Load only the specialist guidance relevant to the requested surface and deliverable.