| name | vue-nuxt |
| description | Vue, Nuxt, .vue, nuxt.config, Vue 3, Composition API -> use when editing, reviewing, or implementing Vue or Nuxt code. |
Vue / Nuxt
Prefer repository-local conventions for components, composables, routing, stores, styling, and tests before applying general guidance.
Components and Composition API
- Use Vue 3 Composition API idioms consistently:
script setup when the repo uses it, clear refs/computed values, and composables for reusable stateful logic.
- Keep components focused: separate presentation, data fetching, and domain logic when the project structure supports it.
- Define props and emits explicitly with TypeScript types or runtime validation matching the repository style.
- Avoid mutating props directly; emit events or update shared state through established stores/composables.
Nuxt, state, and data fetching
- Respect Nuxt conventions for pages, layouts, middleware, plugins, server routes, and
nuxt.config.
- Choose
useFetch, useAsyncData, server routes, stores, or composables according to existing data-fetching patterns.
- Account for SSR and hydration: avoid browser-only APIs during server render, guard client-only work, and keep rendered markup deterministic.
- Handle loading, empty, and error states close to the UI that owns them.
Accessibility, forms, and UX
- Use semantic HTML first; ensure labels, keyboard access, focus management, ARIA, and contrast are not regressed.
- Treat form state and validation deliberately: show actionable errors, avoid losing user input, and prevent duplicate submissions.
- Keep route changes, async updates, and optimistic UI states understandable and reversible where needed.
Performance, TypeScript, and styling
- Avoid unnecessary watchers, broad reactive objects, repeated expensive computed work, and large client-only bundles.
- Use lazy loading, Nuxt server/client boundaries, and caching patterns already present in the repo.
- Prefer precise TypeScript types for props, emits, API responses, and composables without fighting inferred Vue types.
- Follow existing styling conventions, design tokens, class ordering, and component library usage.
Testing
- Match the repo's test stack for components, composables, routes, and end-to-end behavior.
- Test user-observable behavior, accessibility-relevant states, data-fetch outcomes, and SSR/client-only edge cases when relevant.
