Cursor Rules Template: Solar CRM for Solar Installations

Overview

A Cursor rules configuration for Cursor AI is a structured set of instructions that guides the AI to implement a complete solar installation CRM workflow. This template targets a Node.js backend with PostgreSQL and a React frontend, and covers leads, site surveys, proposals, permits, and project tracking.

When to Use These Cursor Rules

• When you want consistent AI behavior across leads to projects workflows in a solar CRM
• When you need repeatable results for data modeling, transforms, and validations
• When you want the AI to generate, validate, and document architectural decisions
• When enforcing security, testing, and linting in one place

Copyable .cursorrules Configuration

// Cursor Rules for Solar CRM Stack
// Framework Role & Context
Role: Senior Backend Engineer for Node.js + PostgreSQL + React Solar CRM
Context: Build and maintain a solar installation CRM with leads, site surveys, proposals, permits, and project tracking
---
// Code Style and Style Guides
Style: TypeScript with strict mode, ESLint set to Airbnb, Prettier formatting
---
/* Architecture & Directory Rules */
Structure: Monorepo with server and client folders
Server: server/src
Client: client/src
Shared: common types and utilities
DB: server/db with migrations and seed data
---
/* Authentication & Security Rules */
Auth: JWT access tokens, HttpOnly refresh tokens, CSRF protection, input validation, parameterized queries
---
/* Database and ORM patterns */
DB: PostgreSQL, normalized schema, explicit foreign keys, indexing, migrations
---
/* Testing & Linting Workflows */
Tests: Jest + Supertest for API, React testing library for UI, CI lint and test gates
---
/* Prohibited Actions and Anti-patterns for the AI */
Do not reach to external services in production code, never log secrets, avoid dynamic SQL; do not bypass auth

Recommended Project Structure

solar-crm/
├─ server/
│  └─ src/
│     ├─ api/
│     │  ├─ leads
│     │  ├─ site_surveys
│     │  ├─ proposals
│     │  ├─ permits
│     │  └─ projects
│     ├─ db/
│     │  ├─ migrations
│     │  └─ models
│     ├─ routes
│     └─ services
├─ client/
│  └─ src/
│     ├─ components
│     ├─ pages
│     └─ hooks
└─ shared/
   ├─ lib
   └─ types

Core Engineering Principles

• Clear domain boundaries between leads, surveys, proposals, permits, and projects
• Idempotent API operations and deterministic side effects
• Defensive programming and strong input validation
• Observability through structured logs and metrics
• Versioned Cursor rules and PR friendly governance
• Security by default with least privilege access

Code Construction Rules

• Use TypeScript typings across server and client code
• Follow a strict folder layout so each domain module has its own API, data, and UI components
• Validate all inputs at boundary layers and sanitize outputs
• Prefer parameterized queries and explicit ORM-like patterns without unsafe string concatenation
• Keep business logic in services with clear unit test coverage
• Document API contracts with precise shapes and error codes

Security and Production Rules

• Use TLS end to end; store secrets in a dedicated vault; rotate credentials
• Use httpOnly cookies for refresh tokens and set proper sameSite policy
• Validate and sanitize all inputs; enforce rate limiting and audit trails
• Limit data exposure to authorized roles; implement field-level access control
• Enable robust error handling and avoid leaking stack traces in production

Testing Checklist

• Unit tests for validators and utility functions
• Integration tests for leads workflow, site surveys, and proposals
• End-to-end tests for core user journeys
• CI gates for lint, test, and type checking

Common Mistakes to Avoid

• Assuming ORM choices are interchangeable; align with the actual stack
• Overexposing fields in APIs; missing input validation
• Hardcoding secrets or API keys in code or migrations
• Skipping migrations or relying on in-memory storage for production
• Ignoring access control in multi-tenant or admin flows

Related Cursor rules templates

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

• Cursor Rules Template: Customer Success Platform with Health Scores, Renewals, NPS and AI Churn
• Cursor Rules Template: Construction Project Management Stack
• Cursor Rules Template: Rental Marketplace with Property Listings, Applications, Tenant Screening, Payments and Messaging
• Cursor Rules Template: Sales Pipeline SaaS with Lead Scoring, Email Tracking, and AI Dashboards

FAQ

What is a Cursor Rules Template for Solar CRM?

A Cursor Rules Template provides a copyable .cursorrules block that guides Cursor AI to implement a solar CRM workflow. It covers leads, site surveys, proposals, permits, and project tracking, with security, testing, and architecture guidelines.

Which stack does this template target?

This template targets a Node.js backend with PostgreSQL for data and a React frontend; Cursor AI rules coordinate API behavior, data integrity, and workflow orchestration across solar CRM modules.

How do I use the provided .cursorrules block?

Copy the code block within the content field into a file named .cursorrules at your project root and adapt paths to match your repository. The rules direct Cursor AI during development, testing, and code generation.

Can I adapt this template to other stacks?

Yes. Modify the framework label, directory layout, ORM references, and API contracts to match another stack. The Cursor rules template serves as a blueprint that can be adjusted for different backends and frontend frameworks.

What are security best practices in production?

Enforce TLS, use httpOnly cookies for refresh tokens, validate inputs, use parameterized queries, rate limit requests, rotate secrets, and monitor logs. The template emphasizes these controls to reduce risk in the solar CRM workflow.