WhatsApp Inquiry Classification Cursor Rules Template for Local Service SMEs

Overview


The Cursor rules configuration you paste here enables a Node.js/TypeScript backend to process WhatsApp messages via the WhatsApp Business API and classify inquiries for local service SMEs. This Cursor rules template is a ready to paste, copyable block designed for the specific stack and workflow of WhatsApp based inquiry routing with Cursor AI.



When to Use These Cursor Rules



  - When building a live WhatsApp inquiry classifier for plumbers, electricians, cleaners, and other local service providers.

  - When you need deterministic routing of inquiries into service categories (e.g., availability, pricing, booking, call back).

  - When you require security conscious input handling and webhook verification for WhatsApp Business API.



Copyable .cursorrules Configuration


# Cursor Rules Template for WhatsApp Inquiry Classification (Local SMEs)
Framework Role & Context
Role: Backend Node.js + TypeScript service that processes WhatsApp messages from the WhatsApp Business API, and classifies inquiries into service categories for local SMEs.
Context: Aligns with Cursor AI for deterministic routing and rule based checks.

Code Style and Style Guides
Language: TypeScript
Style: ESLint with Airbnb rules; Prettier; strict typing; no implicit any.

Architecture & Directory Rules
DirectoryRules:
  - src/
  - src/controllers/
  - src/services/
  - src/models/
  - src/repositories/
  - src/routes/
  - src/middleware/
  - tests/
  - config/

Authentication & Security Rules
Security:
  - Verify WhatsApp webhook signatures using HMAC-SHA256
  - Use JWTs for internal API authentication
  - Do not log secrets; use environment vars or a vault
  - Enforce TLS in production; rotate API keys regularly

Database and ORM patterns
Database:
  - PostgreSQL using pg (no ORM)
  - Use parameterized queries; store only necessary fields
  - Do not store raw WhatsApp messages beyond transient processing

Testing & Linting Workflows
Testing:
  - Unit tests with Vitest
  - Integration tests for webhook flows
  - CI runs lint, typecheck, tests, and deploy checks

Prohibited Actions and Anti-patterns for the AI
Prohibited:
  - Do not call external services in hot path without timeouts
  - Do not bypass input validation
  - Do not store tokens or secrets in code or logs
  - Do not implement classification logic in the route layer; separate concerns

Recommended Project Structure


my-app/
├── src/
│   ├── controllers/
│   │   └─ inquiryController.ts
│   ├── services/
│   │   └─ classificationService.ts
│   ├── models/
│   │   └─ inquiry.ts
│   ├── repositories/
│   │   └─ inquiryRepo.ts
│   ├── routes/
│   │   └─ webhookRoutes.ts
│   ├── middleware/
│   │   └─ authMiddleware.ts
│   ├── config/
│   │   └─ database.ts
│   ├── tests/
│   │   └─ inquiry.test.ts
│   └── index.ts
├── tests/
├── .env.example
├── package.json
└── tsconfig.json

Core Engineering Principles



  - Single Responsibility and clear separation of concerns

  - Security by design: validation, least privilege, secret management

  - Idempotent webhook handling and deterministic classification

  - Observability: structured logs, metrics, and tracing

  - Testability: unit, integration, and CI/CD automation



Code Construction Rules



  - Use a strict TypeScript schema for incoming WhatsApp payloads and classification results

  - Implement a two stage classification: heuristic rules first, optional Cursor AI model second

  - All database access must be parameterized; never interpolate user input into SQL

  - Webhook processing must be idempotent; deduplicate on event IDs

  - Do not hardcode secrets; read from environment variables or a vault

  - API responses should be deterministic and include status codes per REST conventions



Security and Production Rules



  - Validate origin of WhatsApp webhooks and verify signatures

  - Encrypt sensitive data at rest and in transit; rotate keys regularly

  - Limit concurrency and enforce timeouts for external calls to WhatsApp API

  - Implement feature flags to disable classification in case of issues



Testing Checklist



  - Unit tests for classification rules and payload parsing

  - Integration tests for webhook routing and database writes

  - End to end tests simulating WhatsApp inbound messages

  - CI: lint, typecheck, tests, build, and deploy in staging



Common Mistakes to Avoid



  - Relying on ML for critical routing without rules

  - Hard coding business logic in route handlers

  - Neglecting secret management and webhook verification

  - Ignoring input normalization causing inconsistent classifications



Related implementation resources: AI Agent Use Case for Local Service SMEs Using WhatsApp Messages to Auto-Classify Inquiries and Generate Replies and Production-Grade SSO for Enterprise SaaS: Patterns.





FAQ


What is a Cursor Rules Template?


A Cursor Rules Template provides a copyable .cursorrules block and scaffolding tailored to a specific stack. This page centers on a WhatsApp inquiry classification workflow for local service SMEs using Cursor AI in a Node.js backend.


Which stack does this template target?


The template targets a Node.js + TypeScript backend with PostgreSQL and the WhatsApp Business API, integrated with Cursor AI for rule based classification and routing.


How do I test webhook handling?


Test webhook handling by mocking WhatsApp payloads, validating signature checks, and performing end to end tests that simulate inbound messages and classification outcomes. Use a dedicated test environment, such as a WhatsApp sandbox account.


What should not be done in production?


Avoid storing raw WhatsApp payloads beyond transient processing, avoid leaking API keys in logs, and always verify webhooks. Ensure TLS and secret rotation are in place.


How should I deploy this template?


Use CI/CD to lint, compile, run tests, and deploy to staging. After validation, promote to production with secret rotation and monitoring for latency and classification accuracy.