Cursor Rules Template: Onboarding Platform for New Employees with Checklists, Training Materials, Documents and Reminders

Overview

The Cursor rules configuration provides a comprehensive, copyable set of operational and security guidelines for building an onboarding platform for new employees. This template targets a Next.js (app router) + TypeORM + PostgreSQL stack, delivering checklists, training materials, documents, and automated reminders.

Direct answer: Use these Cursor rules to lock in architecture, data models, auth, and CI/CD decisions, so development remains consistent and safe while delivering onboarding features quickly with Cursor AI.

When to Use These Cursor Rules

• When starting a new onboarding portal that requires checklists, training modules, and document management.
• When you need to align frontend routes with backend ORM entities and DB migrations.
• When you want consistent security, testing, and deployment pipelines across the stack.
• When you require repeatable, audit-friendly onboarding workflows and reminders.

Copyable .cursorrules Configuration

.cursorrules
Framework Role & Context:
- You are an expert builder of onboarding platforms using Next.js (with app router) and TypeORM for PostgreSQL. Your task is to ensure a secure, scalable, and testable onboarding system for new employees with checklists, training materials, documents, and reminders.

Code Style and Style Guides:
- Use TypeScript, strict TSConfig, and ESLint with recommended rules. Format code with Prettier. Follow a 2-spaces indent, semicolon-delimited statements, and meaningful variable names.
- Use clean architecture with layers: api (server), domain (logic), data (DB models), and UI components.

Architecture & Directory Rules:
- Root: /src with subfolders: /src/pages or /src/app, /src/components, /src/lib, /src/domain, /src/data, /src/migrations.
- API routes under /src/pages/api or /src/app/api.
- Entities for onboarding include: Employee, Checklist, TrainingMaterial, Document, Reminder.
- Migrations must be under /src/migrations and be run via a CLI script.
- Use a dedicated DB connection module that exports a single getConnection function.

Authentication & Security Rules:
- Use HTTP-only cookies for JWT tokens; implement CSRF protection.
- Do not store JWTs in localStorage or expose secrets in client code.
- Enforce role-based access: Admin, HR, Employee; check permissions on each endpoint.
- Use HTTPS in all environments; enable secure cookies and proper SameSite policy.

Database and ORM patterns:
- PostgreSQL as the primary DB.
- TypeORM entities: Employee, Checklist, TrainingMaterial, Document, Reminder; define relations: Employee has many Checklists; Checklist has many TrainingMaterials; Reminder belongs to Employee.
- Use migrations for schema changes; seed data through a dedicated seed script.

Testing & Linting Workflows:
- Tests: Jest + React Testing Library for UI; integration tests for API endpoints with supertest.
- Lint with ESLint; format with Prettier; run tests in CI on push/PR.

Prohibited Actions and Anti-patterns for the AI:
- Do not hardcode secrets; do not bypass authentication; do not use server-side anti-patterns such as direct DB calls from UI code.
- Do not generate non-deterministic IDs on client; avoid mixed concerns across UI and data layers.
- Do not rely on client-side rendering alone for sensitive onboarding steps.

Recommended Project Structure

onboarding-app/
├── src/
│   ├── components/                 # Reusable UI pieces
│   │   ├── ChecklistCard.tsx
│   │   ├── TrainingTile.tsx
│   │   └── DocumentItem.tsx
│   ├── pages/                     # Next.js pages (or app router equivalents)
│   │   ├── index.tsx
│   │   └── api/
│   │       ├── onboarding.ts
│   │       └── reminders.ts
│   ├── lib/                       # Helpers (auth, i18n, etc.)
│   │   └── auth.ts
│   ├── data/                      # DB entities and DTOs
│   │   ├── entities/
│   │   │   ├── Employee.ts
│   │   │   ├── Checklist.ts
│   │   │   ├── TrainingMaterial.ts
│   │   │   ├── Document.ts
│   │   │   └── Reminder.ts
│   │   └── dtos/
│   ├── migrations/                # SQL/typeorm migrations
│   │   └── 0001-initial-schema.ts
│   └── config/                    # env-based config
│       └── database.ts
└── tests/                         # Jest tests

Core Engineering Principles

• Clear boundaries between API, domain logic, and data persistence.
• Type safety and explicit interfaces for all onboarding data models.
• Idempotent migrations and reproducible seeds for onboarding data.
• Secure authentication with HTTP-only cookies and RBAC.
• Test-driven approach with unit and integration tests for API and UI.
• Observability via structured logs and metrics for reminders and tasks.

Code Construction Rules

• All endpoints must validate input using zod or class-validator with clear error messages.
• Use strong types for all API payloads; never rely on anyImplicit any.
• All DB access must go through a single repository layer; avoid direct queries in UI code.
• Folder structure must mirror the architecture guidance above; do not flatten for convenience.
• API routes should enforce RBAC checks; unauthorized requests must return 403 with a generic message.
• Reminders should be scheduled via a queue/system daemon; do not rely on client-side timers for due dates.

Security and Production Rules

• Enable HTTPS and secure cookies; set SameSite=Strict for sensitive tokens.
• Store DB credentials in environment variables; avoid exposing them in client bundles.
• Audit logs for onboarding actions; redact PII where not necessary on logs.
• Rotate keys and tokens periodically; implement token revocation lists for sessions.
• Use parameterized queries or ORM safeguards to prevent SQL injection.

Testing Checklist

• Unit tests for domain logic (checklists, trainings, documents, reminders).
• API integration tests covering authentication, onboarding flow, and reminder triggers.
• End-to-end tests simulating a new hire onboarding path from signup to completion.
• CI: lint, type checks, tests; CD: deploy to staging with migrations applied.

Common Mistakes to Avoid

• Skipping migrations or bypassing type safety for onboarding data models.
• Using client-side timers for reminders; rely on server-side scheduling instead.
• Ignoring RBAC; exposing onboarding materials publicly.
• Overloading the API with business logic; keep controllers thin.

Related Cursor rules templates

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

• Cursor Rules Template: Policy Management with Versioning (Node.js, Express, PostgreSQL)
• Cursor Rules Template: Client Onboarding Portal with Forms, Uploads, E-Sign and Admin Dashboards
• Physiotherapy Practice Management Cursor Rules Template for Cursor AI
• Cursor Rules Template: NestJS + Next.js + PostgreSQL for B2B Wholesale Portal

FAQ

What stack is this Cursor Rules Template designed for?

This Cursor Rules Template targets a Next.js (app router) + TypeORM + PostgreSQL onboarding app for new employees with checklists, trainings, documents, and reminders. It provides a copyable .cursorrules block and stack-specific guidance to accelerate safe development.

Can I adapt for other databases?

Yes. Adjust entities and migrations for your DB. The rest of the architecture and Cursor rules remain applicable with RBAC and proper security.

How are reminders scheduled?

Reminders are pushed to a server-side queue or background worker and persisted in the Reminders table. Clients fetch due reminders and render them; avoid client-only timers for reliability.

How is security enforced in this template?

Security relies on HTTP-only cookies for tokens, RBAC checks on API endpoints, and encrypted environment variables for credentials. Never expose secrets in client code, and enforce HTTPS in all environments.

What tests should I start with?

Begin with unit tests for domain logic (checklists, trainings, documents, reminders), API integration tests for onboarding flows, and UI tests for critical components, followed by end-to-end tests of a full onboarding run.

Where do I customize onboarding data?

Customize in /src/data/entities and /src/migrations for schema changes, with seed scripts under /src/migrations or /scripts. Keep seed data aligned with real-world onboarding workflows to keep tests deterministic.