What this prompt does
This prompt asks the AI to design a complete Pinia state-management architecture for a Vue 3 application of a given [app_type], built around the specific [stores] you list. Instead of dumping a single monolithic store, it produces setup-store definitions (Composition API style), TypeScript interfaces for every piece of state, and an explicit plan for how stores reference each other without circular dependencies. It also covers where API calls belong, how side effects subscribe to store changes, and how the stores are tested in isolation.
The structure works because it forces decisions you usually discover too late. The [optimistic_actions] placeholder makes the AI write updates that apply instantly and roll back on error, so the UI feels responsive even under a slow network. [persisted_state] tells it exactly which slices to wire through pinia-plugin-persistedstate, and the SSR section keeps hydration in mind from the start. By naming your real stores up front, you get an architecture shaped to your domain rather than a generic template, with naming conventions and a file structure the whole team can follow.
When to use it
- Starting a Vue 3 app large enough that store coupling becomes a real problem
- Migrating from Vuex to Pinia and wanting a clean target architecture
- Adding optimistic updates with rollback to an existing Pinia setup
- Setting up SSR/Nuxt hydration and needing a persistence strategy that survives it
- Deciding where API calls belong (stores vs composables) before the team scatters them
- Establishing naming conventions and file structure for a growing front-end team
Example output
You get a structured architecture document: setup-store code blocks for each store in [stores], TypeScript interfaces for state, getters and actions, a section on cross-store composition that avoids circular dependencies, persistence config for [persisted_state], SSR hydration notes, a subscription-based side-effect pattern that triggers things like analytics, testing snippets using createTestingPinia, and a suggested file structure with naming conventions. If Vuex is relevant, a migration guide is appended that maps old modules onto the new stores.
Pro tips
- List
[stores]with their real names (useAuthStore, useProjectStore) so cross-store references map to your domain instead of placeholders - Be specific in
[optimistic_actions]— name the exact mutations you want to feel instant, since each needs its own rollback path and error handling - Keep
[persisted_state]minimal; persisting tokens, theme and UI flags is sensible, but persisting large lists bloats storage and risks stale data - Set
[app_type]precisely (project management SaaS vs e-commerce) because it changes which stores carry the heavy logic and where coupling appears - Ask for the SSR section only if you actually run Nuxt or custom SSR; otherwise it adds hydration complexity you don't need
- Decide up front whether API calls live in stores or composables, and keep that consistent so data fetching stays predictable as the app grows
- Treat the migration guide as a starting checklist, then verify each converted store against your existing Vuex modules before deleting anything
