vue-best-practices

Overview of vue-best-practices skill

What vue-best-practices is for

vue-best-practices is a Vue-focused instruction skill for code generation, review, and refactoring in Vue 3 projects. Its core job is not just “write Vue code,” but “write Vue code using current architectural defaults that stay maintainable under real project pressure.” In practice, it pushes agents toward Composition API, <script setup lang="ts">, explicit data flow, and Vue-specific decisions that generic frontend prompts often miss.

Who should install vue-best-practices

This skill is best for teams and solo developers working on Vue 3, .vue single-file components, Vue Router, Pinia-style state patterns, Vite-based apps, and SSR-capable Vue apps. It is especially useful if you want an AI assistant to stop drifting into generic JavaScript patterns and instead follow Vue-native conventions.

Real job-to-be-done

The real value of vue-best-practices is reducing avoidable design mistakes before coding starts. The skill explicitly tells the agent to confirm architecture first, then keep a few core references in active context: reactivity, SFC structure, component data flow, and composables. That makes it more useful for implementation decisions than a plain “build this component” prompt.

What makes this skill different

The differentiator is its decision path. The skill does not only say “use Vue 3.” It establishes defaults and boundaries:

• default to Composition API with <script setup lang="ts">
• switch skills if the project is explicitly Options API or JSX
• treat props, emits, v-model, provide/inject, async components, transitions, and performance as first-class design concerns
• use focused reference docs for edge cases instead of relying on memory

When vue-best-practices is a strong fit

Use vue-best-practices for Frontend Development when you need help with:

• creating or refactoring Vue components
• choosing between props/emits, v-model, provide/inject, or a store
• composable design
• SSR-aware async component choices
• slot APIs, fallthrough attrs, transitions, KeepAlive, and list performance
• reviewing whether a Vue implementation is idiomatic, not merely functional

When it is not the right skill

Do not rely on vue-best-practices as your main guide if the codebase is intentionally Options API-heavy or JSX-heavy. The skill itself says to load a different skill in those cases if available. It is also not a substitute for framework-specific docs around Nuxt routing, testing setup, or deployment concerns not covered in the references.

How to Use vue-best-practices skill

vue-best-practices install context

Install the parent skill repository, then invoke the vue-best-practices skill from that collection:

npx skills add vuejs-ai/skills --skill vue-best-practices

The repository path is:
skills/vue-best-practices

GitHub source:
https://github.com/vuejs-ai/skills/tree/main/skills/vue-best-practices

Read these files first

For a fast, high-signal read, start with:

• skills/vue-best-practices/SKILL.md
• skills/vue-best-practices/references/reactivity.md
• skills/vue-best-practices/references/sfc.md
• skills/vue-best-practices/references/component-data-flow.md
• skills/vue-best-practices/references/composables.md

Those four references are named as must-read core context in the skill itself. If you skip them, you lose most of the skill’s practical value.

What input the skill needs from you

vue-best-practices usage improves sharply when you provide architectural context, not just a feature request. The minimum useful input is:

• Vue version and whether this is Vue 3
• whether the project already uses TypeScript
• whether the codebase requires Composition API, Options API, or JSX
• router/store context
• SSR or client-only context
• the component’s responsibilities
• existing parent/child data flow
• constraints on performance, accessibility, or bundle size

A weak prompt asks for a component. A strong prompt explains where that component sits in the app and how data should move.

Turn a rough goal into a strong prompt

Weak:

• “Build a Vue modal.”

Stronger:

• “Using vue-best-practices, create a Vue 3 modal component with <script setup lang="ts">. The modal is controlled by the parent via props and emits, must support v-model:open, trap focus, Teleport to body, and avoid mutating props internally. Show the component API, parent usage, and explain why props/emits are better here than provide/inject.”

That version gives the skill enough context to apply its data-flow and component-API guidance.

Best workflow for first use

A practical vue-best-practices guide looks like this:

1. Confirm the project architecture before asking for code.
2. State whether Composition API is the default.
3. Ask the agent to consult the core references first.
4. Request an implementation plan before code if the component boundary is unclear.
5. Generate the component.
6. Run a second pass focused on Vue-specific review: reactivity, attrs, slots, performance, and SSR behavior.

This workflow matches the skill’s “confirm architecture before coding” emphasis.

How to ask for the right architectural decision

This skill is most useful when the question is framed as a decision, not a code dump. Good examples:

• “Should this state live in the parent, a composable, or Pinia?”
• “Is v-model appropriate here or should this be explicit props/emits?”
• “Should this large list use virtualization?”
• “Is <Transition> correct here, or would class-based animation be simpler?”
• “Should this component be async-loaded in SSR?”

These map directly to the repository’s references.

Reference files worth pulling in by task

Use these references selectively based on the task:

• references/component-async.md for lazy loading and SSR hydration timing
• references/component-slots.md for slot API design and defineSlots
• references/component-fallthrough-attrs.md for $attrs and useAttrs()
• references/component-keep-alive.md for cache behavior and stale state risk
• references/component-transition.md and references/component-transition-group.md for enter/leave cases
• references/animation-class-based-technique.md for non-mount/unmount effects
• references/state-management.md for state ownership decisions
• references/perf-virtualize-large-lists.md for large list rendering
• references/perf-v-once-v-memo-directives.md for selective render optimization

Practical prompt patterns that get better output

Use prompts that ask for both code and reasoning. For example:

• “Apply vue-best-practices and explain the chosen data-flow model.”
• “Refactor this component to Composition API with <script setup lang="ts">, and call out any reactivity pitfalls.”
• “Review this .vue file against vue-best-practices and classify issues as architecture, data flow, performance, or API design.”
• “Implement this feature and list which Vue references were used.”

This forces the assistant to reveal its assumptions instead of silently inventing patterns.

Common adoption blockers

The biggest blocker is mismatch with the actual codebase. If your project is older Vue, Options API-first, or uses JSX/render functions heavily, the skill’s defaults may create churn. Another blocker is under-specifying state ownership. Many Vue mistakes come from asking for UI behavior without saying who owns the state, which leads to bad prop mutation or muddy two-way binding.

What to verify after generation

After using the vue-best-practices skill, check:

• props are not mutated in children
• emits are explicit and typed when using TypeScript
• watch is not used where computed would be simpler
• composables hold reusable logic, not accidental shared state
• async components do not create poor loading UX
• attrs, slots, and transitions follow Vue conventions
• performance tactics are justified, not cargo-culted

vue-best-practices skill FAQ

Is vue-best-practices beginner-friendly

Yes, but it is more helpful for beginners when used as a reviewer than as a blind code generator. The references explain why certain Vue patterns are preferred, which helps new users avoid learning anti-patterns too early.

Does vue-best-practices only support Vue 3

Effectively yes for its default path. The skill strongly centers Vue 3, Composition API, <script setup>, TypeScript, SSR-aware patterns, Volar, and vue-tsc. If your app is Vue 2 or migration-heavy, this is not the best fit.

How is vue-best-practices different from a normal prompt

A normal prompt may produce working Vue-like code. vue-best-practices gives the assistant a specific architectural bias and a reading order. That matters in Vue because mistakes around reactivity, component communication, attrs, caching, and slots often look fine at first but age badly.

Is vue-best-practices good for existing codebases

Yes, especially for refactors and reviews. It is often more valuable on existing components than on greenfield work because it helps identify unclear state ownership, overgrown components, and Vue-specific correctness issues that are easy to miss in mature apps.

Should I use it for Pinia, Router, and SSR tasks

Yes, if the task is still fundamentally Vue architecture or component behavior. The skill description explicitly covers Vue Router, Pinia, Vite with Vue, and SSR-related concerns. Just include those constraints in your prompt so the agent does not assume a simpler client-only case.

When should I not use vue-best-practices

Skip it when:

• the project explicitly requires Options API conventions
• the project uses JSX as a primary authoring style
• you need framework-specific guidance outside the repo’s references
• you only want a quick throwaway prototype and do not care about Vue idioms

How to Improve vue-best-practices skill

Give vue-best-practices stronger architectural inputs

The fastest way to improve output quality is to specify:

• state owner
• component boundaries
• parent/child API expectations
• TypeScript requirement
• SSR vs client-only rendering
• expected scale, such as large lists or cached views

Without that, the skill has to guess the design tradeoffs it was meant to make explicitly.

Ask for a plan before implementation

For non-trivial work, first ask:

• what state belongs where
• whether the feature should be a component, composable, or store concern
• whether communication should use props/emits, v-model, provide/inject, or router/store state

This follows the repository’s architecture-first rule and usually improves the first code pass more than asking for “clean code.”

Use the reference library deliberately

The vue-best-practices skill has meaningful depth in its references/ folder. Better results come from naming the relevant file in your prompt:

• “Use component-data-flow.md logic”
• “Check component-async.md because this is SSR”
• “Apply component-fallthrough-attrs.md because this wrapper forwards attrs”
• “Use perf-virtualize-large-lists.md because this table can exceed 5,000 rows”

That is a practical advantage over generic prompting.

Watch for the most common failure modes

Typical weak outputs happen when the assistant:

• mutates props instead of emitting updates
• uses watchers where computed state is enough
• chooses provide/inject too early
• wraps logic in a component that should be a composable
• adds transitions where class-based animation is simpler
• caches views with <KeepAlive> without a freshness strategy
• suggests premature micro-optimizations without evidence

These are exactly the kinds of issues this skill is meant to reduce.

Improve review prompts after the first draft

After code generation, ask for a second pass like:

• “Review this against vue-best-practices and list the top 5 risks.”
• “Find any reactivity edge cases or data-flow violations.”
• “Check whether this slot API and fallthrough attrs behavior are robust.”
• “Audit this SSR component for async loading and hydration concerns.”

A first pass creates code. A second pass extracts the skill’s real value.

Make output more actionable with explicit deliverables

If you want higher-quality vue-best-practices usage, ask for:

• final code
• a short architecture rationale
• a list of rejected alternatives
• migration notes if refactoring existing code
• a verification checklist for vue-tsc, Volar, and runtime behavior

That format reduces shallow answers and makes the result easier to adopt in a real repo.