CLAUDE.md TemplatesCLAUDE.md Template

CLAUDE.md Template: Next.js 16 + Neon Serverless Postgres + Clerk Auth + Drizzle ORM Pipeline

CLAUDE.md Template for Next.js 16 with Neon Serverless Postgres, Clerk Auth, and Drizzle ORM. Includes a copyable CLAUDE.md template for production-ready pipeline.

CLAUDE.md TemplateNext.js 16Neon Serverless PostgresClerk AuthDrizzle ORMClaude Codepipelinefull-stackNext.js 16 app routerserverless

Target User

Developers building Next.js 16 apps with Neon Serverless Postgres, Clerk Auth, and Drizzle ORM

Use Cases

  • Bootstrapping a Next.js 16 project with serverless Postgres
  • Integrating Clerk authentication
  • Using Drizzle ORM for database access
  • Defining a Claude Code pipeline for deployment

Markdown Template

CLAUDE.md Template: Next.js 16 + Neon Serverless Postgres + Clerk Auth + Drizzle ORM Pipeline

# CLAUDE.md

Project role: You are a Production Engineer who designs and enforces a Next.js 16 + Neon Serverless Postgres + Clerk Auth + Drizzle ORM pipeline with Claude Code. Produce precise, copyable code blocks and configuration scripts.

Architecture rules:
- Use Next.js 16 app router with server components where appropriate; isolate client components behind Clerk auth checks.
- Centralize DB access via Drizzle ORM. Do not use raw SQL in app layer except for advanced migrations.
- Use a single Neon Serverless Postgres DSN from environment variables (NEON_DATABASE_URL).
- Authentication must be handled by Clerk; protect API routes with Clerk middleware.
- All data access must be type-safe via Drizzle models and TypeScript types.
- Expose only necessary APIs; minimize surface area in API routes.

File structure rules:
- Place application code under app/ for Next.js 16.
- Place database schema and drizzle setup under drizzle/.
- Place shared utilities under lib/.
- Do not include legacy Prisma or Mongoose configs.

Authentication rules:
- Use Clerk's Next.js SDK; protect pages and API routes with the <ClerkProvider> and withServerSideAuth where needed.
- Do not place private Clerk keys in client code; retrieve them from environment variables at build time.

Database rules:
- Use Drizzle ORM models for all data access.
- Migrate with drizzle migrate; do not run raw migrations from application code.
- Use parameterized queries; never interpolate user input into SQL strings.

Validation rules:
- Validate inputs with zod schemas; export inferred TS types for API handlers.
- Sanitize all user input before persistence.

Security rules:
- Store secrets in environment variables; never check them into git.
- Use HTTPOnly cookies for sessions; enforce CSRF protection where applicable.
- Enable TLS in deployment; disable verbose error messages in production.

Testing rules:
- Unit test API handlers with Vitest; mock Clerk and DB calls.
- Integration tests for data layer using an in-memory or test Neon database.
- Include end-to-end tests that cover auth flows and key business paths.

Deployment rules:
- Deploy to a serverless host (e.g., Vercel) with environment variables NEON_DATABASE_URL, CLERK_FRONTEND_API, CLERK_API_KEY, NEXTAUTH_URL, and any secrets.
- Use CI to run tests on PRs; ensure type-safety and lint checks pass before merge.

Things Claude must not do:
- Do not bypass Clerk authentication checks.
- Do not expose database credentials in client-side code.
- Do not generate unsafe SQL via string concatenation.
- Do not configure Prisma or Mongoose in this project.
- Do not hard-code production secrets.

Overview

What is this CLAUDE.md template? It is a copyable Claude Code blueprint for building a production-grade Next.js 16 app using Neon Serverless Postgres, Clerk authentication, and Drizzle ORM. It provides a complete pipeline layout and implementation constraints that you can paste into a CLAUDE.md file to drive code generation, reviews, and deployment.

Stack coverage: Next.js 16 app router, Neon Serverless Postgres, Clerk authentication, Drizzle ORM, and a serverless deployment pipeline.

Direct answer: This CLAUDE.md template delivers a ready-to-paste instruction block plus a structured project layout and rules to implement a secure, scalable full-stack flow with the specified stack.

When to Use This CLAUDE.md Template

  • You are starting a new Next.js 16 project that targets Neon Serverless Postgres for the database.
  • You require Clerk-based authentication integrated into a TypeScript Next.js app.
  • You want to use Drizzle ORM for database access with a clean schema layer.
  • You need an opinionated, copyable CLAUDE.md template to enforce architecture and deployment rules.

Copyable CLAUDE.md Template

# CLAUDE.md

Project role: You are a Production Engineer who designs and enforces a Next.js 16 + Neon Serverless Postgres + Clerk Auth + Drizzle ORM pipeline with Claude Code. Produce precise, copyable code blocks and configuration scripts.

Architecture rules:
- Use Next.js 16 app router with server components where appropriate; isolate client components behind Clerk auth checks.
- Centralize DB access via Drizzle ORM. Do not use raw SQL in app layer except for advanced migrations.
- Use a single Neon Serverless Postgres DSN from environment variables (NEON_DATABASE_URL).
- Authentication must be handled by Clerk; protect API routes with Clerk middleware.
- All data access must be type-safe via Drizzle models and TypeScript types.
- Expose only necessary APIs; minimize surface area in API routes.

File structure rules:
- Place application code under app/ for Next.js 16.
- Place database schema and drizzle setup under drizzle/.
- Place shared utilities under lib/.
- Do not include legacy Prisma or Mongoose configs.

Authentication rules:
- Use Clerk's Next.js SDK; protect pages and API routes with the  and withServerSideAuth where needed.
- Do not place private Clerk keys in client code; retrieve them from environment variables at build time.

Database rules:
- Use Drizzle ORM models for all data access.
- Migrate with drizzle migrate; do not run raw migrations from application code.
- Use parameterized queries; never interpolate user input into SQL strings.

Validation rules:
- Validate inputs with zod schemas; export inferred TS types for API handlers.
- Sanitize all user input before persistence.

Security rules:
- Store secrets in environment variables; never check them into git.
- Use HTTPOnly cookies for sessions; enforce CSRF protection where applicable.
- Enable TLS in deployment; disable verbose error messages in production.

Testing rules:
- Unit test API handlers with Vitest; mock Clerk and DB calls.
- Integration tests for data layer using an in-memory or test Neon database.
- Include end-to-end tests that cover auth flows and key business paths.

Deployment rules:
- Deploy to a serverless host (e.g., Vercel) with environment variables NEON_DATABASE_URL, CLERK_FRONTEND_API, CLERK_API_KEY, NEXTAUTH_URL, and any secrets.
- Use CI to run tests on PRs; ensure type-safety and lint checks pass before merge.

Things Claude must not do:
- Do not bypass Clerk authentication checks.
- Do not expose database credentials in client-side code.
- Do not generate unsafe SQL via string concatenation.
- Do not configure Prisma or Mongoose in this project.
- Do not hard-code production secrets.
  

Recommended Project Structure

.
├── app/
│   ├── layout.tsx
│   ├── page.tsx
│   ├── globals.css
│   └── api/
│       └── auth/
│           └── route.ts
├── components/
│   ├── Navbar.tsx
│   └── Provider.tsx
├── drizzle/
│   ├── index.ts
│   ├── schema.ts
│   └── migrations/
├── lib/
│   ├── db.ts
│   └── drizzle.ts
└── drizzle.config.ts

Core Engineering Principles

  • Explicit type-safety and thorough validation with zod and Drizzle types.
  • Clear separation of concerns: app layer, data layer, and auth layer.
  • Environment-driven configuration and 12-factor principles.
  • Automated tests for API, data access, and deployment.
  • Security-by-default: least privilege, CSRF protection, and TLS.

Code Construction Rules

  • Use Drizzle ORM for all DB access and migrations; never rely on string-interpolated SQL in code paths.
  • All API routes must be protected by Clerk middleware; unprotected routes are prohibited.
  • Use environment variables for secrets (NEON_DATABASE_URL, CLERK_API_KEY, etc.).
  • Do not commit database connection strings to git; use runtime fetch of secrets.
  • Validate and sanitize inputs with zod before hitting the data layer.

Security and Production Rules

  • Enable CSRF protection for state-changing requests.
  • Use HTTPOnly cookies and secure flags in all environments.
  • Serverless deployments must not leak stack traces in production.
  • Audit trails for authentication events and harmful input attempts should be available to operators.

Testing Checklist

  • Unit tests for Drizzle models and API handlers.
  • Integration tests for data access with a test Neon database or mocks.
  • End-to-end tests for Clerk auth flows and core UI paths.
  • CI must run type checks, lint, unit, and integration tests on PRs.

Common Mistakes to Avoid

  • Mixing client and server DB code; ensure DB access occurs on server side only where appropriate.
  • Using raw SQL in business logic without parameterization.
  • Hard-coding secrets or using insecure secret patterns.
  • Over-sharing data in API responses; always enforce authorization at the API boundary.

FAQ

Q: What is this CLAUDE.md Template for?
A: It provides a ready-to-paste blueprint for Next.js 16 with Neon Serverless Postgres, Clerk Auth, and Drizzle ORM, including architecture rules and deployment guidance.
Q: Which parts should I paste into CLAUDE.md?
A: The entire code block under Copyable CLAUDE.md Template plus the related project structure and rules sections you want to enforce.
Q: How do I configure Neon with Next.js?
A: Use NEON_DATABASE_URL in environment variables and connect via Drizzle to the database.
Q: How is authentication handled?
A: Clerk authentication is integrated through Clerk Next.js SDK and middleware for protected routes.
Q: What tests should I run?
A: Unit tests for data layer, integration tests against Neon, and E2E tests for auth and core features.