CLAUDE.md TemplatesTemplate

Nuxt 4 + MariaDB + Stytch Auth + Sequelize ORM - CLAUDE.md Template

CLAUDE.md Template for Nuxt 4 + MariaDB + Stytch Auth + Sequelize ORM pipeline.

claude-md-templatenuxt-4mariadbstytchsequelizeclaude-codefull-stackbackendauthenticationweb-app

Target User

Developers building Nuxt 4 apps with MariaDB and Stytch authentication

Use Cases

  • Scaffold a Nuxt 4 frontend with server-side API endpoints
  • Configure Sequelize ORM with MariaDB
  • Integrate Stytch authentication flows
  • Provide a copyable CLAUDE.md template for Claude Code

Markdown Template

Nuxt 4 + MariaDB + Stytch Auth + Sequelize ORM - CLAUDE.md Template

Overview

\nCLAUDE.md template for Nuxt 4 + MariaDB + Stytch Auth + Sequelize ORM pipeline provides Claude Code instructions to scaffold a production-ready stack. It targets a server-driven Nuxt 4 app using Sequelize ORM to connect to MariaDB and Stytch for authentication.

\nDirect answer: This template gives a concise, copyable instruction block you can paste into Claude Code to generate the Nuxt 4 app, configure Sequelize with MariaDB, and wire Stytch authentication with secure defaults.

\n\nWhen to Use This CLAUDE.md Template

\n\n- You are building a Nuxt 4 frontend with a MariaDB backend accessed via Sequelize ORM.
\n- You require Stytch-based authentication flows (passwordless sign-in, session management) integrated into server endpoints.
\n- You want a reproducible structure and actionable Claude Code rules for code generation, validation, and deployment.
\n\n\nCopyable CLAUDE.md Template

\n# CLAUDE.md\n\n# Project Role\n- You are a Nuxt 4 full-stack engineer responsible for wiring a Nuxt 4 frontend (Nitro) with a MariaDB backend via Sequelize ORM, and integrating Stytch authentication in server routes and API handlers.\n\n# Architecture Rules\n- Use Nuxt 4 with Nitro for server routes.\n- Sequelize models live under server/db/models and migrations under server/db/migrations.\n- Authentication flows rely on Stytch tokens validated on the server, not in the client.\n- All database access must go through a repository/service layer with strict input validation.\n\n# File Structure Rules\n- Do not create files outside the recommended structure.\n- All API routes live under server/api.\n- Database config and models live under server/db/models and server/db/migrations.\n- Environment variables are loaded from .env and referenced via process.env.\n\n# Authentication Rules\n- Use Stytch for passwordless sign-in and session management.\n- Verify tokens on protected API routes.\n- Do not expose secret keys to the client.\n\n# Database Rules\n- Use MariaDB (MySQL-compatible) with Sequelize.\n- Connection string and credentials come from environment variables (DB_HOST, DB_USER, DB_PASSWORD, DB_NAME, DB_PORT).\n- Use parameterized queries via Sequelize to prevent SQL injection.\n\n# Validation Rules\n- Validate all inputs at the API boundary with lightweight validation (e.g., Joi or class-validator compatible patterns).\n- Normalize user input (trim, lowercase emails where appropriate).\n\n# Security Rules\n- Do not store plaintext passwords; use Stytch session management.\n- Enable CSRF protection on server routes; configure CORS appropriately.\n- Do not log sensitive payloads in production logs.\n\n# Testing Rules\n- Unit test Sequelize models and utility services.\n- Integration test authentication flows with Stytch sandbox credentials.\n- E2E tests cover login, protected routes, and logout flows.\n\n# Deployment Rules\n- Provide Nuxt 4 build for production and set proper environment variables in the deployment environment.\n- Run migrations as part of deployment.\n- Secrets must be supplied through environment variables, not embedded in code.\n\n# Things Claude Must Not Do\n- Do not generate or expose production secrets in code blocks.\n- Do not bypass authentication checks.\n- Do not use unsafe eval-like constructs or dynamic imports without safeguards.\n\n\nRecommended Project Structure

\nnuxt-app/\n├── nuxt.config.ts\n├── package.json\n├── .env\n├── app/\n├── components/\n├── composables/\n├── plugins/\n├── middleware/\n├── server/\n│   ├── api/\n│   │   ├── auth/\n│   │   │   └── index.ts\n│   │   └── users/\n│   │       └── index.ts\n│   └── db/\n│       ├── index.js\n│       ├── models/\n│       │   ├── user.js\n│       │   └── session.js\n│       └── migrations/\n│           ├── 20240501-create-user.js\n│           └── 20240502-create-session.js\n├── sequelize/\n│   └── config.js\n\n\nCore Engineering Principles

\n\n- Clear separation of concerns between frontend, API, and database layers.
\n- Type-safe boundaries across Nuxt 4, Sequelize models, and auth flows.
\n- Fail-fast with strict input validation and meaningful error handling.
\n- Security-first defaults: environment-based configuration, CSRF protection, and token verification.
\n- Reproducible builds and deterministic migrations for database schema.
\n\n\nCode Construction Rules

\n\n- Use TypeScript for Nuxt 4 and server code; ensure strict type checks.
\n- Centralize configuration in environment variables and Nuxt runtimeConfig.
\n- Models and database access must go through a repository/service layer.
\n- API endpoints must validate input and sanitize outputs; never trust client input.\n\n\nSecurity and Production Rules

\n\n- Store all secrets in environment variables; use a secret manager in production where possible.
\n- Enable CSRF protection and proper CORS policies on API routes.
\n- Validate Stytch tokens server-side and enforce session-based access control for protected routes.
\n\n\nTesting Checklist

\n\n- Unit tests for Sequelize models and data validation logic.
\n- Integration tests for API endpoints and auth flows with Stytch sandbox.
\n- End-to-end tests covering login, protected routes, and logout scenarios.
\n- Migration regression tests to ensure database schema integrity after upgrades.
\n\n\nCommon Mistakes to Avoid

\n\n- Embedding credentials directly in code or CLI scripts.
\n- Bypassing server-side authentication checks.
\n- Using client-side validation as a sole guard for security-critical paths.
\n\n\nFAQ

\n\n- What is this CLAUDE.md Template for Nuxt 4 + MariaDB + Stytch + Sequelize? 
A copyable CLAUDE.md template guiding Claude Code to scaffold Nuxt 4 with MariaDB via Sequelize and Stytch authentication.
\n- Which stack is covered by this template? 
Nuxt 4 (Nitro) frontend, MariaDB backend via Sequelize, and Stytch authentication.
\n- How do I customize the MariaDB connection? 
Configure via environment variables (DB_HOST, DB_USER, DB_PASSWORD, DB_NAME, DB_PORT) and runtime config; do not hard-code credentials.
\n- What should Claude not do in this template? 
Do not bypass authentication checks, expose secrets, or perform unsafe dynamic code execution.
\n- How do I run tests for this template? 
Run unit tests for models/services, integration tests for auth, and end-to-end tests for login and protected routes.
\n

Overview

\n

CLAUDE.md template for Nuxt 4 + MariaDB + Stytch Auth + Sequelize ORM pipeline provides Claude Code instructions to scaffold a production-ready stack. It targets a server-driven Nuxt 4 app using Sequelize ORM to connect to MariaDB and Stytch for authentication.

\n

Direct answer: This template gives a concise, copyable instruction block you can paste into Claude Code to generate the Nuxt 4 app, configure Sequelize with MariaDB, and wire Stytch authentication with secure defaults.

\n\n

When to Use This CLAUDE.md Template

\n
    \n
  • You are building a Nuxt 4 frontend with a MariaDB backend accessed via Sequelize ORM.
  • \n
  • You require Stytch-based authentication flows (passwordless sign-in, session management) integrated into server endpoints.
  • \n
  • You want a reproducible structure and actionable Claude Code rules for code generation, validation, and deployment.
  • \n
\n\n

Copyable CLAUDE.md Template

\n
# CLAUDE.md\n\n# Project Role\n- You are a Nuxt 4 full-stack engineer responsible for wiring a Nuxt 4 frontend (Nitro) with a MariaDB backend via Sequelize ORM, and integrating Stytch authentication in server routes and API handlers.\n\n# Architecture Rules\n- Use Nuxt 4 with Nitro for server routes.\n- Sequelize models live under server/db/models and migrations under server/db/migrations.\n- Authentication flows rely on Stytch tokens validated on the server, not in the client.\n- All database access must go through a repository/service layer with strict input validation.\n\n# File Structure Rules\n- Do not create files outside the recommended structure.\n- All API routes live under server/api.\n- Database config and models live under server/db/models and server/db/migrations.\n- Environment variables are loaded from .env and referenced via process.env.\n\n# Authentication Rules\n- Use Stytch for passwordless sign-in and session management.\n- Verify tokens on protected API routes.\n- Do not expose secret keys to the client.\n\n# Database Rules\n- Use MariaDB (MySQL-compatible) with Sequelize.\n- Connection string and credentials come from environment variables (DB_HOST, DB_USER, DB_PASSWORD, DB_NAME, DB_PORT).\n- Use parameterized queries via Sequelize to prevent SQL injection.\n\n# Validation Rules\n- Validate all inputs at the API boundary with lightweight validation (e.g., Joi or class-validator compatible patterns).\n- Normalize user input (trim, lowercase emails where appropriate).\n\n# Security Rules\n- Do not store plaintext passwords; use Stytch session management.\n- Enable CSRF protection on server routes; configure CORS appropriately.\n- Do not log sensitive payloads in production logs.\n\n# Testing Rules\n- Unit test Sequelize models and utility services.\n- Integration test authentication flows with Stytch sandbox credentials.\n- E2E tests cover login, protected routes, and logout flows.\n\n# Deployment Rules\n- Provide Nuxt 4 build for production and set proper environment variables in the deployment environment.\n- Run migrations as part of deployment.\n- Secrets must be supplied through environment variables, not embedded in code.\n\n# Things Claude Must Not Do\n- Do not generate or expose production secrets in code blocks.\n- Do not bypass authentication checks.\n- Do not use unsafe eval-like constructs or dynamic imports without safeguards.\n
\n\n

Recommended Project Structure

\n
nuxt-app/\n├── nuxt.config.ts\n├── package.json\n├── .env\n├── app/\n├── components/\n├── composables/\n├── plugins/\n├── middleware/\n├── server/\n│   ├── api/\n│   │   ├── auth/\n│   │   │   └── index.ts\n│   │   └── users/\n│   │       └── index.ts\n│   └── db/\n│       ├── index.js\n│       ├── models/\n│       │   ├── user.js\n│       │   └── session.js\n│       └── migrations/\n│           ├── 20240501-create-user.js\n│           └── 20240502-create-session.js\n├── sequelize/\n│   └── config.js\n
\n\n

Core Engineering Principles

\n
    \n
  • Clear separation of concerns between frontend, API, and database layers.
  • \n
  • Type-safe boundaries across Nuxt 4, Sequelize models, and auth flows.
  • \n
  • Fail-fast with strict input validation and meaningful error handling.
  • \n
  • Security-first defaults: environment-based configuration, CSRF protection, and token verification.
  • \n
  • Reproducible builds and deterministic migrations for database schema.
  • \n
\n\n

Code Construction Rules

\n
    \n
  • Use TypeScript for Nuxt 4 and server code; ensure strict type checks.
  • \n
  • Centralize configuration in environment variables and Nuxt runtimeConfig.
  • \n
  • Models and database access must go through a repository/service layer.
  • \n
  • API endpoints must validate input and sanitize outputs; never trust client input.\n
\n\n

Security and Production Rules

\n
    \n
  • Store all secrets in environment variables; use a secret manager in production where possible.
  • \n
  • Enable CSRF protection and proper CORS policies on API routes.
  • \n
  • Validate Stytch tokens server-side and enforce session-based access control for protected routes.
  • \n
\n\n

Testing Checklist

\n
    \n
  • Unit tests for Sequelize models and data validation logic.
  • \n
  • Integration tests for API endpoints and auth flows with Stytch sandbox.
  • \n
  • End-to-end tests covering login, protected routes, and logout scenarios.
  • \n
  • Migration regression tests to ensure database schema integrity after upgrades.
  • \n
\n\n

Common Mistakes to Avoid

\n
    \n
  • Embedding credentials directly in code or CLI scripts.
  • \n
  • Bypassing server-side authentication checks.
  • \n
  • Using client-side validation as a sole guard for security-critical paths.
  • \n
\n\n

FAQ

\n
    \n
  • What is this CLAUDE.md Template for Nuxt 4 + MariaDB + Stytch + Sequelize?
    A copyable CLAUDE.md template guiding Claude Code to scaffold Nuxt 4 with MariaDB via Sequelize and Stytch authentication.
  • \n
  • Which stack is covered by this template?
    Nuxt 4 (Nitro) frontend, MariaDB backend via Sequelize, and Stytch authentication.
  • \n
  • How do I customize the MariaDB connection?
    Configure via environment variables (DB_HOST, DB_USER, DB_PASSWORD, DB_NAME, DB_PORT) and runtime config; do not hard-code credentials.
  • \n
  • What should Claude not do in this template?
    Do not bypass authentication checks, expose secrets, or perform unsafe dynamic code execution.
  • \n
  • How do I run tests for this template?
    Run unit tests for models/services, integration tests for auth, and end-to-end tests for login and protected routes.
  • \n