Express-TypeScript Cursor Rules Template for Compliance Platform

Overview

This Cursor rules template provides a copyable .cursorrules block to accelerate building a compliance management platform on a Node.js/Express + TypeScript stack. It targets policies, controls, evidence, audits, and automated reminders, empowering Cursor AI to guide implementation with concrete rules and engineering constraints.

Direct answer: paste the included .cursorrules block into your project root to bootstrap a safe, auditable development process for compliance workflows.

When to Use These Cursor Rules

Starting a new compliance platform project with policies, controls, evidence tracking, and audits.
Enforcing architecture and coding standards across a TypeScript Express backend.
Automating reminders for audit windows, evidence submission, and control reviews.
Ensuring secure authentication, data handling, and logging practices from day one.

Copyable .cursorrules Configuration

# Cursor Rules Template for Express-TypeScript Compliance Platform
# Framework Role & Context
framework_role: Compliance Platform Engineer
context: Assist building a Node.js/Express backend in TypeScript for a policy-driven compliance platform with policies, controls, evidence, audits, and reminders.

# Code Style and Style Guides
style:
  language: TypeScript
  lint: eslint-config-airbnb-typescript
  formatter: prettier
  spec: strict
  maxLineLength: 120

# Architecture & Directory Rules
directories:
  - src/controllers
  - src/services
  - src/models
  - src/routes
  - src/middleware
  - src/db
  - src/policies
  - src/audits
  - src/evidence
  - tests
  - migrations

# Authentication & Security Rules
auth:
  methods:
    - JWT
    - OAuth2 (optional for integrations)
  tokenPlacement: header
  requireHTTPS: true
  jwtSecret: &jwtSecret ${JWT_SECRET}
  accessControl:
    - role admin
    - role auditor
    - role policy_owner
    - role evidence_manager

# Database and ORM patterns
db:
  engine: PostgreSQL
  orm: TypeORM
  migrations: true
  connectionPool: 15
  namingConventions: true

# Testing & Linting Workflows
testing:
  unit: jest
  integration: supertest
  endToEnd: cypress
  coverage: true
  lint: true

# Prohibited Actions and Anti-patterns for the AI
antiPatterns:
  - Do not bypass authentication checks or expose admin endpoints publicly
  - Do not generate raw SQL in controllers; use migrations and ORM models
  - Do not embed secrets in code or environment variables
  - Do not rely on client-side only validation for security-critical actions

Recommended Project Structure

project-root/
├─ src/
│  ├─ controllers/        # API endpoints
│  ├─ services/           # business logic
│  ├─ models/             # ORM entities
│  ├─ routes/             # express routers
│  ├─ middleware/         # auth, logging, validation
│  ├─ policies/           # policy definitions
│  ├─ evidence/           # evidence collection models
│  ├─ audits/             # audit records and reminders
│  ├─ db/                 # migrations, seed data, prisma-like wrappers
│  └─ config/             # env-based config
├─ tests/                 # unit/integration tests
├─ migrations/            # schema migrations
├─ .eslintrc.js
├─ .prettierrc
└─ tsconfig.json

Core Engineering Principles

Security-first by design: zero-trust habits, validated inputs, and signed tokens.
Explicit contracts between modules: clear APIs, typed interfaces, and strict validation.
Auditable by default: every change has a traceable author and timestamp.
Automated testing: unit, integration, and E2E coverage for critical paths.
Separation of concerns: policy logic, control catalogs, evidence, and audits isolated.

Code Construction Rules

Use TypeScript interfaces for request/response shapes and ORM entities.
Implement policy-driven guards for all sensitive routes; never rely on client data for authorization.
Store policy IDs, control IDs, and audit IDs as canonical integers with consistent naming.
Define migrations for any schema change and review before merging to main.
Keep business logic in services; controllers should delegate to services only.
Lint strictly and format on save; enforce pre-commit checks.

Security and Production Rules

Enforce HTTPS in all environments; disable non-TLS in prod.
JWT tokens for API access with short lifetimes and refresh tokens where appropriate.
Regularly rotate secrets; store in a vault or environment manager.
Audit logs must be immutable and retained for the defined retention window.
Input validation and output encoding to prevent injection attacks.

Testing Checklist

Unit tests for policy, control, and evidence models; mock DB interactions.
Integration tests for auth flows and critical endpoints (policies, audits, reminders).
End-to-end tests covering audit reminder workflows and evidence submission paths.
Lint and type-check as part of CI; ensure 80%+ coverage.
Security tests for token expiry, revocation, and access control boundaries.

Common Mistakes to Avoid

Mixing business logic with controllers; keep services pure and testable.
Hard-coding secrets or credentials in code or config files.
Skipping migrations; schema drift leads to outages in production.
Unvalidated external input propagating to critical security or compliance modules.

Related Cursor rules templates

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

FAQ

Why use a Cursor Rules Template for a compliance platform?

This template provides concrete, stack-specific rules for building a policy-driven system, ensuring secure authentication, proper ORM usage, and auditable workflows with policies, controls, evidence, and audits.

Which stack does this template target?

A Node.js/Express backend written in TypeScript with PostgreSQL (TypeORM), JWT-based authentication, and a folder structure suited for policy, control, evidence, and audit modules.

How do I use the included .cursorrules block?

Copy the block into your project root, adjust environment values for secrets and DB connections, and run your usual CI workflow to validate lint and type checks.

How can I extend the template for more modules?

Add new policy and control entities, extend routes and services, and perform migrations while preserving the existing structure and testing strategy.

What tests should I prioritize first?

Prioritize unit tests for policy and evidence models, integration tests for authentication and audit workflows, and end-to-end tests for reminder notifications to ensure the platform remains auditable end-to-end.

How do I ensure security in production?

Use HTTPS, rotate secrets, enforce short-lived tokens, implement role-based access controls, and maintain immutable audit logs. Validate inputs and implement secure defaults in all modules.

Target User

Use Cases