Ecommerce Price Monitoring Cursor Rules Template

Overview

Direct answer: This Cursor rules configuration provides a production-ready, copyable set of Cursor AI instructions for building a competitor price monitoring tool on a modern ecommerce stack (Next.js frontend, Express backend, PostgreSQL database, Redis cache). It specifies role, style, architecture, authentication, DB patterns, testing, and anti-patterns so you can paste the .cursorrules block into your project root and proceed with confidence.

The template targets a full-stack price monitoring solution used by ecommerce sellers to track rival pricing, detect undercut opportunities, surface alerts, and maintain historical price intelligence. It emphasizes safe AI-assisted development, traceable outputs, and reproducible results in a production workflow.

When to Use These Cursor Rules

When implementing a price-tracking pipeline that ingests product feeds, API price data, or scraped data with compliant data sources.
When you need a consistent coding and security standard across frontend (Next.js) and backend (Express) layers.
When building testing, linting, and CI workflows around a price-monitoring feature set.
When you want a repeatable project structure with clear separation between data models, services, and routes.
When enforcing safe AI usage, including audit trails and strict anti-patterns for data handling.

Copyable .cursorrules Configuration

// Cursor Rules Template for Ecommerce Price Monitoring
Framework: Next.js frontend, Node.js (Express) backend, PostgreSQL, Redis
Role & Context: You are a Senior Full-Stack Engineer building a competitor price monitoring tool for ecommerce sellers. Output production-ready code blocks and configuration using Cursor AI.
Code Style and Style Guides: TypeScript, ESLint, Prettier; explicit types, consistent naming, no questionable patterns; adhere to Airbnb-like conventions where applicable.
Architecture & Directory Rules:
  - apps/
    - frontend/
      - src/
      - pages/
      - components/
      - styles/
    - backend/
      - src/
      - controllers/
      - routes/
      - services/
      - models/
      - repositories/
      - migrations/
  - libs/
  - databases/
  - migrations/
  - tests/
Authentication & Security Rules:
  - Use JWTs with short expiry (e.g., 15-60 minutes) and refresh tokens
  - Enforce HTTPS and secure cookies; set HSTS
  - Do not log PII; mask sensitive fields in logs
  - Validate all inputs; use parameterized queries and output escaping
Database and ORM patterns:
  - PostgreSQL with Knex for query building (avoid ORM leaking raw SQL)
  - Tables: sellers, products, price_records, competitors, alerts, histories
  - Use composite indexes on (seller_id, product_id, price_timestamp)
Testing & Linting Workflows:
  - Unit tests with Jest
  - Integration tests with supertest for APIs
  - Linting with ESLint; formatting with Prettier
  - CI: lint, test, typecheck, build, and security checks
Prohibited Actions and Anti-patterns for the AI:
  - Do not propose unsafe eval or server-side code execution
  - Do not bypass rate limits or robots.txt; do not scrape without permission
  - Do not embed secrets in code blocks; use environment variables
  - Do not return unvalidated user input to the database

Recommended Project Structure

/apps
  /frontend
    /src
      /pages
      /components
      /styles
      /utils
  /backend
    /src
      /controllers
      /routes
      /services
      /models
      /repositories
      /middlewares
      /utils
      /config
      /migrations
  /libs
  /databases
  /tests
  /scripts

Core Engineering Principles

Clear separation of concerns across frontend, backend, and data layer.
Idempotent price fetch and upsert logic to avoid data drift.
Strong typing and explicit contracts for API inputs/outputs.
Defensive security: input validation, authorization, and secrets management.
Observability: structured logging, metrics, and tracing for price pipelines.

Code Construction Rules

Use TypeScript end-to-end; define API schemas with types and runtime validation.
Environment-based configuration; avoid hard-coded values.
All DB queries parameterized; prefer Knex query builder style over raw strings.
Cache price data with Redis; implement TTLs and cache invalidation on writes.
API responses are consistent: { success: boolean, data: T, error?: string }.
Do not couple frontend rendering with business logic; keep data-fetching in services.

Security and Production Rules

Enforce HTTPS, set HSTS, and rotate secrets regularly.
Use short-lived JWTs with refresh tokens and implement token revocation.
Limit API rate per seller and IP; implement robust input validation and escaping.
Encrypt sensitive data at rest where feasible; avoid storing raw competitor data beyond necessity.
Audit access to price data and keep an immutable log of critical actions.

Testing Checklist

Unit tests cover business rules for price normalization and threshold calculations.
Integration tests verify API endpoints for price ingestion and alert creation.
End-to-end tests simulate a price update flow from ingestion to alert dispatch.
CI runs lint, tests, type checks, and a quick deployment smoke test.

Common Mistakes to Avoid

Mixing business logic with API handlers; it reduces testability.
Hard-coding environment-specific URLs or credentials in code blocks.
Using client-side code to fetch or validate server-side price data.
Neglecting input validation and error handling paths in data ingestion.
Neglecting access controls when exposing price data to multiple sellers.

FAQ

What is the Cursor rules template for ecommerce price monitoring?

A ready-to-paste Cursor AI instruction block that configures a Next.js + Express + PostgreSQL stack to support competitor price tracking, alerts, and historical analysis, with security and testing baked in.

Which stack does this Cursor Rules Template target?

Next.js frontend, Express backend, PostgreSQL database, and Redis caching, using Knex as the SQL query builder for safe data access.

What should I include in the copyable .cursorrules block?

Framework role, code style, architecture and directory rules, authentication, database patterns, testing, linting, and clearly defined anti-patterns for safe AI-assisted development.

How do I structure the recommended project tree?

Follow a clean monorepo layout with apps/frontend, apps/backend, migrations, libs, databases, tests, and scripts; avoid irrelevant folders and ensure clear separation of concerns.

What are key security considerations for production?

Implement HTTPS, token rotation, least-privilege DB access, secure credential storage, input validation, and proper logging to prevent information leakage and injection attacks.

Target User

Use Cases