feat(skills): add React and Vite tool expertise

Squash-merge verified React and Vite expertise at exact head d4fd6cf70d. Required validate and paired evaluation checks passed; advisory droid review had no blocking findings.

react/references/component-and-state.md

@@ -0,0 +1,54 @@
+# React Component And State Patterns
+
+## Start with ownership
+
+Describe each value as one of local UI state, server/cache state, URL state, or
+cross-cutting application state. Keep state at the lowest common owner. If a
+value is derived from other values, compute it during render or in a memoized
+calculation when measurement proves the calculation costly; do not create a
+second source of truth.
+
+A practical component boundary usually owns one interaction or visual contract.
+Split when a component has unrelated state machines, repeated markup, or an
+API that requires consumers to understand implementation details. Keep domain
+transformations outside presentational components when they can be tested
+without a browser.
+
+## Effects and asynchronous work
+
+Before adding `useEffect`, name the external system it synchronizes with:
+network, subscription, timer, browser API, or imperative widget. If none exists,
+prefer render derivation or an event handler. Every effect should have a cleanup
+when it creates a subscription, timer, listener, or request that can outlive the
+render.
+
+For a request keyed by an input, use an abort signal or an active-request guard,
+handle abort as non-error cancellation, and ensure a late response cannot replace
+newer data. Model `status` explicitly (`idle`, `pending`, `success`, `error`) and
+render all meaningful states. Avoid catching an error only to log it and leave a
+permanently pending screen.
+
+## Interaction contracts
+
+Use controlled inputs when validation, submission, or external reset is part of
+the feature; otherwise an uncontrolled input with a ref may be simpler. Keep
+submit handlers idempotent, disable or guard while pending, and preserve the
+user's entered data on recoverable errors. Announce validation and server errors
+through the accessible structure, not only a color or toast.
+
+For lists, key rows with stable domain identity. If a row has local state, an
+index key can transfer that state to another record after sorting or deletion.
+Use functional updates for transitions based on prior state, especially when
+multiple events may batch.
+
+## Verification checklist
+
+- Hooks are unconditional and dependencies reflect values read from the effect.
+- No derived state or duplicated server state is introduced without a reason.
+- Loading, empty, error, retry, and success states are represented where relevant.
+- Async cleanup prevents stale writes and treats cancellation intentionally.
+- Buttons and links use native semantics; keyboard and focus behavior is tested.
+- Component tests cover user-visible behavior; browser flows are delegated to
+  [playwright](../../playwright/SKILL.md).
+- Dedicated semantic and WCAG review is delegated to
+  [web-accessibility](../../web-accessibility/SKILL.md).

react/references/vite-diagnostics.md

@@ -0,0 +1,51 @@
+# Vite Diagnostics And Release Checks
+
+## Environment values
+
+Vite substitutes client-exposed variables at build time. Only variables with the
+configured public prefix (commonly `VITE_`) should be read by browser code.
+Treat every such value as public: it is not a secret merely because it lives in
+`.env`. Keep credentials and server-only configuration outside the client
+bundle. Check `.env.example`, Vite config, deployment configuration, and the
+actual built assets for accidental exposure.
+
+Vite loads mode-specific files with a defined precedence. Confirm the intended
+mode (`development`, `production`, or a custom mode) and do not assume a local
+`.env` matches CI. When diagnosing a value, inspect its name and source without
+printing its value. Re-run the build after changing env configuration because
+substitution is compile-time.
+
+## Build and asset paths
+
+Inspect `base` in `vite.config.*` when the app is served below `/`. A wrong base
+usually appears as 404s for module, CSS, or asset URLs after deployment even
+though the root-local dev server works. Validate the generated HTML and asset
+references against the real deployment path. For SPA history fallback, confirm
+the host serves the app entry point for non-root routes; Vite does not configure
+that server rule for every deployment target.
+
+## Dependency and output checks
+
+Use the project's package manager lockfile and scripts. Check that `react` and
+`react-dom` versions are compatible and that duplicate React copies are not
+being pulled into the bundle, which can produce invalid hook call errors. Do not
+blindly delete lockfiles or upgrade dependencies while diagnosing.
+
+For release verification, run the existing typecheck/lint/test commands before
+`vite build`, inspect warnings, and use a preview server for a smoke check at
+the deployed base path. Keep source maps and reports out of user-facing output
+unless the project intentionally publishes them.
+
+## Safe diagnostic sequence
+
+1. Record the package manager and available scripts from `package.json`.
+2. Identify the active mode and public-prefix configuration without exposing
+   values.
+3. Inspect `base`, route fallback, and generated asset URLs.
+4. Check lockfile consistency and React package version alignment.
+5. Run the narrowest reproducible check, then the production build.
+6. Confirm the browser flow with [playwright](../../playwright/SKILL.md) when
+   route, asset, or navigation behavior is involved.
+7. Ask [frontend-engineering](../../frontend-engineering/SKILL.md) for broader
+   performance/component strategy and [web-accessibility](../../web-accessibility/SKILL.md)
+   for a dedicated accessibility audit.