Un archivo de Cursor rules afinado para RevOps engineers que hacen ship de SOQL, Apex, scripts de HubSpot, flows de n8n y modelos dbt sobre datos de revenue. Empuja al modelo hacia escrituras idempotentes, manejo explícito de errores y las convenciones que tu equipo realmente usa. Colócalo en .cursor/rules y deja de relitigar “esto debería ser un workflow o un flow” con el assistant.

Lo que vas a necesitar

Cursor (cualquier versión reciente con soporte de rules)
Un monorepo o un repo por herramienta donde vivirán las reglas
El doc de convenciones de código de tu equipo, aunque sea una página de Notion a medias

Setup

Crea el archivo de reglas. Coloca revops-engineer.mdc en .cursor/rules/. El archivo está dividido en secciones: SOQL y Apex, código custom de HubSpot, autoría de n8n, dbt y SQL, manejo de secretos.
Edita la sección de convenciones. El archivo trae defaults sensatos pero tu equipo tiene opiniones: Apex bulkificado, nada de SOQL anónimo, flows de n8n sobre webhooks primero. Sobreescribe los defaults.
Configura la política de secretos. Las reglas prohíben credenciales hardcoded y dirigen al modelo hacia tu secret manager de elección (1Password CLI, Doppler, AWS Secrets Manager). Elige uno.
Pruébalo en una tarea típica. Pídele a Cursor “escribe una HubSpot custom code action que actualice un stage de deal cuando un contacto envíe un formulario”. La salida debería seguir tus convenciones desde el inicio.

Cómo funciona

Las Cursor rules aplican a cada prompt del workspace. El archivo de reglas está estructurado como una serie de directivas “cuando trabajes con X, prefiere Y, evita Z”. Para trabajo de Salesforce, las reglas empujan hacia patrones bulkificados y chequeos explícitos de límites. Para código custom de HubSpot, empujan hacia el cliente v4 y lejos de endpoints deprecados. Para n8n, empujan hacia credenciales tipadas y lejos de secretos inline.

Las reglas más valiosas son las negativas. “No escribas Apex anónimo cuando un deploy es factible”. “No pongas lógica de filtro en nodos IF de n8n cuando un nodo Code es más claro”. “No generes modelos dbt sin un test unique en la primary key”. Las reglas negativas cortan más output malo del que las positivas agregan output bueno.

Cuídate de

Drift de reglas. Los equipos agregan reglas y nunca las quitan. Revisión trimestral o el archivo se vuelve un museo.
Reglas en conflicto. Cursor aplica todas las reglas que matcheen; directivas en conflicto producen salida confundida. Mantén el archivo bajo trescientas líneas.
Churn de versiones de herramientas. “Usa el cliente v4 de HubSpot” se vuelve incorrecto cuando v5 sale. Etiqueta las reglas con versión donde importe.
Overrides por repo. Una regla que tiene sentido en tu repo de forecasting puede no tenerlo en el de lead-routing. Usa el soporte de reglas por directorio de Cursor.

Stack

Cursor — IDE y motor de reglas
Directorio .cursor/rules — committed, versionado, code-reviewed
Doc de convenciones — la fuente de verdad que las reglas referencian