serkodev/vue-skills
Overview
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.
How this skill works
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.
When to use it
- Starting a new Vue or Nuxt project to set consistent conventions
- Refactoring large components into smaller, testable parts
- Performing code reviews focused on state, reactivity, and data flow
- Implementing cross-component state or shared logic with composables or a store
- Migrating Options API codebase toward Composition API and TypeScript
Best practices
- Keep one source of truth for state; derive values instead of duplicating them
- Prefer Composition API and <script setup lang="ts"> SFCs by default unless constrained
- Keep components small and single-responsibility; split UI and orchestration
- Move shared logic and side effects into composables (useXxx) and use a store for app-wide state
- Make data flow explicit: props down, emits/events up, use v-model for two-way bindings, provide/inject sparingly
- Use computed properties and watchers appropriately to avoid unnecessary re-renders
Example use cases
- Split a dashboard component into data-fetching composable + presentational child components
- Refactor form logic into a useForm composable and keep inputs as focused child components
- Review a PR to ensure props/emits are used instead of global mutable state
- Migrate a small app from Options API to Composition API with TypeScript SFCs
- Introduce a centralized store for authenticated user state and derive read-only views with getters
FAQ
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.