CRM Lead Scoring with Notes, Emails, and Deals — Cursor Rules Template

Overview

This Cursor rules configuration provides a precise, repeatable prompt set for building a CRM lead scoring tool that leverages notes, emails, and deal history. It targets a TypeScript/Node.js backend with PostgreSQL, and enforces data-access controls, deterministic scoring, and testable workflows with Cursor AI. The direct answer: paste the included .cursorrules block into your project root to standardize AI guidance across data signals, scoring rules, and deployment checks.

When to Use These Cursor Rules

• When you need a consistent scoring funnel based on notes, email interactions, and deal progression.
• When integrating signals from CRM records into a single, auditable score.
• When you require deterministic prompts that are easy to test and review in CI.
• When ensuring data access is restricted to authorized services and users.

Copyable .cursorrules Configuration

# Cursor Rules Template — CRM Lead Scoring (Notes, Emails, Deals)
# Framework Role & Context
Framework: TypeScript/Node.js backend with PostgreSQL
Context: You are Cursor AI configured to assist building a CRM lead scoring tool. Signals come from notes, emails, and deal history stored in PostgreSQL. Produce deterministic prompts, scoring rules, and validation hooks.

# Code Style and Style Guides
CodeStyle: TypeScript with strict types; ESLint + Prettier; Prettier formatting; no trailing semicolon ambiguities
Naming: camelCase for functions, PascalCase for types; explicit types everywhere
Documentation: inline JSDoc for public APIs

# Architecture & Directory Rules
Architecture: Layered clean architecture with clear separation of concerns
Directories:
  src/
    models/        # TypeScript interfaces and ORM-like schemas
    services/      # Scoring, enrichment, and business logic
    adapters/      # DB access, email/notes pulls, deal history fetchers
    routes/        # API endpoints for CRM integrations
    tests/         # Unit and integration tests
    config/        # Environment and feature flags

# Authentication & Security Rules
Auth: JWT bearer tokens; scopes for read/write lead data; never log PII; mask email bodies in logs; audit trail on scoring decisions
Input Sanitization: validate all inputs; escape SQL inputs; enforce field length limits
Data Access: least privilege; DB operations wrapped in transactions with retry logic

# Database and ORM patterns
DB: PostgreSQL; use parameterized queries; avoid dynamic SQL composition
Signals Model: notes, emails, and deals map to LeadSignal entities with timestamps and source identifiers
ScoringModel: deterministic function mapping signals to a LeadScore
Migrations: idempotent SQL migrations in migrations/ folder

# Testing & Linting Workflows
Tests: Jest-based unit tests for scoring logic; integration tests for DB writes/reads; CI runs lint, test, and type-check
CI: GitHub Actions or equivalent; run tests on PRs; fail CI on flaky tests; require 100% type coverage where feasible

# Prohibited Actions and Anti-patterns for the AI
Do not: manipulate live CRM data directly; call external services without explicit permission; rely on non-deterministic prompts for scoring decisions
Avoid: business logic sprinkled in prompts; opaque shortcuts defeating auditability

# Example: Lead Scoring Function (sketch)
interface Lead { id: string; notes: string[]; emails: string[]; deals: { id:string; stage:string; amount:number; closeDate?:string }[]; }
interface Signal { type:'note'|'email'|'deal'; value:string; ts:number }
function computeLeadScore(lead: Lead, signals: Signal[]): number { /* deterministic scoring logic using signals */ return signals.length + (lead.deals?.length ?? 0) * 2; }

Recommended Project Structure

project-root/
  src/
    models/
      lead.ts
      signal.ts
    services/
      scoring.ts
      enrichment.ts
    adapters/
      db.ts
      signals.ts
      auth.ts
    routes/
      leads.ts
    tests/
      scoring.test.ts
      integration.test.ts
    config/
      env.ts
  migrations/
  migrations/202405_crm_init.sql
  .eslintrc.json
  .prettierrc
  tsconfig.json
  package.json

Core Engineering Principles

• Single source of truth for lead signals and scores
• Deterministic, testable scoring logic with explicit inputs
• Data privacy and least-privilege access
• Observability: structured logs and metrics for scoring decisions
• Continuous testing and incremental deployment

Code Construction Rules

• Define strong TS interfaces for Lead, Signal, and Score
• Use parameterized SQL; avoid concatenated queries
• Keep scoring logic in services/, not in routes or adapters
• Test scoring functions with varied signal sets and edge cases
• Document API contracts with JSDoc; include input/output schemas
• Do not hard-code secrets; use environment variables

Security and Production Rules

• Store DB credentials in a secure vault; rotate credentials
• Encrypt sensitive signals in transit and at rest where feasible
• Validate input lengths and formats; log sanitized summaries only
• Enable TLS for all endpoints; implement rate limiting and IP allowlists
• Audit scoring decisions and data access; maintain immutable logs

Testing Checklist

• Unit tests for computeLeadScore with diverse signals
• Integration tests for DB reads/writes and transaction boundaries
• End-to-end tests simulating CRM lead creation and scoring workflow
• Linting and type-checking in CI; run Prettier formatting checks
• Security tests for input validation and auth scopes

Common Mistakes to Avoid

• Mixing business logic with data access or API layers
• Ignoring time zones in deal closeDate and signal timestamps
• Overcomplicating scoring rules; avoid opaque heuristics
• Logging raw PII from notes/emails
• Skipping tests for edge cases (no signals, missing deals)

Related implementation resources: AI Agent Use Case for B2B SMEs Using CRM Notes to Identify Warm Leads and Next Best Actions and Implementing Parameterized Testing Matrices for Wide Input Coverage in Production AI.

FAQ

What is the purpose of this Cursor Rules Template?

The template standardizes Cursor AI prompts to build a CRM lead scoring tool using notes, emails, and deal history, ensuring repeatable, auditable scoring behavior in a TypeScript/PostgreSQL stack.

How do I adapt this for PostgreSQL-backed signals?

Use parameterized SQL queries, store signals in LeadSignal tables, and implement deterministic score calculation in a scoring service. The prompts guide AI to operate within those DB rules and schemas.

How should I test the lead scoring logic?

Create unit tests for computeLeadScore with synthetic signals, integration tests for database reads/writes, and CI checks for linting and type-safety. Use mock data reflecting notes, emails, and deals.

How do I handle PII in notes and emails?

Do not log full bodies or identifiers. Redact sensitive content from logs, use field-level access controls, and store only necessary signals for scoring.

How can I integrate with an existing CRM?

Expose a stable scoring API, align lead and deal schemas to CRM fields, and ensure backward compatibility when changing scoring rules. Use webhooks or api routes to push scores to the CRM on changes.