---
name: react
description: Implements and refactors React or Next.js components, hooks, data loading, rendering, bundles, and composition. Use when editing or creating .tsx or .jsx files, React components, Next.js routes, or when the user mentions React, Next.js, UI, frontend, HTML, CSS, Tailwind, or accessibility, including HTML and CSS without React.
---

1. Identify the requested behavior, affected route and components, their callers, React and framework versions, router, bundler, runtime, and existing checks. Inspect whether React Compiler is enabled. For a standalone HTML/CSS review, use the interface reference without imposing a React toolchain.
2. Read official documentation matching the installed version before changing framework APIs, caching, or runtime boundaries. Use packaged documentation or a release tag if the live site targets a newer version. Preserve the existing router and dependency versions. Do not convert the project to a new state manager or rendering architecture as a side effect.
3. Trace the user interaction through state, data loading, server mutation, and the rendered result. Distinguish real persistence from fixtures or optimistic display. Reproduce the reported failure when practical. Keep props, refs, keyboard behavior, public exports, and supported loading and error states compatible.
4. Keep render pure and hooks in valid call positions. Derive values from current props or state instead of synchronizing a duplicate through an effect. Put action-specific side effects in the event handler. Use effects for external synchronization with complete dependencies and symmetric cleanup.
5. Preserve component identity and immutable state. Define component types outside parent renders, use stable entity keys, and use functional updates when the next value depends on previous state. Keep transient non-rendered values in refs. Do not mutate props or arrays while sorting.
6. For component APIs, state placement, hook dependencies, repeated rendering, or responsiveness, read [composition and rendering decisions](references/composition-rendering.md).
7. For fetching, SSR, hydration, Server Components, actions, caching, or bundle changes, read [data and Next.js decisions](references/data-next.md).
8. When changing interactive UI or reviewing HTML/CSS, read [accessibility and interface checks](references/interface.md). Apply the relevant checks to changed behavior. A role or passing automated scan does not prove keyboard operability.
9. For TanStack imports, use the installed-version discovery procedure in typescript when available. Do not add a second data library for an optimization. For compiler or Node lifecycle changes, use typescript rather than duplicating its procedure here. This skill's UI procedure remains usable on its own.
10. Run the project's relevant interaction tests, configured hook lint, type check when present, and affected production build. Check the actual changed flow, including its loading, empty, error, and retry paths as applicable. Test route navigation, unmount or rapid input when asynchronous ownership changes. For a persistence change, verify the result after reload against the real authorized test backend.
11. Inspect the rendered result at relevant viewport sizes and exercise keyboard focus when layout or interaction changes. Check hydration and console errors for SSR changes. Compare the same scenario before and after a performance change using an existing profiler or bundle report. Do not present a smaller source file or fewer renders alone as a measured speedup.
12. Review all final changes for scope and compatibility. Report the user-visible result and executed verification, with blocked checks named explicitly. Do not claim completion from an unexecuted test, a screenshot, or a build alone.

Use [React versions](https://react.dev/versions) and [Next.js documentation](https://nextjs.org/docs) to locate the matching APIs. Current stable documentation at this review covers React 19.3 and Next.js 16.4.5. These are research baselines, not upgrade instructions.