Social Dashboard Cursor Rules Template for Cursor AI

Overview

This Cursor rules configuration is a paste-ready, instruction-driven block designed for building a social media analytics dashboard with Cursor AI. It targets a Next.js frontend paired with a Node.js API, PostgreSQL as the data store, Prisma as the ORM, and AI-driven insights. Direct answer: paste this into your project root as a .cursorrules file to enforce architecture, security, testing, and AI safety for post performance, audience growth, engagement, and AI insights features.

The template defines the stack, coding standards, data access patterns, and safety constraints to keep development predictable and auditable while enabling AI-assisted engineering across the full stack.

When to Use These Cursor Rules

Starting a new social analytics dashboard project with a Next.js frontend and a Node.js API backend.
Enforcing a PostgreSQL+Prisma data layer for analytics facts and dimensions.
Preparing CI/CD pipelines with unit, integration, and E2E tests for a data-heavy dashboard.
Incorporating AI-driven insights into visuals and reports while maintaining security and data privacy.
Onboarding new contributors by providing a single source of truth for project structure and rules.

Copyable .cursorrules Configuration

// Cursor Rules Template for Social Dashboard (Stack: Next.js + Node.js API + PostgreSQL + Prisma)
// Copy this block into the project root as .cursorrules

framework: "Next.js + Node.js API + PostgreSQL + Prisma"
context: "You are building a social media analytics dashboard UI and API showing post performance, audience growth, engagement metrics, and AI-derived insights. Cursor AI should enforce architecture, data privacy, testing, and safe AI usage within this stack."
role: "Cursor AI acts as a full-stack engineering assistant for a Next.js frontend, a Node.js API, and a PostgreSQL database accessed via Prisma. It guides file layout, data modeling, and automated checks."
codeStyle: "TypeScript, ESLint with Airbnb/TSConfig, Prettier, React/JSX, TailwindCSS, Storybook for components"
architecture: "Monorepo with apps/web (Next.js) and apps/api (Node.js). Central PostgreSQL DB accessed through Prisma ORM. Shared libs under libs/. Use Next.js API routes or an Express-style API. Implement server-side auth middleware and data access layer."
authentication: "Use HTTP-only cookies or JWTs with short-lived access tokens; store secrets in environment variables; validate tokens server-side; ensure CSRF protection for stateful sessions."
database: "PostgreSQL with Prisma ORM; explicit migrations; seed and test data; analytics stars/fact tables and dimensional model for dashboards."
testing: "Jest + React Testing Library for UI, Vitest for server-side tests, Playwright for end-to-end; CI runs type checks, lint, unit/integration tests, and a basic e2e suite."
antiPatterns: "Do not call the database from the client; Do not bypass server-side validation; Do not store secrets in client code; Do not rely on insecure authentication flows; Do not over-fetch analytics data on API routes without filtering by tenant/role."
prohibitedActions: "Do not eval user input; Do not expose DB credentials or API keys in frontend; Do not ship raw SQL in responses; Do not ignore CORS or rate-limiting in public APIs."

Recommended Project Structure

project-root/
├── src/
│   ├── apps/
│   │   ├── web/        # Next.js frontend (app router)
│   │   └── api/        # Node.js API (or Next.js API routes)
│   ├── lib/            # shared utilities and config
│   ├── services/       # domain services (analytics, AI insights)
│   ├── components/     # UI components
│   │   └── ui/
│   └── styles/         # CSS/Tailwind setup
├── prisma/             # Prisma schema and migrations
│   └── schema.prisma
├── tests/              # unit/integration/e2e tests
│   ├── unit/
│   ├── integration/
│   └── e2e/
├── scripts/            # CI, migrations, seed scripts
└── README.md

Core Engineering Principles

Explicit contracts: strongly type inputs/outputs across frontend, API, and data layer.
Single source of truth for analytics data model: fact tables for metrics and dimensions for context.
Type-safe boundaries: keep Prisma/DB types flowing to UI through well-defined APIs.
Security by default: validate inputs, restrict access, rotate keys, and protect secrets.
Observability: structured logging, metrics, and tracing for queries and AI actions.
Performance discipline: caching for heavy analytics queries and paginated fetches.
Testability: unit, integration, and E2E tests with CI checks and type checks.

Code Construction Rules

Frontend calls must use API routes or server-side data fetch; never access DB directly from client code.
Use Prisma for all DB interactions; keep a dedicated data-access layer with typed DTOs.
Enforce strict input validation and output schemas on API boundaries.
Environment-driven configuration; never hardcode secrets; use vaults or secret managers in production.
Adopt TypeScript end-to-end; keep types synchronized across API and UI layers.
Lint, format, and run type checks in CI; fail builds on violations.
Maintain clear API contracts; version endpoints when breaking changes are introduced.

Security and Production Rules

Encrypt in transit with TLS; enable HSTS; use secure cookies with HttpOnly flags.
Implement RBAC for dashboard data; enforce tenant isolation and row-level security where appropriate.
Validate all inputs; sanitize and escape data to prevent injection attacks.
Rate-limit public API access; log anomalies and implement alerting for unusual query patterns.
Manage secrets via environment variables; rotate credentials and audit access.
Monitor performance budgets; alert on long-running analytics queries and API slowness.

Testing Checklist

Unit tests for data transformation and utility functions.
Integration tests for API routes and Prisma data layer.
End-to-end tests covering login, data loading, and AI insight generation (Playwright).
Type-checks and linting in CI; ensure code style consistency.
Regression tests for dashboard visuals and metrics calculations.

Common Mistakes to Avoid

Exposing secrets in client code or committing them to VCS.
Calling DB queries directly from components or the browser.
Ignoring time zones and date handling in analytics aggregations.
Over-fetching analytics data or returning large payloads without pagination.
Skipping tests for critical data workflows or AI inference paths.

Related Cursor rules templates

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

FAQ

What is the purpose of this Cursor Rules Template?

This template provides a paste-ready set of Cursor AI instructions to guide architecture, security, tests, and AI-assisted development for a social media analytics dashboard stack (Next.js + Node.js API + PostgreSQL + Prisma). It helps engineers implement consistent patterns and safe AI usage.

Which stack is this template tailored for?

It targets Next.js for the frontend, a Node.js API backend, PostgreSQL for data storage, and Prisma as the ORM. The rules enforce architecture, data contracts, and AI safety within this stack.

How do I use the .cursorrules block in my project?

Copy the block into a new .cursorrules file at your project root. Ensure your project structure matches the recommended layout and adapt environment-specific values (DB connection strings, secret keys) via environment variables.

How can I extend this template with AI insights?

Extend the data model with analytics-specific AI inference steps, ensure output is validated, and keep AI calls rate-limited and auditable. Use clearly defined interfaces so AI-generated code remains testable and secure.

Where can I find related Cursor Rules Templates?

Related resources are available under the Cursor Rules Templates collection in the AI Skills Library, including other stack-specific templates and guidelines for safe AI-assisted development.

Target User

Use Cases