Un archivo de Cursor rules dirigido a GTM engineers que cablean el stack moderno de outbound: tablas de Clay, campañas de Smartlead, enrichment de Apollo, orquestación con n8n y el inevitable pegamento de Python entre todo eso. Empuja al modelo hacia scripts pequeños y composables, manejo explícito de rate limits y el tipo de observabilidad que sobrevive un lunes en la mañana.

Lo que vas a necesitar

Cursor con soporte de rules
Un repo para tus scripts y flows de GTM (mono o por herramienta)
Credenciales de API para las herramientas que realmente usas, en un secret manager

Setup

Coloca el archivo de reglas. Pon gtm-engineer.mdc en .cursor/rules/. Las secciones cubren columnas HTTP de Clay, operaciones de campaña de Smartlead, enrichment masivo de Apollo, autoría de n8n, utilidades de Python.
Fija las versiones de herramientas. Las APIs de herramientas GTM evolucionan semanalmente. El archivo de reglas referencia formas de endpoint actuales; fíjalas y bumpa con cadencia en lugar de por tarea.
Configura los defaults de rate-limit. Las reglas empujan al modelo hacia exponential backoff con jitter, máximo de retries y un circuit breaker después de tres fallos consecutivos. Edita los defaults para que coincidan con los límites reales de cada herramienta.
Agrega el stub de observabilidad. Las reglas dirigen al modelo a cablear cada script con un logger estructurado y un patrón “resumen al final”. Apúntalo a tu destino de logging.

Cómo funciona

GTM engineering es trabajo de integración disfrazado. Las Cursor rules optimizan para esa realidad. Cuando el usuario pide “un script que jale resultados de Clay y los pushee a Smartlead”, las reglas fuerzan al modelo a preguntar “cuál es el table ID de Clay, cuál es el campaign ID de Smartlead, dónde corre el script, qué pasa con fallo parcial” antes de escribir código. Esa única intervención de prompt-shaping ahorra más tiempo que cualquier otra regla del archivo.

Las reglas también empujan hacia idempotencia. La mayoría de los scripts GTM corren agendados; la segunda corrida no debería duplicar enrolamientos de leads ni duplicar envíos de secuencia. Las reglas requieren una clave de dedupe en cada operación de escritura.

Cuídate de

Drift de superficie de API. Smartlead y Apollo hacen ship de cambios breaking trimestralmente. Una regla que referencie un endpoint deprecado genera código roto. Diffea contra changelogs mensualmente.
Filtración de secretos. Los scripts GTM tocan muchas credenciales. Las reglas prohíben secretos inline pero el modelo a veces incrusta tokens de ejemplo en tests. Agrega un pre-commit hook que escanee llaves.
Sobre-orquestación. Los engineers van por n8n cuando un script de Python de quince líneas serviría. Las reglas empujan hacia “usa n8n para human-in-the-loop, scripts para todo lo demás”. Mantén la línea.
Volumen de logs. Logs estructurados en cada operación en una corrida de enrichment de cien mil filas van a sepultar tu destino de logs. Las reglas limitan la verbosidad por defecto a INFO con DEBUG detrás de un flag.

Stack

Cursor — IDE y motor de reglas
.cursor/rules — versionado, revisado, fijado al entorno
Secret manager — referenciado desde reglas, nunca inline