react ยท diff
git:20260722.f0eb407 to git:20261105.39988c5
14 added, 33 removed. Audit A to A.
---
name: react
- description: Engineer React components, Hooks, state, Effects, rendering, Suspense, SSR, hydration, and Server Components. Use for React-owned behavior; not Next.js routing or caching, and not merely because React is installed.
+ description: Implements and refactors React or Next.js components, hooks, data loading, rendering, bundles, and composition. Use for React UI behavior and Next.js routes, or accessibility and interface review of web UI, including HTML and CSS without React.
---
- # React
-
- ## Resolve the React contract
-
- - Inspect the renderer owner, source, lockfile, framework or bundler configuration, tests, and installed metadata. Resolve the exact `react`, `react-dom` or other renderer, type package, Hooks lint plugin, and compiler versions; declared ranges are not resolved versions.
- - Check for duplicate React copies and renderer/version mismatches when Hooks, context, hydration, or scheduling behave unexpectedly. Identify whether the owner is client-only React, SSR, React Server Components, native rendering, or a component library.
- - Follow the framework for routing, data caches, server endpoints, and deployment behavior. This skill owns React semantics; use the Next.js skill for Next router and cache behavior.
-
- Read [versioning and interop](references/versioning-interop.md) before migrations, compiler changes, or version-sensitive APIs. Use [authoritative React sources](references/sources.md) when support or API status matters.
-
- ## Preserve component and Hook semantics
-
- - Keep render idempotent and free of observable side effects. Treat props, state, context, Hook inputs, and existing JSX as immutable snapshots; never depend on render count or timing.
- - Call components through JSX and Hooks only at permitted top-level positions. Keep the repository's Hooks lint rules enabled and restructure code rather than suppressing dependency diagnostics.
- - Derive values during render when possible. Put user-caused work in event handlers or Actions. Use an Effect only to synchronize with a system outside React, pair setup with complete cleanup, and make it safe to restart.
- - Preserve state through stable component identity. Reset intentionally with position or keys, and use stable data identifiers for list keys rather than array position or generated-per-render values.
- - Choose local state, reducer, context, or an external store by ownership. Context is for a real provider boundary, not a substitute for passing a small number of clear props. Use [component, state, and Effect guidance](references/component-state-effects.md) for detailed choices.
- - Keep controlled text input updates urgent. Use transitions or deferred values only for non-urgent rendering work and expose pending state without making correctness depend on scheduling.
-
- ## Handle rendering boundaries and failures
-
- - Keep server and client initial output deterministic. Fix hydration mismatches at the source rather than suppressing warnings or rendering a deliberately different first tree.
- - Keep browser-only APIs out of server/shared modules and privileged code out of client graphs. Treat every serialized prop as public and verify values crossing an RSC boundary are serializable.
- - Let the renderer or framework own streaming and RSC transport. Use direct React DOM streaming APIs only when implementing the renderer integration, with the stream type supported by the host.
- - Place Suspense and error boundaries around independently recoverable regions. Error boundaries do not catch every event-handler, asynchronous callback, or server-rendering failure.
- - Abort obsolete work or ignore stale completions, bound concurrency and retries, and define cache ownership before adding caching. Do not create an Effect-based fetch layer when the framework or existing data library owns reads.
- - Never render unsanitized HTML. Preserve semantic names, focus behavior, keyboard interaction, status announcements, and reduced motion in component behavior.
-
- Use [rendering and performance guidance](references/rendering-performance.md) for concurrency, Suspense, memoization, SSR, hydration, and RSC details. Use [forms, data, and error guidance](references/forms-data-errors.md) for form Actions, optimistic state, cancellation, and recovery. Use [testing, accessibility, and security guidance](references/testing-accessibility-security.md) when those contracts change.
-
- ## Use project feedback
+ 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.
- Run the repository's focused typecheck, Hooks lint, and component or integration tests. Run the production build and a real browser/server smoke test when changing SSR, hydration, RSC boundaries, Suspense, compiler behavior, or renderer versions. Profile before adding memoization, and verify rendered behavior through roles, labels, text, and interactions rather than component internals.
+ 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.