What this prompt does
This prompt scaffolds a complete Nuxt 3 full-stack application template for a given [app_type], putting the frontend, server API, authentication, and database into one coherent project. You define the [api_endpoints], pick an [auth_method] and [orm], choose a [ui_lib], and set a [deploy_target], and it returns a project structured around Nuxt conventions with TypeScript strict mode throughout. It also covers middleware for auth guards, rate limiting, and validation so the server side is protected from the start.
The structure works because Nuxt's server routes let the API and the UI live in a single deployable codebase, and the prompt makes that explicit. It places server routes in server/api/, wires typed data fetching through useFetch and useAsyncData with proper caching, and keeps client state in Pinia. By naming your real [api_endpoints] and [orm], you get a template shaped to your data model rather than a generic starter, complete with nuxt.config.ts, an .env.example, and Docker setup. SEO is handled through useHead, useSeoMeta, and OG image generation so public pages are discoverable.
When to use it
- Starting a Nuxt 3 project that needs both marketing pages and an authenticated dashboard
- Wanting the API, auth, and database in one deployable codebase instead of a separate backend
- Standing up authentication with
[auth_method](OAuth plus email/password) quickly - Integrating an
[orm]like Drizzle with migrations from day one - Needing SEO wired in via useHead, useSeoMeta, and OG image generation
- Preparing a deployment config for
[deploy_target]with environment variables and Docker
Example output
You get a project template: a directory layout with auto-imports, layouts and middleware; server routes implementing your [api_endpoints]; auth wiring for [auth_method]; [orm] setup with migrations; useFetch and useAsyncData examples with caching; Pinia stores for client state; SEO meta and OG image config; [ui_lib] components; auth-guard, rate-limit and validation middleware; and deployment files (nuxt.config.ts, .env.example, Dockerfile) targeting [deploy_target], all in TypeScript strict mode.
Pro tips
- List
[api_endpoints]as concrete resources (auth, users CRUD, projects CRUD) so the server routes match your domain rather than placeholders - Match
[orm]and its database; Drizzle with PostgreSQL and Prisma with MySQL imply different migration and query patterns - Choose
[auth_method]deliberately — OAuth plus email/password covers most apps, but pure OAuth or magic links change the middleware - Set
[deploy_target]to where you actually ship (Vercel, a VPS, a container host) because it shapes the env and Docker config - Keep
[app_type]specific so the AI knows whether to emphasise public marketing pages, the dashboard, or both - Lean on useFetch and useAsyncData caching for server-rendered data so the dashboard and marketing pages don't refetch needlessly
- Treat the generated Docker and deployment files as a starting point, then test a real build against your target before relying on them
