Cursor Rules Template: Multiplayer Whiteboard with Cursor AI

Overview

Direct answer: This Cursor Rules Template guides Cursor AI in implementing a production-ready, real-time multiplayer whiteboard stack with a React frontend, a Node backend using Socket.IO for real-time collaboration, and PostgreSQL for persistence. It codifies safe AI usage, coding standards, and integration patterns for canvas drawing, sticky notes, diagrams, and board export features.

When to Use These Cursor Rules

Kick off a new real-time whiteboard project with collaborative drawing and note-taking.
Establish strict event flows for canvas actions, sticky notes, and diagram edits to maintain consistency across clients.
Ensure secure authentication, per-board access control, and robust export capabilities.

Copyable .cursorrules Configuration

ROLE: Developer Assistant for a multiplayer whiteboard app
CONTEXT: You guide implementation for a React frontend, Node backend with Socket.IO, and PostgreSQL persistence.
STYLE: TypeScript, ESLint + Prettier, modular architecture, explicit types
ARCHITECTURE: FRONTEND: /frontend/src; BACKEND: /backend/src; SHARED: /shared
AUTH: JWT tokens, HttpOnly cookies; verify on socket connection; reject invalid tokens
DB: PostgreSQL with pg; migrations under db/migrations
TEST: unit tests for utilities; integration tests for API and socket events; E2E tests for critical flows
EXPORT: provide endpoints for board export in JSON and PNG; allow per-board export with access checks
PROHIBITED: Do not bypass authentication; Do not access DOM from server; Do not expose secrets in code

Recommended Project Structure

frontend/src/components/WhiteboardCanvasfrontend/src/components/StickyNotesfrontend/src/components/Diagramsfrontend/src/hooksfrontend/src/servicesfrontend/index.htmlbackend/srcbackend/src/server.jsbackend/src/routesbackend/src/controllersbackend/src/socketsdb/migrationsdb/seedstests/unittests/integrationtests/e2e

Core Engineering Principles

Clear real-time synchronization semantics with deterministic reconciliation
Explicit data models for board, strokes, notes, and diagrams
Secure authentication and per-board access control
Defensive programming: input validation, schema checks, and error handling
Test-driven approach: unit, integration, and end-to-end coverage

Code Construction Rules

Event naming conventions: board::draw, board::note_add, board::diagram_update
Frontend updates are optimistic and reconciled with server state
Board state stored as structured JSON; avoid large binary blobs in memory
Export endpoints enforce access control and data integrity
Do not use global mutable state; prefer immutable updates

Security and Production Rules

JWT-based auth with secure socket connections; token validation on connect
HTTPS and WSS in production; CSP and robust input sanitization
Least privilege database access; separate read/write roles
Audit logs for export and board modifications

Testing Checklist

Unit tests for utilities and data models
Integration tests for REST API and WebSocket events
End-to-end tests simulating multi-user collaboration
Performance tests for concurrent draw operations

Common Mistakes to Avoid

Ignoring offline and latency scenarios
Under validating inputs leading to XSS or injection
Overloading a single WebSocket channel with unbounded events
Hardcoding secrets or credentials in code

Related Cursor rules templates

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

FAQ

What is the goal of this Cursor Rules Template?

This template guides developers to implement a production-ready real-time whiteboard app with multiplayer canvas, sticky notes, diagrams, and export features using React, Node.js, and Socket.IO, with security, testing, and clean architecture patterns.

Which export formats are recommended?

JSON exports capture the board state for restoration; PNG/SVG exports provide visual snapshots. Exports should respect access controls and include per-board metadata.

How are concurrent updates resolved?

Use a deterministic reconciliation approach (CRDT or OT) on the server; clients apply optimistic updates and reconcile with server state to maintain consistency.

How do offline scenarios work?

Support local edits offline with a queued operation set; on reconnect, replay operations to the server and resolve conflicts via versioning and idempotent operations.

What should be tested for real-time features?

Tests cover socket events, room join/leave, cross-client synchronization, and latency behavior; include end-to-end tests with multiple simulated clients.

Target User

Use Cases