Industrial Predictive Maintenance Cursor Rules Template
Cursor Rules Template for building predictive maintenance apps using sensor and service ticket data in industrial SMEs. Includes a copyable .cursorrules block and stack-specific guidance.
Target User
Developers building predictive maintenance apps for industrial SMEs with sensor and service-ticket data
Use Cases
- Ingest sensor time-series data into PostgreSQL/TimescaleDB
- Correlate sensor anomalies with service tickets
- Forecast equipment failure and schedule maintenance
- Provide alerts and maintenance recommendations
Markdown Template
Industrial Predictive Maintenance Cursor Rules Template
.cursorrules
framework: Node.js + TypeScript + Express
context: Industrial predictive maintenance using sensor and service ticket data
stack: PostgreSQL with TimescaleDB, Redis (optional), RabbitMQ (optional)
orm: TypeORM
entities: SensorReading, Ticket, Equipment, MaintenanceEvent
rootDir: apps/predictive-maintenance-api
layout: layered
rules:
- role: Backend engineer for Node.js TS API
- style: TypeScript, ESLint, Prettier
- architecture: Monorepo with domain-driven layers
- authentication: JWT-based auth with scopes
- data_patterns: ingest sensor time-series; ingest service tickets; join on equipment_id
- testing: Jest unit and integration tests; lint with ESLint; type checks
- anti_patterns: Do not eval; Do not log secrets; Do not bypass authenticationOverview
Cursor rules configuration is a machine-assisted policy for Cursor AI to operate within a Node.js + TypeScript Express API that ingests sensor data and service ticket data to drive predictive maintenance for industrial SMEs. This Cursor Rules Template provides a concrete, copyable configuration you can paste into your project root as .cursorrules.
When to Use These Cursor Rules
- When building predictive maintenance features that fuse real-time sensor streams with historical service tickets.
- When creating anomaly detection, failure prediction, and maintenance scheduling workflows.
- When establishing guardrails to prevent unsafe AI actions in production data pipelines.
Copyable .cursorrules Configuration
.cursorrules
framework: Node.js + TypeScript + Express
context: Industrial predictive maintenance using sensor and service ticket data
stack: PostgreSQL with TimescaleDB, Redis (optional), RabbitMQ (optional)
orm: TypeORM
entities: SensorReading, Ticket, Equipment, MaintenanceEvent
rootDir: apps/predictive-maintenance-api
layout: layered
rules:
- role: Backend engineer for Node.js TS API
- style: TypeScript, ESLint, Prettier
- architecture: Monorepo with domain-driven layers
- authentication: JWT-based auth with scopes
- data_patterns: ingest sensor time-series; ingest service tickets; join on equipment_id
- testing: Jest unit and integration tests; lint with ESLint; type checks
- anti_patterns: Do not eval; Do not log secrets; Do not bypass authentication
Recommended Project Structure
apps/predictive-maintenance-api
├── src
│ ├── api
│ │ ├── controllers
│ │ └── routes
│ ├── domain
│ │ ├── models
│ │ └── services
│ ├── infrastructure
│ │ ├── database
│ │ │ ├── entities
│ │ │ ├── migrations
│ │ │ └── repositories
│ │ └── messaging
│ └── config
└── tests
Core Engineering Principles
- Clear separation of API, domain, and infrastructure concerns
- Data-first design with explicit contracts for sensor and ticket data
- Security by default with robust authentication and encrypted channels
- Observability through structured logging, metrics, and tracing
- Reproducible builds and deterministic deployments
Code Construction Rules
- Enforce strict TypeScript typing for all DTOs and entities
- Use TypeORM models with proper migrations and relations
- Do not bypass authentication; validate every API boundary
- Encapsulate sensor and ticket ingestion in dedicated services
- Avoid cross-origin data leakage by respecting data ownership
- Write tests that cover ingestion, joining logic, and failure modes
Security and Production Rules
- Enable TLS in all endpoints; rotate secrets; do not log sensitive data
- Use JWT with scopes and role checks; enforce least-privilege access
- Validate inputs strictly; protect against injection and timing attacks
- Separate read/write databases if possible; implement robust backup strategy
Testing Checklist
- Unit tests for sensors parsing, tickets parsing, and data contracts
- Integration tests for ingestion pipelines and database writes
- End-to-end tests simulating real sensor and ticket streams
- CI checks for linting, type-checks, and security scans
Common Mistakes to Avoid
- Mixing domain logic with API handlers; create pure services
- Neglecting time zone handling for sensor data
- Skipping migrations and relying on in-memory schemas
- Ignoring security between ingestion endpoints
Related implementation resources: AI Agent Use Case for Food & Beverage Plants Using SCADA Logs To Predict and Prevent Conveyor Belt Motor Failures and Production-grade API design for coding agents: practical rules and templates.
FAQ
What is this Cursor Rules Template used for?
This template provides a complete, copyable .cursorrules configuration for building predictive maintenance apps that fuse sensor data with service ticket data in industrial SMEs, guided by Cursor AI rules.
Which stack does this template target?
Node.js with TypeScript and Express, PostgreSQL with TimescaleDB, and a TypeORM ORM layer for data modeling, plus JWT-based security for production-grade deployments.
How do I test the ingestion and predictions?
Tests cover unit parsing of sensors and tickets, integration tests for database writes, and end-to-end tests that simulate real data streams; use CI to ensure linting and type checks are enforced.
How should I deploy securely?
Deploy with TLS, rotate secrets via a secret store, enforce least-privilege access, and monitor ingestion latency, error rates, and prediction accuracy; apply migrations with rollback plans.
Can I extend this template for other stacks?
Yes. The structure supports extension by swapping the ORM and adapting data contracts while preserving Cursor AI rules for safe, auditable AI-driven maintenance decisions.