Cursor Rules Template: Newsletter Platform with Subscriptions, Campaigns, Segmentation, Payments and AI Writing Assistant

Overview

Direct answer: This Cursor rules configuration delivers a copyable Cursor rules template tailored for a Node.js/TypeScript newsletter platform with subscribers, campaigns, segmentation, Stripe payments, and an AI writing assistant using Cursor AI. It codifies stack-specific patterns to guide development, testing, and security for production workloads.

When to Use These Cursor Rules

• You are building a modern newsletter platform with subscriptions and payments (Stripe) from the ground up.
• You need clear architectural guidance for modules like subscribers, campaigns, segmentation, and payments.
• You want an AI writing assistant to help generate campaign content and subject lines while enforcing safe AI usage.
• You require a copyable, paste-ready configuration to seed your project root and CI pipelines.

Copyable .cursorrules Configuration

.cursorrules
Framework Role & Context:
- You are Cursor AI assistant specialized in building production-grade Node.js/TypeScript (NestJS-like) services for a newsletter platform with subscribers, campaigns, segmentation, payments (Stripe), and an AI writing assistant.

Code Style and Style Guides:
- TypeScript, ESLint, Prettier, JSDoc, strict mode, noImplicitAny

Architecture & Directory Rules:
- Monorepo structure: src/core, src/api, src/subscribers, src/campaigns, src/segmentation, src/payments, src/ai-writer; shared libs; migrations; tests

Authentication & Security Rules:
- JWT-based authentication; Stripe webhook verification; RBAC; input validation; avoid leaking secrets

Database and ORM patterns:
- PostgreSQL; TypeORM-like patterns; entities with relations; migrations; repositories; strict typing

Testing & Linting Workflows:
- Jest unit tests; Supertest for API; CI runs lint, test coverage & type checks

Prohibited Actions and Anti-patterns for the AI:
- Do not embed secrets in prompts; Do not bypass server validation; Do not generate unsafe code paths; Do not generate direct SQL without parameterization

Recommended Project Structure

newsletter-platform/
├─ src/
│  ├─ api/
│  │  ├─ main.ts
│  │  └─ routes/
│  ├─ core/
│  │  ├─ config/
│  │  └─ lib/
│  ├─ subscribers/
│  │  ├─ entities/
│  │  └─ services/
│  ├─ campaigns/
│  │  ├─ entities/
│  │  └─ services/
│  ├─ segmentation/
│  ├─ payments/
│  ├─ ai-writer/
│  └─ tests/

Core Engineering Principles

• Single Responsibility and modularized boundaries between domains (subscribers, campaigns, segmentation, payments, AI writer).
• Strong typing and explicit interfaces to prevent implicit behavior.
• Security by default: input validation, strict auth, validated webhooks, and secret management.
• Observability: structured logging, metrics, tracing for key flows (payments, campaign delivery).
• Idempotency and event-driven patterns for payments and campaign events.

Code Construction Rules

• Use DTOs for all external inputs and output shape enforcement.
• Encapsulate business logic in domain services; keep controllers thin.
• Prefer repository/ORM patterns with typed queries and parameterization to avoid SQL injection.
• All external calls go through a single gateway service; mockable in tests.
• Documentation: JSDoc on public methods and business rules.
• Linting and formatting enforced in CI; pre-commit hooks for formatting.

Security and Production Rules

• Store secrets in environment variables or vault; never commit secrets.
• Validate all inputs; use CSRF protection for browser-based flows; sign and verify Stripe webhooks.
• Do not expose raw database errors to clients; surface friendly error messages.
• Implement daily backups and point-in-time recovery for PostgreSQL; monitor for failures.
• Maintain idempotency keys for payment operations to avoid double-charging.

Testing Checklist

• Unit tests for domain services and utilities.
• Integration tests for subscribers, campaigns, and payments flows.
• End-to-end tests for campaign delivery and AI writing prompts.
• CI/CD validation: lint, type check, test coverage, security checks.

Common Mistakes to Avoid

• Mixing domain logic into controllers or API layer.
• Unparameterized queries or manual SQL risk; avoid raw SQL in services.
• Hard-coding secret keys; rely on environment configs.
• Ignoring idempotency for webhook-driven flows.

Related Cursor rules templates

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

• Cursor Rules Template: SaaS Metrics Dashboard with Stripe Integration
• Cursor Rules Template — Real Estate Dashboard with Cash Flow, ROI, and Analytics
• Cursor Rules Template: Django Subscription Box Platform
• Cursor Rules Template for Vendor Management SaaS (Contracts, Compliance, Renewals, AI Risk)

FAQ

What is a Cursor Rules Template for a newsletter platform?

A Cursor Rules Template provides a production-ready, copyable .cursorrules configuration and implementation guidance to build a complete newsletter platform with subscribers, campaigns, segmentation, payments, and an AI writing assistant using Cursor AI.

Which stack and tooling does this template target?

The template targets Node.js with TypeScript (NestJS-like structure), PostgreSQL for data, Stripe for payments, SendGrid for emails, and Cursor AI for content creation and guardrails.

How do I paste and customize the .cursorrules into my project?

Copy the .cursorrules block from the Copyable section and place it in your project root as .cursorrules. Update module names, environment references, and any region-specific settings before running CI.

How does the template handle payments and webhook security?

It prescribes Stripe webhook verification, idempotent operations, and secure endpoints. Webhooks trigger state changes for subscribers and campaigns with proper error handling.

Can I customize AI writing prompts and guardrails?

Yes. The template includes configurable prompts and guardrails to control tone, style, safety, and length for campaign content, subject lines, and long-form pieces.