CLAUDE.md Template for Next.js Security Review SaaS with Supabase, Clerk, Stripe

Overview

This CLAUDE.md template is a copyable Claude Code instruction block designed to guide building a complete Security Review SaaS using Next.js, TypeScript, Supabase, Clerk, Stripe, AI vulnerability summaries, dependency scanning, and remediation planning. It’s intentionally stack-specific and production-ready enough to paste into your CLAUDE.md file without modification. Direct answer: you’ll get a turnkey Claude Code block that encodes architecture, file layout, security posture, and testing in a single, reusable template.

When to Use This CLAUDE.md Template

• You are delivering a full-stack SaaS with a strong focus on security and vulnerability management.
• You need a pasted Claude Code template that enforces authentication, authorization, and secure data flows using Next.js, TypeScript, Supabase, Clerk, and Stripe.
• You require a ready-to-deploy project skeleton and precise rules for architecture, file layout, validation, and deployment.
• You want a reproducible blueprint for AI-assisted vulnerability summaries and remediation planning within a SaaS context.

Copyable CLAUDE.md Template

# CLAUDE.md

Project role:
- You are Claude, a software architect and developer relations engineer tasked with delivering production-ready code blocks for a complete Security Review SaaS using Next.js, TypeScript, Supabase, Clerk, Stripe, and AI vulnerability workflows.

Architecture rules:
- Build a monorepo with a Next.js frontend and serverless backend (Next.js API/Edge where appropriate).
- Supabase handles PostgreSQL and auth; Clerk handles user management and roles; Stripe handles billing.
- Frontend uses React with TypeScript; prefer server components where possible; avoid exposing secrets on the client.
- All AI capabilities (vulnerability summaries) run on a secure server path; never expose secrets to the client.
- Use environment-based feature flags for staging vs. production behavior.
- Prefer observable, testable functions with explicit inputs/outputs over implicit side effects.

File structure rules:
- apps/web as the Next.js app root
- apps/web/src for source code
- libs/ for shared types and utilities
- services/ for external clients: supabaseClient.ts, clerkClient.ts, stripeClient.ts
- ai/ for vulnerability summarization and remediation planning logic
- tests/ for unit/integration tests

Authentication rules:
- Clerk for user authentication; require sign-in for all core features
- Roles: admin, user; enforce access controls on data operations
- Use server components to fetch data and enforce authorization on the server side
- Do not expose API keys or secrets to the browser

Database rules:
- Supabase PostgreSQL with Row-Level Security (RLS) enabled
- Policies that scope data to the authenticated user or org, as appropriate
- Use UUIDs for IDs; ensure proper foreign key constraints
- Never accept direct SQL from the client; route DB access through server/API layers

Validation rules:
- Validate all inputs with strict TypeScript types; apply runtime validation with a schema library if available (e.g., zod)
- Normalize and sanitize all inputs from external systems (Stripe webhooks, etc.)

Security rules:
- Implement Content-Security-Policy and secure cookies; disable inline scripts where possible
- Validate Stripe webhooks with signature checks; store webhook events securely
- Audit sensitive changes; redact secrets in logs; implement rate limiting

Testing rules:
- Unit tests for business logic (AI vulnerability summarization, remediation planner)
- Integration tests for Supabase data flows and Clerk auth paths
- End-to-end tests for signup, login, feature flows, and billing via Stripe mocks
- CI should run lint, type checks, unit, integration, and E2E tests

Deployment rules:
- Deploy to a hosting platform with first-class Next.js support (e.g., Vercel)
- Configure environment variables securely; do not commit secrets
- Run database migrations on deploy; verify Stripe webhook endpoint and keys
- Enable monitoring and alerting for critical failures

Things Claude must not do:
- Do not bypass Clerk authentication or expose secret keys to the client
- Do not propose Prisma; use Supabase/SQL directly or with Supabase client
- Do not degrade security posture for convenience
- Do not enable broad, permissive CORS or insecure API endpoints

Recommended Project Structure

.
├── apps
│   └── web
│       ├── src
│       │   ├── app
│       │   │   ├── layout.tsx
│       │   │   ├── page.tsx
│       │   │   └── components
│       │   ├── lib
│       │   │   ├── supabaseClient.ts
│       │   │   ├── clerkClient.ts
│       │   │   └── stripeClient.ts
│       │   ├── services
│       │   │   ├── ai
│       │   │   └── billing
│       │   ├── hooks
│       │   └── styles
│       ├── next.config.js
│       ├── tsconfig.json
│       └── package.json
├── libs
│   ├── types
│   └── ui
├── ai
│   ├── vulnerabilitySummaries
│   └── remediationPlans
├── tests
│   ├── unit
│   ├── integration
│   └── e2e

Core Engineering Principles

• Security-by-default: enforce least privilege and server-side data access checks
• Explicit data contracts: TypeScript interfaces for all data shapes
• Observability: structured logging, tracing, and metrics from the front end to the DB
• Deterministic builds and reproducible deployments
• Separation of concerns: clear boundaries between auth, data access, and business logic

Code Construction Rules

• Use Next.js App Router with TS; keep server components for data operations
• Use Supabase client for all DB ops; enable RLS with strict policies
• Clerk should be the sole auth provider for user accounts; manage roles carefully
• Stripe integration must occur on the server; never perform billing actions on the client
• AI vulnerability summaries must run in a server context and not leak secrets
• All API routes must validate inputs, handle errors gracefully, and return deterministic error messages
• Use environment-based feature toggles for risky features
• Document all public endpoints and their expected inputs/outputs

Security and Production Rules

• Enable RLS on all tables; define policies by user/org ownership
• Use secure cookies, CSRF protection, and Content-Security-Policy
• Validate Stripe webhooks with signature verification; store only minimal webhook data
• Audit and redact sensitive data in logs; implement access logging
• Roll out rate limits and bot protection on API endpoints
• Run dependency scanning and vulnerability checks in CI

Testing Checklist

• Unit tests for vulnerability summarizer and remediation planner logic
• Integration tests for Supabase auth flows and CRUD operations
• End-to-end tests for signup, login, project creation, vulnerability reporting, and remediation plan generation
• CI: lint, type-check, unit, integration, and e2e tests; run security checks
• Deployment: smoke tests verifying web UI, auth, and billing flows

Common Mistakes to Avoid

• Exposing API keys or secrets in client code
• Skipping Row-Level Security policies on Supabase
• Handling Stripe webhooks insecurely or ignoring webhook verification
• Mixing server and client responsibilities in a way that leaks secrets

Related implementation resources: AI Use Case for Project Managers Using Ms Project To Identify The Critical Path and Simulate Project Delay Impacts and How skill files guide dependency choices for production AI workflows.

FAQ

What stack is this CLAUDE.md Template designed for?

Next.js with TypeScript, Supabase, Clerk, Stripe, and AI vulnerability workflows for a Security Review SaaS.

Can I paste this template into an existing CLAUDE.md?

Yes. It provides a complete, stack-specific CLAUDE.md block plus project structure recommendations.

How are AI vulnerability summaries generated securely?

All AI processing occurs server-side; no secrets are exposed to the client, and input validation is enforced before processing.

How do I handle authentication and authorization?

Clerk manages users and roles; access to data is protected by server-side checks and policy enforcement with Supabase RLS.

What about deployment and secrets?

Secrets are stored in environment variables; deployment requires secret management and webhook verification for Stripe.