What this prompt does
This prompt directs the AI to set up Zustand state management for an app you name, returning strict TypeScript rather than pseudocode. You provide the [app], the store [slices], and the [persisted] slices. It produces a single store composed from per-slice creators, devtools middleware named per slice, persist middleware applied only to the persisted slices with a partialize selector, shallow-compare selector hooks, strict types with no any, and an example component reading and updating via narrow selectors.
The structure works because Zustand's flexibility makes it easy to misuse — especially over-persisting state. By splitting the store into [slices] and applying persist only to [persisted] with partialize, the prompt keeps transient data out of storage. [slices] defines the store's shape and where actions live, [persisted] controls exactly what survives a reload, and the strict-TypeScript requirement ensures action signatures are inferred and the store type is exported for reuse.
When to use it
- You're choosing Zustand over Redux and want a clean, typed baseline.
- You need a store split into slices, each with its own state and actions.
- You want devtools wired for the Redux DevTools extension, named per slice.
- You need persistence on only some slices, never live data.
- You're fighting unnecessary re-renders and want shallow-compare selectors.
- You want strict TypeScript with no
anyand an exported store type.
Example output
You get the store file(s) and an example component in separate code blocks: a single store composed from per-slice creators for each entry in [slices], each with its own actions and state; devtools middleware wired for the Redux DevTools extension and named per slice; persist middleware applied only to [persisted] with a partialize selector so transient state is never saved; selector hooks using shallow compare to prevent unnecessary re-renders; strict TypeScript with no any, inferred action signatures, and an exported store type; and an example component that reads and updates the store via narrow selectors.
Pro tips
- Be deliberate about
[persisted]— persist only auth and a couple of UI preferences, never live data, or you'll ship stale state to users after a reload. - Define
[slices]to match real domains in[app]; clean slice boundaries keep actions colocated and make the store easier to reason about. - Use the shallow-compare selector hooks the prompt generates, and read narrow slices in components, to avoid re-rendering on unrelated state changes.
- Keep the partialize selector tight so transient fields never sneak into storage; this is the most common persistence mistake.
- Confirm the exported store type is actually imported where you use the store, so you keep end-to-end type safety rather than re-declaring shapes.
- Ask a follow-up to add a rehydration check if
[persisted]includes auth, so you handle the brief moment before persisted state loads.