Nuxt 3

Enforce Nuxt 3 folder contracts and separate page, component, and server responsibilities.

1|Updated May 2, 2026
One-click install
npx skills add https://github.com/Levironexe/architect --skill nuxt-3
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Nuxt 3
Source: https://github.com/Levironexe/architect/tree/main/skills/stacks/vue-nuxt
Command: npx skills add https://github.com/Levironexe/architect --skill nuxt-3

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Nuxt 3 codebases often drift into inconsistent folder usage, scattered business logic, and risky refactors where pages, components, and server routes blur responsibilities. This Skill creates a consistent architecture so an agent can reorganize code without breaking SSR behavior, auto-import conventions, or error handling.

Core Features & Use Cases

  • Enforces a Nuxt-specific folder contract: routes in pages/, UI components in components/, reusable logic in composables/, and server endpoints in server/api/.
  • Standardizes safe data flow: pages stay declarative, composables wrap useFetch/useAsyncData, and server routes delegate business logic to server/utils/.
  • Hardens SSR, errors, and security: uses createError()/error.vue patterns, validates config via Nitro, and keeps secrets out of runtimeConfig.public.
  • Pinia state guidance: global/shared state goes to stores/, while local UI state remains in composables.

Quick Start

Give your AI agent the instruction: “Analyze my Nuxt 3 repository and produce a phased refactor plan that moves data fetching into composables, moves business logic into server utilities, and aligns folder responsibilities with the Nuxt 3 architecture rules.”

Frequently Asked Questions about Nuxt 3

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely refactor a Nuxt 3 app without breaking SSR behavior or auto-imports?

To safely refactor a Nuxt 3 app, enforce strict folder contracts and separation of concerns. Keep routes in `pages/`, UI in `components/`, logic in `composables/`, and endpoints in `server/api/` to prevent responsibility mixing and maintain SSR safety.

What is the best way to structure Pinia state and data fetching in Nuxt 3?

The best way to structure Pinia and data fetching is to wrap `useFetch` and `useAsyncData` strictly within composables. Global shared state should go to Pinia `stores/`, while local UI state remains isolated in composables to ensure safe SSR data flow.

How do I secure secrets and handle errors in Nuxt 3 Nitro server routes?

Secure secrets by keeping them in server-only `runtimeConfig` and validating configuration at Nitro startup. Handle errors in server routes by using `defineEventHandler` with `createError()` patterns to ensure consistent error responses.

Why does my Nuxt 3 business logic drift into pages and components during refactoring?

Business logic drifts during refactoring when folder boundaries are unclear. Standardize your architecture by delegating server business logic to `server/utils/` and keeping pages declarative, ensuring pages and components blur responsibilities less.

Does this Nuxt 3 refactoring approach work with auto-imported components and composables?

Yes, this refactoring approach explicitly supports Nuxt 3 projects that use auto-imported components and composables. It establishes consistent application architecture to reorganize code without breaking auto-import conventions or SSR behavior.

When do I need to validate runtimeConfig at startup for a Nuxt 3 server?

You need to validate `runtimeConfig` at startup when hardening security and preventing configuration errors in Nitro server routes. This ensures secrets remain server-only and your Nuxt 3 application fails fast on invalid configurations.