Review a frontend application's route tree — path/layout nesting, loader/action data-fetching placement, code-splitting boundaries, and navigation-blocking/focus-management behavior — without re-litigating what data a loader fetches from the backend contract (that is api-integration-contract-review) or SSR streaming/hydration mechanics at a route's data boundary (that is ssr-hydration-streaming-diagnosis) in every response. This skill exists because route-level defects hide in three distinct, easily-conflated places: a route that is \"protected\" only by hiding a nav link or redirecting client-side (an authorization bypass reachable by typing the URL directly), a code-split boundary that accidentally serializes loader→component→action instead of loading them in parallel, and a route transition that silently drops keyboard focus with no status announcement (a WCAG 2.4.3 / 4.1.3 failure that is invisible unless you trace it deliberately).
Use this skill when the user asks to:
\nDo not use this skill for:
\napi-integration-contract-review instead,ssr-hydration-streaming-diagnosis instead,/remix-run/react-router for React Router, /vercel/next.js for Next.js. Do not assume API shape from memory — both frameworks' routing/data APIs have changed materially across major versions (React Router v6 object-route API vs. v7 framework-mode route modules; Next.js Pages Router vs. App Router)./remix-run/react-router for \"loader authentication redirect\" and confirm the current guidance: a loader (or a middleware paired with a loader to force it to run on every client-side navigation) is the enforcement point — a component-level redirect or conditional render is not, because React Router still renders/matches the route client-side without a network round trip that a server can gate./vercel/next.js for \"data access layer authorization\" and confirm the current guidance: official docs explicitly frame middleware/proxy-based checks (cookie-presence checks run at the edge) as an optimistic first pass for UX/redirect purposes, and require the actual authorization check to live in a server-only Data Access Layer close to the data source (Server Component, Server Action, or Route Handler) — do not treat a middleware matcher as sufficient enforcement on its own./remix-run/react-router for \"lazy route module\" and confirm current guidance: the recommended lazy route property loads the component and its loader/action together (e.g., via Promise.all) so they resolve in parallel — a common regression is await-ing them in sequence instead./remix-run/react-router for \"useBlocker\" and confirm current constraints: useBlocker only works within data routers (createBrowserRouter/framework mode) and explicitly does not intercept hard reloads or cross-origin navigations — do not present it as a universal unsaved-changes guard.package.json) before asserting version-specific route-module or App Router conventions; if the repo is on Pages Router or React Router v5/v6 classic mode, framework-mode/App Router guidance does not transfer directly.official_docs URLs in this skill's metadata.json and label the claim documentation-based, unverified against current release.loader (or middleware forced to run via a paired loader) that redirects/throws, or a Next.js Data Access Layer check inside a Server Component/Server Action/Route Handler. Hiding a nav link, a client-side useEffect redirect, or a component-level conditional render is UX affordance only — treat any \"protected\" route lacking a paired server-side enforcement point as a blocking (HIGH) security finding, not a style note.middleware/proxy auth check as sufficient enforcement by itself; official Next.js guidance frames it as an optimistic edge check. Require the corresponding Data Access Layer check to also exist, and flag a middleware-only implementation as a HIGH finding even if the middleware matcher looks correct.Promise.all, or the framework's single lazy property that loads them together) versus sequential await calls that create a waterfall — the latter is a measurable performance regression, not a style preference.aria-live region announces the route/status change for assistive technology. Absence of either is an accessibility (WCAG 2.4.3 Focus Order / 4.1.3 Status Messages) finding, not a nice-to-have.useBlocker) exists for unsaved changes, and verify its known limits (SPA-only; does not cover hard reloads or cross-origin navigation) are either accepted knowingly or covered by a beforeunload handler for the hard-reload case.useEffect on location change, aria-live regions) and label the finding repo evidence with a caveat that runtime confirmation was not performed.Load these only when needed:
\naria-live behavior on route transitions or unsaved-changes navigation blocking.Return, at minimum:
\nrepo evidence, documentation-based, or inference),