Cursor Rules Template for SvelteKit + Prisma Server Load Functions

Overview

The Cursor rules configuration is designed for a SvelteKit project using Prisma as the ORM with server load functions. This Cursor rules template provides a copyable .cursorrules configuration you can paste into your project root to govern AI-assisted development, data access, and server-side data hydration. It preserves a clear separation of concerns between server logic and client-facing code while keeping Cursor AI aligned with Prisma patterns.

Direct answer: Paste the included .cursorrules block at the repository root to activate stack-specific Cursor AI guidance for SvelteKit server load and Prisma interactions.

When to Use These Cursor Rules

• When implementing server-load data fetching in SvelteKit with Prisma and you want consistent data access controls.
• When you need deterministic, type-safe data hydration in routes and layout loading.
• When you want Cursor AI to produce code that follows Prisma patterns, server-only data access, and secure authentication flows.
• When your project requires automated testing and linting coverage for server-load driven code.

Copyable .cursorrules Configuration

# Cursor rules block for SvelteKit + Prisma server-load
framework: 'sveltekit'
stack: 'prisma'
context: 'server-load functions in SvelteKit with Prisma ORM'

rules:
  # Framework Role & Context
  role: 'You are Cursor AI assistant configuring server-load functions for SvelteKit + Prisma.'
  # Code Style and Style Guides
  style: 'TypeScript strict; ESLint + Prettier; TSConfig strict; noImplicitAny'
  # Architecture & Directory Rules
  architecture:
    rootDirs:
      - 'prisma/schema.prisma'
      - 'src/routes/**/+page.server.ts'
      - 'src/hooks.server.ts'
      - 'src/lib/db.ts'
  # Authentication & Security Rules
  auth:
    authenticity: 'Use cookie-based JWT, httpOnly, sameSite=Lax; CSRF tokens for mutating requests'
    access: 'Enforce user roles and data-scoping in load functions'
  # Database and ORM patterns
  prisma:
    client: 'Prisma'
    connection: 'PostgreSQL or SQLite for dev; migrations via prisma migrate'
    patterns:
      - 'use prisma client in server-load'
      - 'never expose prisma queries to the client'
  # Testing & Linting Workflows
  testing:
    unit: 'Vitest'
    integration: 'Playwright or Vitest with fetch mocks'
    lint: 'eslint --ext .ts,.js --fix; prettier --write'
  # Prohibited Actions and Anti-patterns
  prohibitions:
    - 'Do not perform client-only calls in server-load'
    - 'Do not use eval() or dynamic code execution'
    - 'Do not bypass authentication checks in load'
    - 'Do not return raw database rows; map to DTOs'
    - 'Do not rely on non-deterministic ordering in queries'
  # Cursor behavior
  cursorFor: 'server-load-sveltekit-prisma'
  sentinel: 'Ensure deterministic caching'

Recommended Project Structure

project-root/
├─ prisma/
│  └─ schema.prisma
├─ src/
│  ├─ routes/
│  │  ├─ +layout.server.ts
│  │  └─ +page.server.ts
│  │  └─ api/
│  │     └─ [endpoint].ts
│  ├─ lib/
│  │  └─ db.ts
│  ├─ hooks.server.ts
│  └─ app.html
├─ tests/
│  ├─ unit/
│  └─ integration/
└─ package.json

Core Engineering Principles

• Explicit server-side data access with typed APIs and strict boundaries between server and client.
• Single source of truth for Prisma queries and data transformation into DTOs.
• Deterministic behavior in server load, with clear caching and memoization policies.
• Type-safe, testable code with comprehensive error handling and observability.
• Security by default: sanitize inputs, validate sessions, and protect secrets via environment variables.

Code Construction Rules

• Implement data fetching in src/routes/+page.server.ts and related +layout.server.ts using Prisma client; never access the database from client code.
• Return only sanitized, strongly-typed data to the client; map database rows to DTOs before sending.
• Enable strict TypeScript checks (strict: true) and keep tsconfig.json aligned with Prisma types.
• Keep Cursor AI prompts in the repository root and reference them from scripts or hooks as needed.
• Follow an explicit error-handling strategy; convert runtime errors to structured JSON responses with status codes.

Security and Production Rules

• Store database credentials and API secrets in environment variables; never commit them.
• Use httpOnly, secure, sameSite cookies for authentication; implement CSRF protection for state-changing requests.
• Validate user input server-side; enforce data-access boundaries by user context in server-load.
• Enable TLS, configure rate limiting, and maintain audit logs for sensitive endpoints.
• Do not expose Prisma queries or internal identifiers to the client.

Testing Checklist

• Unit tests for Prisma query helpers and DTO mappers.
• Integration tests for server-load endpoints covering authorized and unauthorized access.
• End-to-end tests for authentication flows and data hydration via server load.
• Linting and type-checking in CI; ensure Prettier formatting on commit.

Common Mistakes to Avoid

• Relying on client-provided data in server-load handlers without validation.
• Exposing Prisma queries directly to the client or skipping access checks.
• Neglecting error handling and mapping errors to meaningful HTTP responses.
• Skipping migrations or using unsafe raw SQL in schemas.

FAQ

What is a Cursor Rules Template for SvelteKit + Prisma?

A Cursor Rules Template provides a copyable .cursorrules configuration that guides Cursor AI to generate safe, stack-specific server-load code for a SvelteKit app using Prisma. It enforces architecture, authentication, testing, and security practices tailored to this stack.

How do I apply the .cursorrules configuration?

Copy the block from the Copyable section into the project root as .cursorrules. Then run your usual code generation or linting workflow to align AI-generated code with the rules, architecture, and security constraints described.

Which stack elements are covered by these rules?

The rules cover SvelteKit server load functions, Prisma ORM usage, TypeScript strictness, server-side data fetching patterns, authentication, testing, and production security practices.

Can I adapt the rules for different databases?

Yes. The configuration specifies Prisma usage and migrations, and you can adjust the Prisma client connection details for PostgreSQL, SQLite, or other supported databases, while maintaining safe server-side access patterns.

What testing strategies are recommended?

Use Vitest for unit tests, and Playwright or Vitest for integration and end-to-end tests. Include tests for data access boundaries in server-load and verify authentication and error handling paths.