Cursor Rules Template: Green Building Audit Prioritization Dashboards

Overview


Cursor rules configuration for building green-building audit prioritization dashboards on a Node.js + React + PostgreSQL (TypeORM) stack. This template encodes guardrails, architecture rules, security norms, and testing expectations to keep development aligned with safe, auditable, and scalable Cursor AI-guided workflows.


Direct answer: This Cursor rules template provides a concrete, copyable configuration block and stack-specific guidelines you can paste into your project root to enforce consistent patterns across backend, frontend, and data access layers for green-building audits.



When to Use These Cursor Rules



  - Starting a green-building audit dashboard project with clear architectural boundaries.

  - Enforcing consistent data access for audit items and remediation tasks.

  - Defining security, authentication, and data protection expectations for a public-facing ESG dashboard.

  - Setting up CI/CD, tests, and linting to prevent drift in a multi-repo stack.

  - Ensuring auditable decision records and reproducible deployments for regulatory review.



Copyable .cursorrules Configuration


# Cursor Rules for Green Building Audit Dashboard
framework: node-typescript+react-typescript+postgresql+typeorm
stack: backend(Node.js + TypeScript) + frontend(React + TypeScript) + database(PostgreSQL via TypeORM)
role: full-stack-engineer
context: You are an AI assistant that enforces safe, auditable, and scalable Cursor-guided development for a green-building audit dashboard. You must preserve data integrity, explicit boundaries, and secure handling of ESG data across the stack.
codeStyle: eslint-config-airbnb-typescript, prettier, tsconfig-strict
architecture:
  directories:
    backend/src/
      controllers/
      services/
      entities/
      migrations/
    frontend/src/
      components/
      pages/
      hooks/
    shared/
  patterns:
    modules-per-domain, feature-based folders, strict boundaries
authentication:
  method: jwt
  token:
    access: 15m
    refresh: 7d
    httpOnly: true
    sameSite: strict
security:
  tls: enabled
  secrets: env.JWK_KEYS
  csrfProtection: enabled
database:
  engine: postgres
  orm: typeorm
  migrations: enabled
  namingConventions: camelCase
  sqlPatterns:
    - parameterizedQueries
    - avoidRawSQL
ormPatterns:
  entities: [AuditSite, AuditItem, AuditResult, AuditPolicy]
  relations: [AuditSite hasMany AuditItem, AuditSite hasMany AuditPolicy]
  migrations: true
testing:
  unit: jest + ts-jest
  integration: supertest
  e2e: cypress
linting:
  eslint: latest
  prettier: true
prohibitedActions:
  - avoid string concatenation in SQL
  - do not bypass TLS in production
  - do not store secrets in code

Recommended Project Structure


backend/
  src/
    main.ts
    app.ts
    controllers/
      auditController.ts
    services/
      auditService.ts
    entities/
      AuditSite.ts
      AuditItem.ts
      AuditResult.ts
    migrations/
      001-create-schema.ts
  migrations/
  config/
    ormconfig.ts
frontend/
  src/
    index.tsx
    App.tsx
    pages/
      Dashboard.tsx
    components/
      widgets/
        Gauge.tsx
    hooks/
      useAuditData.ts
  tests/
    unit/
    integration/
shared/
  lib/
  types/

Core Engineering Principles



  - Explicit boundaries: separate backend, frontend, and data access concerns with clear module contracts.

  - Security-by-default: TLS, JWT-based auth, and least-privilege DB access.

  - Idempotent operations: avoid side effects in repeated Cursor runs; use upserts and transactional boundaries.

  - Observability: structured logging, metrics, and tracing for audit actions.

  - Reproducibility: versioned migrations, deterministic builds, and lockfile pinning.



Code Construction Rules



  - Use TypeScript throughout the stack with strict type-checking enabled.

  - Backend must use TypeORM with parameterized queries; avoid raw string concatenation.

  - Frontend components should be designed as pure, stateless UI with clear prop contracts.

  - Data models must reflect the green-building audit domain (sites, audits, items, remediation actions).

  - All secrets must be sourced from environment variables or secret management; do not embed in code.

  - Tests must cover unit, integration, and end-to-end paths for audit prioritization flows.

  - Do not bypass security or degrade access controls for expediency.



Security and Production Rules



  - Enable TLS termination in production and enforce secure cookies for auth tokens.

  - Use short-lived access tokens with refresh tokens and rotating keys.

  - Audit database access and enable row-level security where appropriate; enforce least privilege roles.

  - Validate all inputs, enforce server-side validation, and log security-relevant events.

  - Set up monitoring, alerting, and automated recovery for critical services.



Testing Checklist



  - Unit tests for business rules around audit prioritization logic.

  - Integration tests for API endpoints and ORM mappings.

  - End-to-end tests simulating the audit prioritization workflow from frontend to DB.

  - Linting and type checks as part of CI; fail on warnings.

  - Security tests for JWT validation and input sanitization.



Common Mistakes to Avoid



  - Mixing frontend and backend concerns in a single module; keep domain boundaries tight.

  - Ignoring migrations in favor of destructive schema changes.

  - Storing secrets in code or environment files without proper rotation.

  - Over-reliance on dynamic SQL without proper parameterization.

  - Neglecting observability, which makes debugging audit-priority issues hard to reproduce.



Related implementation resources: AI Use Case for Software Agencies Using Github Copilot To Accelerate Boilerplate Code Generation for New Client Mvps and How project rules prevent AI from breaking existing code patterns in production-grade systems.





FAQ


What is the purpose of this Cursor Rules Template?


It defines a comprehensive, stack-specific set of guardrails, architecture rules, and testing expectations to guide the development of green-building audit prioritization dashboards. The template ensures safe data handling, auditable actions, and repeatable deployments when using Cursor AI across a Node.js backend, React frontend, and PostgreSQL database. It is designed to be pasted into your project root.


Which stack does this template cover?


The template targets a Node.js (TypeScript) backend with Express/Nest.js, a React (TypeScript) frontend, and PostgreSQL using TypeORM as the ORM layer. It includes authentication, data access patterns, and testing workflows aligned with Cursor AI rules for green-building audits.


How do I customize the green-building data model in the rules?


Adapt the ORM entities to reflect your data model: AuditSite, AuditItem, AuditResult, and related remediation actions. Use migrations for schema changes, keep naming conventions consistent, and ensure data relations mirror the real-world relationships between sites, audits, and remediation tasks.


How can I test the Cursor rules locally?


Run unit tests for core logic, integration tests for API routes, and E2E tests covering the dashboard workflow. Use a local PostgreSQL instance with a seeded dataset, and validate that prioritization results align with expected outcomes under different scenarios.


Can I extend this template to additional dashboards?


Yes. Extend the data model, adjust query patterns for new visualizations, and add domain-specific rules for additional ESG dashboards. Maintain strict boundaries and reuse the same Cursor rules structure to preserve consistency across projects.