vue-pinia-best-practices

Overview of vue-pinia-best-practices skill

The vue-pinia-best-practices skill is a focused guidance skill for Vue 3 teams using Pinia who want fewer state-management bugs and better default architecture decisions. It is not a broad Vue tutorial. Instead, it targets the Pinia mistakes that most often waste time in real projects: bad install timing, broken reactivity from destructuring, setup-store SSR/DevTools issues, and confusion about what belongs in stores versus the URL.

Who this skill is best for

This vue-pinia-best-practices skill fits:

• Vue 3 developers already using or adopting Pinia
• teams migrating from Vuex or hand-rolled reactive() stores
• developers hitting specific runtime issues like getActivePinia() errors
• frontend engineers who want conventions that scale beyond toy apps

It is especially useful when your app has shared state, routing, SSR concerns, DevTools workflows, or multiple contributors.

What job it helps you get done

Use the vue-pinia-best-practices skill when you want an AI assistant to review or generate Pinia code with fewer hidden footguns. The real job-to-be-done is not “explain Pinia,” but “help me structure stores correctly and avoid known mistakes before they ship.”

What makes it different from a generic Vue prompt

A generic prompt may produce plausible Pinia code that still fails in practice. This skill is stronger because it centers a small set of high-impact, evidence-backed patterns:

• install Pinia before anything that consumes stores
• avoid top-level store access before app initialization
• return all reactive state from setup stores
• use storeToRefs() when destructuring state and getters
• keep shareable filter state in the URL, not only in Pinia
• prefer Pinia over ad hoc stores in larger apps

What it does not try to cover

This skill is narrow by design. It will not replace full docs for:

• advanced plugin authoring
• end-to-end SSR framework integration details
• every possible store organization style
• unrelated Vue component patterns

If you need exhaustive framework-specific setup, treat this skill as a guardrail layer, not the whole implementation plan.

How to Use vue-pinia-best-practices skill

Install context for vue-pinia-best-practices

If your skill runner supports repository-based skill installation, add vue-pinia-best-practices from vuejs-ai/skills in the same way you add other skills from that collection. After installation, the important working directory is:

• skills/vue-pinia-best-practices/

Start with:

• SKILL.md

Then read the reference files tied to your current problem.

Read these files first by problem type

The fastest path is to open the reference that matches your symptom:

• reference/pinia-no-active-pinia-error.md for startup/install-order crashes
• reference/pinia-setup-store-return-all-state.md for setup store SSR or DevTools issues
• reference/pinia-store-destructuring-breaks-reactivity.md for stale UI after destructuring
• reference/state-url-for-ephemeral-filters.md for filters, search, sort, and pagination state
• reference/state-use-pinia-for-large-apps.md for architecture decisions
• reference/store-method-binding-parentheses.md for method binding issues in non-Pinia reactive stores

This repo is compact, so using the right file early matters more than reading everything linearly.

What input the skill needs to help well

The vue-pinia-best-practices skill works best when you provide concrete implementation context, not just “help with Pinia.” Include:

• your Vue version and whether you use Vue 3 with Composition API
• whether the store is a Pinia store or a hand-rolled reactive store
• whether the issue appears at startup, during navigation, in templates, or after refresh
• relevant files such as main.ts, router setup, one store file, and one consuming component
• whether SSR, DevTools visibility, or URL persistence matter

Without that context, the assistant may give correct-but-misaligned advice.

Turn a rough goal into a strong prompt

Weak prompt:

• “Help me fix my Pinia store.”

Better prompt:

• “Use the vue-pinia-best-practices skill. I have a Vue 3 app with Pinia and Vue Router. I get getActivePinia() during startup when a router guard reads useAuthStore(). Review my main.ts and router file, explain the root cause, and rewrite the setup in the safest order.”

Another strong example:

• “Use vue-pinia-best-practices to review this setup store for SSR and DevTools compatibility. Tell me if any reactive state is not returned, what that breaks, and provide a corrected store.”

Practical vue-pinia-best-practices usage workflow

A reliable workflow for this skill:

1. Identify the symptom category: startup, reactivity, setup store shape, URL state, or architecture.
2. Attach the smallest set of files that reproduce the issue.
3. Ask the assistant to diagnose using the matching reference/*.md file.
4. Request a corrected code version plus a short rule you can reuse elsewhere.
5. After the first fix, ask for a checklist to apply the pattern across the repo.

This produces better outcomes than asking for a one-shot “best practices review” with no code.

Use it for startup and plugin-order bugs

One of the highest-value uses of vue-pinia-best-practices is resolving “no active Pinia” failures. If router guards or modules call stores too early, ask the assistant to inspect:

• main.js or main.ts
• router creation and guard registration
• any top-level imports that call useXxxStore()

The key issue is usually initialization timing, not the store implementation itself.

Use it for reactivity-safe destructuring

If your UI stops updating after pulling values from a store, ask the skill to check whether you destructured the store directly. The likely correction is:

• keep actions destructured directly if needed
• move state and getters through storeToRefs()

This is a good review prompt for any component that reads many store values.

Use it for setup-store SSR and DevTools checks

If you use defineStore('x', () => {}), have the assistant verify that all reactive state is returned. This matters because omitted state can silently break:

• SSR serialization and hydration
• Vue DevTools inspection
• Pinia plugin compatibility

This is one of the best reasons to use the vue-pinia-best-practices skill during code review, not just debugging.

Use it for state placement decisions

A subtle but valuable vue-pinia-best-practices guide use case is deciding whether data belongs in Pinia at all. Ask the assistant to classify state into:

• app-level shared state
• local component state
• URL-backed view state such as filters, search, pagination, and sorting

This is where the skill adds more value than generic Pinia snippets, because it helps prevent the wrong architecture before code grows.

Best prompt pattern for repo review

For vue-pinia-best-practices for Frontend Development, a strong audit prompt looks like this:

• “Use the vue-pinia-best-practices skill to audit these files for Pinia gotchas. For each issue, label it as install timing, reactivity, setup-store return shape, or state-placement mistake. Show exact fixes and explain production impact.”

That framing pushes the model toward actionable findings instead of abstract advice.

vue-pinia-best-practices skill FAQ

Is vue-pinia-best-practices good for beginners?

Yes, if you are already building with Vue 3 and have started using Pinia. The skill is concise and problem-first, so it is easier to apply than broad documentation. Absolute beginners may still need official Pinia basics for concepts like stores, getters, and actions.

What problems does the vue-pinia-best-practices skill cover best?

It is strongest on a small number of common, high-impact problems:

• getActivePinia() setup timing errors
• broken reactivity from direct destructuring
• setup stores not returning all state
• deciding when URL query state is better than store state
• deciding when Pinia is worth using over hand-rolled state

Is this better than asking for ordinary Pinia help?

Usually yes for these specific topics. Ordinary prompts often generate code that looks fine but misses runtime details like plugin order, SSR serialization, or storeToRefs(). The vue-pinia-best-practices skill narrows the model to proven pitfalls and corrections.

When should I not use vue-pinia-best-practices?

Skip it when your task is mainly:

• learning Vue from scratch
• framework-specific deployment setup unrelated to Pinia
• advanced state-machine design beyond the repo’s scope
• non-Vue frontend stacks

It is a targeted Pinia guardrail skill, not a universal frontend architecture skill.

Does it help with Vuex migration decisions?

Indirectly, yes. The repo explicitly supports the view that Pinia is the right default for larger Vue apps and that Vuex is in maintenance mode. It is useful when reframing old Vuex habits into current Pinia patterns, especially around simpler store ergonomics and tooling.

Can vue-pinia-best-practices help with hand-rolled stores too?

Partly. One reference covers method-binding pitfalls in reactive stores, and the skill also helps you decide when hand-rolled state is still acceptable. But its center of gravity is Pinia, not custom store libraries.

How to Improve vue-pinia-best-practices skill

Give the skill exact failure symptoms

To improve vue-pinia-best-practices output quality, include the exact error text, where it appears, and when it started. For example:

• “Error occurs only during router navigation”
• “DevTools does not show a ref from my setup store”
• “UI stops updating after destructuring the store in <script setup>”

These clues map directly to the repo’s strongest guidance.

Include the lifecycle and file boundary

Many Pinia bugs are really timing bugs. Tell the assistant whether the code runs:

• at module import time
• in setup()
• in a router guard
• during app bootstrap
• during SSR hydration

That context helps the skill distinguish install-order issues from ordinary component bugs.

Provide minimal but complete code slices

Better inputs usually include:

• main.ts
• one router file if guards use stores
• one store file
• one component that consumes the store

Do not paste your whole repo first. A tight reproduction improves diagnosis speed and reduces generic filler.

Ask for classification, not just a fix

A high-yield prompt is:

• “Classify each issue by category, explain why it happens, then patch the code.”

For this skill, good categories are:

• install timing
• reactivity
• setup-store return shape
• URL vs store state
• scale/architecture fit

This makes the output more reusable across future files.

Request before-and-after code

The vue-pinia-best-practices install step is simple compared with the real adoption question: can it improve your generated code? The best way to judge that is to ask for:

• a corrected code sample
• a short explanation of why the original failed
• a checklist you can apply elsewhere

That turns the skill into a repeatable review tool instead of a one-off answer.

Common failure modes to watch for

The most likely weak outputs happen when the input is underspecified. Examples:

• asking for “best practices” without any code or symptom
• not saying whether the store is option-style or setup-style
• omitting router setup when the issue is startup-related
• describing filter persistence needs without mentioning shareable URLs

When that happens, the assistant may give true advice that does not solve your problem.

Iterate after the first output

After the first answer, ask a second-pass question such as:

• “Now scan for the same pattern in the rest of my stores.”
• “Convert this fix into a team convention.”
• “Show how this changes if the state should be shareable by URL.”
• “Add SSR and DevTools checks to the review.”

This is the easiest way to get more value from vue-pinia-best-practices usage than a single correction.

Use the references as review rules

The reference files are compact enough to turn into team code-review checks. Examples:

• no useXxxStore() at module top level
• install Pinia before router if guards read stores
• return all reactive state from setup stores
• use storeToRefs() for state/getter destructuring
• keep view filters in the URL when refresh/share matters

That is the best long-term way to improve results from vue-pinia-best-practices for Frontend Development: use it not only to patch bugs, but to enforce better defaults before they appear.