home / skills / serkodev / vue-skills / vue-best-practices
This skill helps you apply Vue.js best practices across projects, guiding composition API usage, SFC structure, and data flow for maintainable apps.
npx playbooks add skill serkodev/vue-skills --skill vue-best-practicesReview the files below or copy the command above to add this skill to your agents.
---
name: vue-best-practices
description: A collection of best practices and tips for developing applications using Vue.js. This skill MUST be apply when developing, refactoring or reviewing Vue.js or Nuxt projects.
license: MIT
metadata:
author: SerKo <https://github.com/serkodev>
version: "0.1"
compatibility: Requires Vue 3 (or above) or Nuxt 3 (or above) project
---
# Vue.js Best Practices
## Tasks Checklist
- [ ] Followed the core principles
- [ ] Followed the defaults unless there is a good reason not to
- [ ] Followed the reactivity best practices
- [ ] Followed the component best practices
- [ ] Followed the Vue SFC best practices
- [ ] Kept components focused
- [ ] Split large components into smaller ones when needed
- [ ] Moved state/side effects into composables if applicable
- [ ] Followed data flow best practices
---
## Core Principles
- **Keep state predictable:** one source of truth, derive everything else.
- **Make data flow explicit:** Props down, Events up for most cases.
- **Favor small, focused components:** easier to test, reuse, and maintain.
- **Avoid unnecessary re-renders:** use computed properties and watchers wisely.
- **Readability counts:** write clear, self-documenting code.
## Defaults (unless the user says otherwise)
- Prefer the **Composition API** over the Options API.
## Reactivity
IMPORTANT: You MUST follow the `references/reactivity-guide.md` for reactive state management when creating, updating a component or a composable.
## Components
IMPORTANT: You MUST follow the `references/sfc-guide.md` for best practices when working with Vue SFCs.
- Prefer Vue Single-File Components (SFC) using **`<script setup lang="ts">`** (TypeScript) by default.
- In Vue SFCs, keep sections in this order: `<script>` → `<template>` → `<style>`.
### Keep components focused
Split a component when it has **more than one clear responsibility** (e.g. data orchestration + UI, or multiple independent UI sections).
- Prefer **smaller components + composables** over one “mega component”
- Move **UI sections** into child components (props in, events out).
- Move **state/side effects** into composables (`useXxx()`).
NOTE: This rule also applies to the entry component (e.g. App.vue) in a Vue / Nuxt project by default.
### Data Flow
IMPORTANT: You MUST follow the `references/data-flow-guide.md` for passing and receiving data between components using:
- Props
- Emits
- `v-model`
- provide/inject
For sharing data across the app, please follow the `references/state-management-guide.md` and consider using a Store for state management solution.
This skill provides a compact, opinionated set of best practices for developing, refactoring, and reviewing Vue.js and Nuxt projects. It emphasizes predictable state, explicit data flow, focused components, and the Composition API with TypeScript-ready Single-File Components. Use it to guide architecture decisions, code reviews, and incremental refactors.
The skill inspects code and design choices against core principles: single source of truth for state, props-down/events-up data flow, and component responsibility boundaries. It enforces defaults such as Composition API and <script setup lang="ts"> SFCs, recommends splitting large components, and moves shared logic into composables or a store. It also ensures reactivity and data-flow patterns follow established guides for safe updates and predictable behavior.
Should I always use the Composition API?
Prefer Composition API by default for new code and refactors; keep Options API only when migration cost outweighs benefits.
When should I split a component?
Split when a component has more than one responsibility, mixes orchestration with presentation, or grows hard to test and reason about.
How do I share state across unrelated components?
Use a store for app-wide state and composables for reusable logic. Use provide/inject only for tightly related component hierarchies.