Restaurant-Clinic-Retail Shift Scheduler Cursor Rules Template

Overview

Direct answer: This Cursor rules template defines guardrails for Cursor AI to generate and enforce code and configurations for a multi-tenant shift scheduling SaaS that serves restaurants, clinics, and retail teams. It focuses on availability collection, shift creation, and real-time notifications, using a Node.js + Express backend with PostgreSQL and Redis for notifications.

When to Use These Cursor Rules

Starting a new multi-tenant shift scheduler project for restaurants, clinics, or retail teams.
Enforcing tenant isolation and RBAC across tenants and roles.
Standardizing the data model for shifts, availabilities, assignments, and notifications.
Guiding safe AI-assisted code generation and configuration with Cursor AI rules.
Integrating availability and notification workflows with a PostgreSQL backend.

Copyable .cursorrules Configuration

Framework: Node.js + Express API
Context: You are a backend engineer building a multi-tenant shift scheduling SaaS for restaurants, clinics, and retail teams with availability and notifications. Use Cursor AI to enforce safe patterns and to draft code and configs.

Role: Backend Engineer
CodeStyle: TypeScript, ESLint + Prettier, strict mode, no implicit any
Architecture: Monorepo with modules api, domain, infra; Multi-tenant isolation at schema level; separation of concerns
DirectoryRules: /src/api, /src/domain, /src/infra, /src/utils, /tests
Authentication: JWT with short-lived access tokens; RBAC per tenant; refresh tokens stored in httpOnly cookies
Security: Input validation, CSRF protection, rate limiting, secure headers
Database: PostgreSQL; parameterized queries; transactions; avoid N+1 queries
ORM: None; use pg with prepared statements; simple repositories
Testing: Jest for unit tests; integration tests for DB; lint and type checks in CI
Prohibited: Do not use Prisma, Mongoose, Drizzle; do not bypass auth or credentials; avoid dynamic SQL string concatenation

Recommended Project Structure

restaurant-shift-scheduler/
  server/
    src/
      api/
        controllers/
        routes/
      domain/
        models/
        services/
      infra/
        db/
        notifier/
      config/
  migrations/
  tests/

Core Engineering Principles

Data correctness, auditability, and clear tenant isolation
Strong input validation and RBAC across tenants
Defensive coding with explicit error handling
Idempotent shift and notification operations
Observability, tracing, and structured logging
Safe AI integration with Cursor rules to guide generation

Code Construction Rules

Use TypeScript with strict mode and noImplicitAny
Export named modules and avoid default exports where possible
Prefer parameterized SQL and repository pattern for data access
All API routes must return consistent schemas and status codes
Tenant-aware data access: include tenantId in all queries
Avoid hard-coded credentials; pull config from environment variables
Do not bypass authentication; validate JWT on every protected endpoint
Test coverage: unit tests for services, integration tests for DB queries

Security and Production Rules

Use TLS for all traffic; enforce secure cookies for tokens
JWT access tokens with short expiry; refresh tokens stored in httpOnly cookies
Role-based access control and per-tenant scoping
Rate limiting, input validation, and CSRF protection
Audit logging for create/update/delete operations
Encrypt sensitive data at rest where applicable
Automated backups and immutable migration history

Testing Checklist

Unit tests for services and utilities
Integration tests for database access and transactions
End-to-end tests for major user flows (shift creation, availability, notifications)
Linting and TypeScript type checks in CI
Migration verification and rollback tests
Health checks and canary deployment readiness

Common Mistakes to Avoid

Assuming single-tenant data can be shared across tenants
Relying on an ORM when you need fine-grained SQL control
Ignoring time zone correctness in schedule calculations
Under- or over-notifying users; missing retry logic
Entering unsafe SQL or bypassing RBAC checks

Related Cursor rules templates

Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.

FAQ

What is a Cursor Rules Template for a shift scheduler?

A Cursor Rules Template defines guardrails and configuration to guide Cursor AI in generating safe, stack-specific code and patterns for a multi-tenant shift scheduler focused on availability and notifications.

Which stack does this template target?

The template targets a Node.js + Express backend with TypeScript, PostgreSQL for data persistence, and Redis for notification workflows, guided by Cursor AI rules to ensure security and testability.

Can the template support multi-tenant isolation?

Yes. It provides tenant-aware data models and RBAC to isolate data per tenant, ensuring shifts, availabilities, and notifications stay within the tenant boundary.

How are notifications handled?

Notifications are defined to trigger on shifts changes or availability updates and are delivered via email, SMS, or push with retry logic and observability hooks.

How do I apply the .cursorrules block?

Copy the raw .cursorrules block into a file named .cursorrules at your project root and run Cursor AI tooling to apply the rules and scaffold code for your stack.

Target User

Use Cases