Review a proposed or existing state-management design without re-litigating routing/URL-state ownership, API contract shape, or SSR hydration-mismatch diagnosis in every response. Most state-management bugs trace back to a single category error: treating server-owned data (fetched from an API, subject to staleness, shared across users or tabs) as if it were client-owned data (form input, UI toggles, ephemeral interaction state). Once that error is made, every downstream decision — where to put the data, when to refetch it, how to invalidate it, whether an update needs a rollback path — compounds it. This skill exists to catch that root-cause error early and to evaluate the caching/invalidation strategy and store topology against two measurable failure modes: stale/duplicated data and unnecessary re-render cascades.
\nUse this skill when the user asks to:
\nDo not use this skill for:
\nrouting-navigation-review,api-integration-contract-review,ssr-hydration-streaming-diagnosis. This skill only covers SSR store/queryClient instantiation (per-request vs. shared singleton), not hydration mismatch mechanics./tanstack/query with resolve-library-id before asserting any caching default (staleTime, gcTime, refetchOnWindowFocus) — these are documented defaults, not universal truths, and the repo's installed major version governs behavior. staleTime defaults to 0 (query is considered stale immediately after any successful fetch) and refetchOnWindowFocus defaults to true; do not assume the reviewed repo has left these at default without checking the QueryClient construction site.query-docs on /tanstack/query for \"optimistic updates\" to confirm the current documented shape (onMutate cancels in-flight queries, snapshots prior data, returns it as mutation context; onError restores the snapshot from that context; onSettled invalidates). Do not invent an alternate rollback API./pmndrs/zustand with resolve-library-id before recommending a selector-based re-render fix. Confirm current useShallow import path and behavior via query-docs before telling a user to add it — the import path (zustand/react/shallow vs zustand/react) and default Object.is comparator behavior are version-sensitive.persist middleware usage that touches auth/session data, call query-docs on /pmndrs/zustand for \"persist middleware\" to confirm current partialize and storage options exist and are the documented way to exclude sensitive fields — do not assume a field-exclusion API without checking it.official_docs URLs in this skill's metadata.json and label every caching-default or API-shape claim documentation-based, verify against installed version rather than stating it as settled fact.package.json first to confirm which server-state library (if any) is actually installed and its major version. Do not recommend a fix keyed to an API that the installed major version does not have.useState/useReducer/a plain client store instead of a query/cache library is a category-error finding, not a style note — it is the root cause of most manual-refetch and stale-cache bugs the skill exists to catch.onError restoring a snapshot taken in onMutate) per the current documented pattern. An optimistic update with no rollback path is a HARD STOP, not a note — it means a failed mutation leaves the UI showing state the server never accepted, with no correction mechanism.localStorage/sessionStorage (directly or via a persist middleware without a partialize exclusion) as a security-relevant finding requiring explicit encryption/expiry/justification — do not wave it through as a caching-pattern detail.Load these only when needed:
\nuseShallow usage, or a reported re-render-cascade / typing-jank complaint.Return, at minimum:
\nrepo evidence, documentation-based, or inference),