React state management skills for AI agents

Ask an agent to "add global state to this React app" and it will produce a store. The store will look right. What it will not tell you is which era of the library it came from — because these documents split on the thing most stores reach eventually: how you subscribe to more than one field at a time. Older instructions pass an equality function as a second argument to the hook. The ones that name version 5 wrap the selector in useShallow instead. Both shapes look plausible on the page, and which one your agent writes is decided by whichever skill you happened to install.

That is what makes a state-management skill worth choosing carefully rather than grabbing by name. Read enough of these documents side by side and a sharper problem shows up: they contradict each other on small mechanical points, sometimes contradict themselves, and none of it is visible from the outside. They write the same second argument to set in incompatible ways, and the longest of them writes it two ways in its own examples. They disagree about which middleware belongs on the outside. One announces the exact package version it targets in a header block and then teaches the older selector idiom two screens later. Below are the ones worth installing, the three lines to check in any state skill before you trust it, and the one gate worth copying out before a store of yours starts writing to local storage.

Top picks

Start by asking whether you need a store at all

The mistake that costs most here is reaching for a global store when the state was never global, and JosiahSiegel/claude-plugin-marketplace/react-state-management is built to stop that at the decision rather than the implementation. It opens with two lookup tables — one mapping libraries to what they are good at, one mapping scenarios to a verdict — so simple local state resolves to useState, complex local state to useReducer, shared state in a small app to Context plus useReducer, and server state to TanStack Query or SWR before any store gets written.

Its best passage is the one that makes Context fast instead of replacing it: user data and user actions go into two separate contexts, the actions object is memoized with useMemo over useCallback-wrapped handlers, and the file exports useUser and useUserActions as separate hooks, so a component that only dispatches stops re-rendering when the data changes. wshobson/agents/react-state-management answers the same question with a comparable category table and a compact selection block, and it does ship one full store inline — devtools wrapped around persist, with the component that consumes it — plus a Redux-to-RTK migration, before handing the rest of its patterns to a references/details.md and calling itself the navigation tier. Both are MIT; JosiahSiegel's is the one that hands your agent more of the code, though its Jotai and TanStack Query material is a pointer to a reference file too.

When the state is really a workflow, take the XState skill that refuses the job

seed-hypermedia/seed/xstate contains no code blocks at all, and that is the point: what it hands your agent is judgement about whether a machine is warranted, not syntax for writing one. It declares itself v5-only and instructs the agent to translate anything that smells of v4 rather than mix eras, and its first move in an existing codebase is to inspect the local package.json files and imports and read the machines already there before deciding how opinionated to be. It then makes the agent pick a mode — new code, local edit, or migration — with migration explicitly preferring the smallest safe translation, and it carries a v4-to-v5 mapping in prose: cond becomes guard, services becomes actors, interpret(...) becomes createActor(...).

The part worth the install is the refusal clause: when the problem has no finite modes, no invoked async processes and no actor communication, the skill tells the agent to say so plainly and recommend @xstate/store instead, and it closes with a compile-minded self-check — every imported symbol actually exported by the file shown, no pseudocode inside a fence meant to be runnable. Scope that verdict to judgement, though: another skill named xstate, pedronauck/skills/xstate, carries XState v5 and the setup() API as worked inline code, adds a section routing between machines, @xstate/store and TanStack Query, and closes on pitfalls and a validation checklist — so if what you want is implementation examples rather than a decision procedure, take that one, or take both. One caveat on seed-hypermedia's: its front matter sets user-invocable: false, so it is written to be picked up by the agent rather than summoned by name, and it is Apache-2.0 rather than MIT.

For Zustand, install the one that names the error message

secondsky/claude-skills/zustand-state-management is the reference to reach for when something is already broken, because it is organised around failures rather than features. Its header block states the package version it was written against, zustand@5.0.8, alongside React 18+ and TypeScript 5+, and its known-issues table pairs each problem with the literal string you will see — "Text content does not match" resolves to the _hasHydrated flag plus onRehydrateStorage, a missing createJSONStorage export resolves to a version upgrade, and middleware type failures resolve to the double-parenthesis create<T>()() form.

yonatangross/orchestkit/zustand-patterns states that same currying rule as a one-line checkmark; secondsky is the document that attaches it to the symptom, which is what makes it useful at the moment the types break. The caveat is specific and worth acting on: for selecting several fields at once it tells you to use shallow, and the string useShallow appears nowhere in the document — so take its troubleshooting and take the multi-value selector idiom from the pick below.

The Zustand skill that turns advice into a merge condition

existential-birds/beagle/zustand-state is short, current, and the one that survives a code review. It teaches the multi-value selector the way the version 5 documents do — useShallow imported from zustand/react/shallow, shown wrapping both an object selector and an array-destructuring one — and it documents the second argument to set under a comment reading // Replace entire state (no merge).

It ends with two gates written as pass conditions for merging code rather than as tips. The persistence gate clears only once someone has named what goes to disk — beagle's phrasing is "partialize or a reviewed full-state snapshot" — and confirmed that none of it is a credential; the devtools gate clears once the middleware is env-gated, or once the pull request carries a one-line note saying why it was left on in production. yonatangross's skill reaches the same verdict on useShallow and goes further on machine-readability — its front matter pins the target as zustand >=5.0.0 and its path_patterns scope it to store directories — but its code lives in reference files loaded on demand. pproenca/dot-skills/zustand indexes 43 rules across eight priority tiers, each tier carrying its own impact rating, which is a genuinely useful map; every rule does state itself in one line inline — "Use useShallow for multi-property selections" — with the explanation and the code behind the link.

For testing, hydration and migrations, the thickest Zustand reference

bobmatnyc/claude-mpm-skills/zustand keeps inline the material most of these documents push into reference files: mocking a store in tests and resetting it between them, Next.js App Router persistence with skipHydration plus a manual persist.rehydrate() on mount, side-by-side migrations from both Redux and the Context API written out as code rather than deferred, and an undo/redo store modelled as past, present and future arrays. Two things are worth knowing before you copy out of it.

Its front matter carries user-invocable: false together with disable-model-invocation: true, which is coherent inside the bundle it was written for and means a straight copy into your own skills directory will sit there unread. The other is internal to the document: its DevTools section writes the second argument to set as false beside an action name — set({ count: 42 }, false, 'setCount'), and twice more in the same block — while its transient-update section writes true in that position and annotates it as an update whose subscribers will not be notified. The examples and the annotation describe the same argument differently, so treat that line as unsettled inside the file rather than lifting it straight into a scrubbing control. patricio0312rev/skills/zustand-state-builder covers comparable ground with a nine-point output checklist and a partialize example that persists the cart and deliberately leaves auth out to be handled with tokens, and it writes that second argument the way bobmatnyc's DevTools section does — false, with the action name after it — but it teaches the older two-argument shallow throughout.

A skill's name is its topic, not its identity

Skill names are not namespaced, so the name on a state-management skill tells you which library it is about and nothing else — the publisher and the body together are its identity. The clearest demonstration is zustand-5, which ships from two unrelated accounts. Below the front matter, Gentleman-Programming/Gentleman-Skills/zustand-5 and prowler-cloud/prowler/zustand-5 are the same document: identical sections in identical order, from the basic store through persist, selectors, async actions, slices, immer, devtools and store access outside React, differing only in that one of them ends with a trailing keywords list. Each front matter names its own account as the author, neither declares an origin, source or derivation field, and their licence stories differ — prowler-cloud's front matter and its repository both say Apache-2.0, while Gentleman-Programming's front matter says Apache-2.0 over a repository licensed MIT. Whichever you install, you are installing that text; the account tells you who to ask when it breaks, and the front matter alone will not tell you where it came from.

The trap runs the other way too. vercel-labs/json-render/zustand is not a Zustand guide: it is an adapter that wires a Zustand vanilla store in as the state backend for json-render, and it states its version boundary outright, requiring Zustand v5 or later and calling v4 unsupported because the vanilla store interface changed. The same split runs through xstate, where one document is a decision procedure with no code at all and another is a worked v5 guide with the examples inline. And the two react-state-management skills discussed above share a name across a guide that keeps most of its patterns inline and one that ships a store and a migration and routes the rest to a reference file. Read the description and the first two sections before you read the name.

Three lines that tell you what you are holding

Open any candidate and look for three things. First, the multi-value selector: useShallow wrapping the selector is the shape the version 5 documents teach, while an equality function passed as a second argument to the hook is the older one — beagle, yonatangross and both copies of zustand-5 use the former, and secondsky, patricio0312rev and bobmatnyc use the latter. Second, the middleware nesting: bobmatnyc, patricio0312rev, secondsky, JosiahSiegel and wshobson all wrap devtools on the outside of persist, while yonatangross wraps persist outermost, and secondsky is the one that gives a reason for its choice — with devtools outermost, persist's own actions show up in the DevTools timeline.

Third, the second argument to set. bobmatnyc, patricio0312rev and secondsky all put something in that slot with a devtools action name after it — false in the first two, undefined in secondsky's fix for actions not showing in DevTools; beagle writes set({ bears: 0 }, true) under a comment calling that a full replacement with no merge; and the vercel-labs adapter offers (next, s) => s.setState(next, true) as an override for full replacement over its own default of shallow merge. bobmatnyc writes that slot both ways, in the same file. Whatever a document means by that argument it should mean one thing, so a document that passes something there without a word about which is one to check before you copy from it.

A skill that declares a version and matches it is better than one that declares nothing, but a declared version is a floor, not a proof: secondsky names its version precisely and still teaches the older selector, while beagle names no version anywhere and uses the current idiom throughout. That gap is not visible from a catalogue card. It is visible on the first screen of the file.

What to install

Start with the decision, not the store: JosiahSiegel's react-state-management, so your agent reaches for useState, useReducer or a split Context when those are the right answer, and TanStack Query when the state is really server data. If the thing you are modelling has finite modes, retries or child processes, add seed-hypermedia's XState skill and let it talk you out of a machine when a machine is overkill — with pedronauck's beside it if you want the v5 code as well as the ruling. For Zustand, pair beagle's compact current-idiom skill with secondsky's failure catalogue: one keeps the code in the shape the version 5 documents expect and stops a secret from being written to storage at review time, the other tells you what the console message means at two in the morning. Reach for bobmatnyc's when you need testing, hydration or migration worked out in full, with its two front-matter keys flipped for use outside its bundle and its set annotation read against its own DevTools examples.

What you have avoided is the quiet drift that started this: an agent emitting the older two-argument selector long after the documents that name version 5 moved to useShallow, a scrubbing control copied off a line its own document writes two different ways, and a persisted store carrying an auth token into local storage because nobody wrote the gate down.