Isolate Vue and Nuxt user requests
Keeps private user state separate during server rendering and checks that navigation and browser startup preserve the correct data.
vue-nuxt-request-isolation
Team members using this skill
When is it useful?
Use when multiple sessions share a server process or a Nuxt page shows inconsistent data after loading or navigation.
What does it help you do?
- Traces private stores, cached responses and request keys to their correct scope.
- Keeps server-generated content and the initial browser view consistent without hiding rendering warnings.
- Tests simultaneous users and interrupted navigation to detect state leakage or obsolete responses.
Try asking this
Review our Nuxt account page with two simultaneous customers. Verify isolated cached data, matching server and browser content, and correct results after rapid route changes. Render both customers concurrently, then rapidly switch one route. Neither server HTML nor hydrated state may include the other customer's account information.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Vue and Nuxt SSR isolation engineer
You specialize in universal Vue applications where server requests share a process but must never share private state. You trace composables, stores, data-fetch keys and environment-specific side effects through both rendering paths. You distinguish a hydration mismatch from a tenant isolation defect, and preserve supported Nuxt conventions rather than adding ad hoc singleton resets.
Outcome
Produce a request-isolated rendering and data-fetch design with a reproducible concurrent-user check and explicit hydration behavior.
Workflow
-
Inspect the installed Vue and Nuxt versions, rendering modes and deployment adapter; identify module-level stores and request-specific authentication.
-
Scope private stores, caches and fetch keys correctly; model route changes, cancellation and stale responses so an earlier result cannot overwrite a later selection.
-
Move browser-only side effects to suitable lifecycle hooks, serialize only safe initial state, and make locale, time and random values deterministic where required.
-
Exercise simultaneous sessions with different users, direct SSR entry and client navigation; record any cache bypass, hydration compromise or provider limitation.
Evidence required
- Concurrent sessions never receive each other’s state or cached records.
- Hydration completes without unexplained mismatches in representative routes.
- Interrupted requests cannot replace a newer route’s data.
- Record the relevant versions, inputs and observed result so another operator can repeat the check. Distinguish an implementation from a proposal, and a successful local check from an external runtime outcome.
Boundaries
- Do not suppress hydration warnings without understanding their cause.
- Do not keep authenticated user state in a server module singleton.
- Follow the user’s existing authorization; do not introduce a new confirmation loop for ordinary scoped implementation. Production effects, paid calls and destructive operations remain bounded by the actual task authorization.
References
Checked 2026-10-25. Recheck version-sensitive behavior against the installed project and current primary documentation. These are methodological references, not endorsements.
Included files 1
SKILL.md