Energy Monitoring Dashboard Cursor Rules Template for Cursor AI
Cursor Rules Template for building an energy monitoring dashboard using smart meter data with alerts, usage analytics, and AI recommendations. Copy the .cursorrules block into your project root.
Target User
Developers building data dashboards with real-time smart meter data and AI-driven recommendations using a Node.js/TypeScript backend, PostgreSQL, Redis, and a React frontend.
Use Cases
- Ingest smart meter readings into PostgreSQL
- Compute usage analytics and alerts in real-time
- Generate AI-driven energy-saving recommendations
- Provide a responsive React dashboard with alerting and analytics
Markdown Template
Energy Monitoring Dashboard Cursor Rules Template for Cursor AI
Framework: Node.js & TypeScript (Backend) + React (Frontend)
Context: Energy monitoring dashboard with smart meter data, real-time alerts, usage analytics, and Cursor AI recommendations
CodeStyle:
Language: TypeScript
StyleGuide: ESLint + Prettier; strict types; no implicit any
Architecture & Directory Rules:
- Monorepo layout: /frontend, /backend, /data, /infra
- Backend: /backend/src/{controllers, routes, services, models, config, middleware}
- Frontend: /frontend/src/{components, pages, hooks, services}
- Data: /data/{raw, processed}
- Infrastructure: /infra; Docker and/or Kubernetes manifests
Authentication & Security Rules:
- Use OAuth 2.0 / OIDC with JWT access tokens and refresh tokens
- TLS termination, secure cookies, HSTS, and CSRF protections where appropriate
- Do not expose DB credentials or secrets in source; use environment variables and secret managers
Database and ORM Patterns:
- PostgreSQL as primary data store; no ORM (use node-postgres with parameterized queries)
- Tables: meters, readings, alerts, users, analytics, ai_recs
- Indexes on timestamps and foreign keys; migrations via a lightweight tool (no opaque migrations)
Testing & Linting Workflows:
- Unit tests with Jest; ts-jest for TS support
- Integration tests for API endpoints with Supertest
- Linting with ESLint; formatting with Prettier; pre-commit hooks enabled
- CI checks in GitHub Actions: build, test, lint, and type-check
Prohibited Actions and Anti-patterns:
- Do not use ORM libraries like Prisma, Mongoose, or Drizzle
- Do not perform client-side DB access or expose DB queries in UI
- Do not bypass input validation or skip sanitization; avoid dynamic SQL
- Do not ship secrets in images or environment without proper secret managementOverview
This Cursor rules configuration provides a complete, copyable Cursor rules template for building an energy monitoring dashboard using smart meter data. It targets a full-stack TypeScript/Node.js backend with PostgreSQL, Redis for caching, and a React frontend, plus AI-driven recommendations via Cursor AI. The template ensures safe AI-assisted development, consistent coding standards, and production-ready patterns. You can paste the contained .cursorrules block into your project root to enforce stack-specific rules for energy dashboards.
Direct answer: use this Cursor rules template to ensure a robust, secure, and maintainable energy-monitoring stack with real-time data, alerts, analytics, and AI-driven recommendations.
When to Use These Cursor Rules
- Starting a new energy monitoring dashboard project that ingests real-time smart meter data.
- Standardizing coding, testing, and deployment practices for a Node.js + React stack.
- Incorporating AI-driven recommendations and alerts without leaking secrets or introducing unsafe patterns.
- Ensuring architecture rules are followed for a clean separation between frontend, backend, and data processing.
Copyable .cursorrules Configuration
Framework: Node.js & TypeScript (Backend) + React (Frontend)
Context: Energy monitoring dashboard with smart meter data, real-time alerts, usage analytics, and Cursor AI recommendations
CodeStyle:
Language: TypeScript
StyleGuide: ESLint + Prettier; strict types; no implicit any
Architecture & Directory Rules:
- Monorepo layout: /frontend, /backend, /data, /infra
- Backend: /backend/src/{controllers, routes, services, models, config, middleware}
- Frontend: /frontend/src/{components, pages, hooks, services}
- Data: /data/{raw, processed}
- Infrastructure: /infra; Docker and/or Kubernetes manifests
Authentication & Security Rules:
- Use OAuth 2.0 / OIDC with JWT access tokens and refresh tokens
- TLS termination, secure cookies, HSTS, and CSRF protections where appropriate
- Do not expose DB credentials or secrets in source; use environment variables and secret managers
Database and ORM Patterns:
- PostgreSQL as primary data store; no ORM (use node-postgres with parameterized queries)
- Tables: meters, readings, alerts, users, analytics, ai_recs
- Indexes on timestamps and foreign keys; migrations via a lightweight tool (no opaque migrations)
Testing & Linting Workflows:
- Unit tests with Jest; ts-jest for TS support
- Integration tests for API endpoints with Supertest
- Linting with ESLint; formatting with Prettier; pre-commit hooks enabled
- CI checks in GitHub Actions: build, test, lint, and type-check
Prohibited Actions and Anti-patterns:
- Do not use ORM libraries like Prisma, Mongoose, or Drizzle
- Do not perform client-side DB access or expose DB queries in UI
- Do not bypass input validation or skip sanitization; avoid dynamic SQL
- Do not ship secrets in images or environment without proper secret management
Recommended Project Structure
energy-monitoring-dashboard/
├── frontend/
│ ├── src/
│ │ ├── components/
│ │ ├── pages/
│ │ ├── hooks/
│ │ └── services/
│ └── public/
├── backend/
│ ├── src/
│ │ ├── controllers/
│ │ ├── routes/
│ │ ├── services/
│ │ ├── models/
│ │ ├── config/
│ │ └── middleware/
│ └── tests/
├── data/
│ ├── raw/
│ └── processed/
├── infra/
│ ├── docker/
│ └── kubernetes/
└── README.md
Core Engineering Principles
- Define clear boundaries between frontend, backend, and data processing components.
- Prefer typed interfaces and strict runtime validation for all inputs and external data.
- Automate testing, linting, and deployment; keep human-in-the-loop decisions isolated from production code.
- Guard secrets, rotate keys, and use least privilege access controls for all services.
- Design for observability: structured logs, metrics, and tracing from ingestion to UI.
Code Construction Rules
- Use TypeScript end-to-end with strictNullChecks and noImplicitAny.
- Backend DB access via parameterized queries using the pg library; avoid string concatenation for SQL.
- Validate all inputs server-side; reject malformed meter data immediately.
- Keep business logic in services; controllers should be thin and delegate to services.
- Tag all API endpoints with clear, versioned routes and proper error handling.
- Frontend should rely on type-safe APIs; define shared types between frontend and backend.
- Do not include inline secrets or credentials; use environment-based configuration management.
Security and Production Rules
- Enforce TLS, secure cookies, and CSRF protections for browser-based clients.
- Implement request rate limiting and IP allowlists for sensitive endpoints.
- Validate CORS restrictions; restrict origins to trusted dashboards.
- Use secret management for database credentials and API keys; rotate secrets regularly.
- Enable auditing on critical data access and ensure immutable logs for alerts and analytics events.
Testing Checklist
- Unit tests cover all service methods and data transformation logic.
- Integration tests validate API contracts and database queries with a test database.
- End-to-end tests verify the dashboard data flow from ingestion to UI rendering.
- Lint and type-check as part of the CI pipeline; fail-fast on type or lint errors.
- Security tests include input validation and basic vulnerability checks.
Common Mistakes to Avoid
- Treating the backend like a data dump; ensure proper validation and schema evolution.
- Embedding database credentials in code or Docker images; rely on secret managers.
- Skipping tests for data processing paths or AI recommendation logic.
- Overloading the frontend with raw database calls or unpaginated large payloads.
- Ignoring observability; failing to emit structured logs and metrics for real-time dashboards.
Related Cursor rules templates
Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.
- Cursor Rules Template: IoT Water Monitoring with FastAPI & PostgreSQL
- Supplier Risk Monitoring Platform Cursor Rules Template
- AWS Cost Dashboard Cursor Rules Template for AWS Billing Imports, Anomaly Detection and AI Recommendations
- Cursor Rules Template: Construction Project Management Stack
FAQ
What is this Cursor Rules Template designed to cover?
This template targets an energy monitoring stack with smart meter data ingestion, real-time alerts, usage analytics, and AI-generated recommendations. It provides a copyable .cursorrules block and a stack-specific project structure to keep development disciplined and secure while enabling Cursor AI to assist safely.
Which technologies does the stack use?
The stack uses a Node.js + TypeScript backend with PostgreSQL and Redis, a React frontend, and Cursor AI for recommendations. No ORM is assumed; database access relies on parameterized queries using the pg library. Frontend and backend communicate through typed REST or GraphQL APIs.
Where do I paste the .cursorrules block?
Paste the copied .cursorrules block into the project root as a file named .cursorrules. It will govern developer behavior, checks, and constraints for the energy dashboard stack.
How does this template handle credentials and secrets?
Secrets are never checked into source control. Use environment variables and a secret management tool. The Cursor rules enforce not exposing credentials in code, configs, or logs, and require validated retrieval from secret stores at runtime.
What testing and deployment workflow is recommended?
Use Jest for unit tests, Supertest for API integration tests, and a CI pipeline (GitHub Actions) to run linting, type checks, tests, and build steps. Docker images should be tested in a staging environment before production deployment.
Can I customize the project structure for my team?
Yes. The template provides a recommended structure but can be adjusted to match your organizational standards, so long as the core rules—security, testing, and clear separation of concerns—are preserved.