Cursor Rules Template: Podcast Management Stack

Overview

Direct answer: This Cursor Rules Template provides a copyable .cursorrules block for building a Podcast Management Platform with guest CRM, episode planning, transcripts, clips, and publishing workflows on a Node.js Express + PostgreSQL + Redis stack.

The Cursor rules configuration defines how Cursor AI should reason about architecture, code style, security, data modeling, testing, and deployment for this stack. It targets a full backend system built with Node.js and Express, stores data in PostgreSQL, and uses Redis for caching and queueing, enabling guest CRM, episode planning, transcripts, clips, and publishing workflows.

When to Use These Cursor Rules

When you need a repeatable backend blueprint for a podcast platform with guest CRM, episode planning, transcripts, clips, and publishing workflows.
When you want a copyable .cursorrules block that you can paste into project roots to guide Cursor AI during implementation.
When security, testing, and CI/CD are requirements from day one, not as afterthoughts.

Copyable .cursorrules Configuration

# .cursorrules
framework: nodejs-express
language: typescript
runtime: node-18
stack: postgresql, redis
root: ./src
rules:
  - role: 'Framework Role & Context'
    content: |
      You are Cursor AI configured to implement a Podcast Management Platform with guest CRM, episode planning, transcripts, clips, and publishing workflows using Node.js and Express. Target PostgreSQL and Redis for durable storage and caching. You must provide concrete code and structure, avoiding unsafe shortcuts.
  - role: 'Code Style and Style Guides'
    content: |
      Use TypeScript with strict types, ESLint, and Prettier. Prefer camelCase, clear JSDoc, and well-typed APIs.
  - role: 'Architecture & Directory Rules'
    content: |
      Project layout:
      /src
        /server
          /controllers
          /routes
          /middlewares
          /services
        /db
          /migrations
          /models
          /seeds
        /modules
          /guest
          /episodes
          /transcripts
          /publishing
        /utils
      /tests
  - role: 'Authentication & Security Rules'
    content: |
      Use JWT with RS256, store secrets in environment vars, implement role-based access control, rotate keys, audit logs for sensitive actions.
  - role: 'Database and ORM patterns'
    content: |
      PostgreSQL with pg and Knex. Use parameterized queries, migrations, indexes on foreign keys, and hashed credentials with bcrypt.
  - role: 'Testing & Linting Workflows'
    content: |
      Jest for unit tests, SuperTest for integration tests, GitHub Actions for CI, run linting on commit, and run type checks.
  - role: 'Prohibited Actions and Anti-patterns'
    content: |
      Do not bypass authentication, do not execute code from untrusted sources, avoid dynamic eval, do not bypass migrations or seed data in prod.

Recommended Project Structure

podcast-platform/
├── src/
│   ├── server/
│   │   ├── controllers/
│   │   │   ├── guestController.ts
│   │   │   ├── episodeController.ts
│   │   │   ├── transcriptController.ts
│   │   │   └── publishController.ts
│   │   ├── routes/
│   │   │   ├── guestRoutes.ts
│   │   │   ├── episodeRoutes.ts
│   │   │   ├── transcriptRoutes.ts
│   │   │   └── publishRoutes.ts
│   │   ├── middlewares/
│   │   │   └── authMiddleware.ts
│   │   └── services/
│   │       ├── guestService.ts
│   │       ├── episodeService.ts
│   │       ├── transcriptService.ts
│   │       └── publishingService.ts
│   ├── db/
│   │   ├── migrations/
│   │   ├── models/
│   │   │   ├── Guest.ts
│   │   │   ├── Episode.ts
│   │   │   ├── Transcript.ts
│   │   │   └── Clip.ts
│   │   └── seeds/
│   ├── modules/
│   │   ├── guest/
│   │   ├── episodes/
│   │   ├── transcripts/
│   │   └── publishing/
│   └── utils/
├── tests/
├── .eslintrc.js
├── tsconfig.json
├── knexfile.js
└── package.json

Core Engineering Principles

Strong typing and explicit contracts across modules and APIs.
Clear separation of concerns between data access, business logic, and HTTP handling.
Idempotent and retry-friendly operations for publishing workflows.
Observability: structured logs, metrics, and tracing for all critical paths.
Security-by-default with RBAC, proper secret management, and validated inputs.
Reliable data modeling with migrations and versioned schemas.
Continuous integration, linting, and automated tests for maintainability.

Code Construction Rules

Use TypeScript with strictNullChecks and noImplicitAny enabled.
Define DTOs for request/response payloads and validate with a schema library (e.g., Zod).
Implement a repository layer for PostgreSQL access via Knex; avoid raw queries sprinkled across services.
Keep business logic in services; controllers should delegate to services and return HTTP responses.
All secrets come from environment variables; never hardcode credentials.
Migrations must be used for all schema changes; rely on idempotent seeds for test data.
Authentication uses JWTs with RS256; enforce RBAC for guest, admin, and producer roles.
Do not use dynamic code execution or eval; sanitize all inputs and escape outputs.

Security and Production Rules

Transport Layer Security (TLS) in all environments; enforce HSTS in production.
Store secrets in a dedicated vault or environment-based config; rotate keys on schedule.
Implement rate limiting and IP-based throttling for public endpoints.
Enable audit logging for critical actions like publishing and guest data access.
Use parameterized queries to prevent SQL injection; validate all inputs server-side.
Regularly patch dependencies and run dependency vulnerability scans in CI.

Testing Checklist

Unit tests for service methods and validation logic.
Integration tests for routes and data access with a test database.
End-to-end tests for guest CRM, episode planning, transcripts, and publishing flows.
Migration tests to ensure schema changes apply cleanly in CI.
Static type checks and linting as part of the pre-commit and CI steps.

Common Mistakes to Avoid

Ignoring input validation and relying on client-side checks.
Over-complicating the domain model; avoid circular dependencies between modules.
Forgetting to index foreign keys in PostgreSQL for querying performance.
Hardcoding production endpoints in code or secrets in repository history.
Skipping migrations in favor of ad-hoc schema changes in production.

Related Cursor rules templates

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

FAQ

What is this Cursor Rules Template for Podcast Management?

It provides a copyable .cursorrules configuration and a blueprint for implementing a complete podcast platform backend, including guest CRM, episode planning, transcripts, clips, and publishing workflows on a Node.js Express + PostgreSQL + Redis stack.

Which stack does this template target?

The template targets a Node.js and Express backend, PostgreSQL as the RDBMS, and Redis for caching and queues, with TypeScript, Knex, and JWT-based auth. It emphasizes clean architecture and secure, testable code.

How do I use the copyable .cursorrules block?

Copy the entire code block under Copyable .cursorrules Configuration and paste it into a .cursorrules file at your project root. Update any framework-specific paths or environment-specific values as needed before running Cursor AI.

What security considerations are included?

RBAC, RS256 JWTs, environment-based secrets, input validation, and audit logging are included. The configuration forbids bypassing authentication or using unsafe runtime evals in production paths.

Can I adapt this for GraphQL or REST?

Yes. The rules emphasize REST-style controllers and service layers but can be extended to GraphQL by adding a GraphQL module and resolver layer while preserving the underlying security and validation principles.

How should I test this template?

Use unit tests for services, integration tests for endpoints, and CI pipelines that run migrations, linting, type checks, and test suites on every pull request.

Target User

Use Cases