Um arquivo de Cursor rules afinado pra RevOps engineers que dão ship em SOQL, Apex, scripts de HubSpot, flows de n8n e modelos dbt em cima de dados de revenue. Empurra o modelo pra escritas idempotentes, tratamento explícito de erros e as convenções que seu time realmente usa. Coloque em .cursor/rules e pare de relitigar “isso devia ser um workflow ou um flow” com o assistant.

O que você vai precisar

Cursor (qualquer versão recente com suporte a rules)
Um monorepo ou um repo por ferramenta onde as rules vão viver
O doc de convenções de código do seu time, mesmo que seja uma página de Notion pela metade

Setup

Crie o arquivo de rules. Coloque revops-engineer.mdc em .cursor/rules/. O arquivo é dividido em seções: SOQL e Apex, código custom de HubSpot, autoria de n8n, dbt e SQL, manuseio de secrets.
Edite a seção de convenções. O arquivo vem com defaults sensatos mas seu time tem opiniões: Apex bulkificado, nada de SOQL anônimo, flows de n8n antes de webhooks. Sobrescreva os defaults.
Configure a política de secrets. As rules banem credenciais hardcoded e direcionam o modelo pro secret manager da sua escolha (1Password CLI, Doppler, AWS Secrets Manager). Escolha um.
Teste numa tarefa típica. Peça pro Cursor “escreva uma HubSpot custom code action que atualiza um stage de deal quando um contato envia um formulário”. A saída deve seguir suas convenções de cara.

Como funciona

Cursor rules aplicam a cada prompt no workspace. O arquivo de rules é estruturado como uma série de diretivas “quando trabalhar com X, prefira Y, evite Z”. Pra trabalho de Salesforce, as rules empurram pra padrões bulkificados e checagens explícitas de limites. Pra código custom de HubSpot, empurram pro client v4 e longe de endpoints deprecados. Pra n8n, empurram pra credenciais tipadas e longe de secrets inline.

As rules mais valiosas são as negativas. “Não escreva Apex anônimo quando um deploy é viável”. “Não coloque lógica de filtro em nós IF do n8n quando um nó Code é mais claro”. “Não gere modelos dbt sem um teste unique na primary key”. Rules negativas cortam mais output ruim do que as positivas adicionam output bom.

Pontos de atenção

Drift de rules. Times adicionam rules e nunca removem. Revisão trimestral ou o arquivo vira museu.
Rules conflitantes. Cursor aplica todas as rules que dão match; diretivas conflitantes produzem saída confusa. Mantenha o arquivo abaixo de trezentas linhas.
Churn de versão de ferramenta. “Use o client v4 do HubSpot” fica errado quando v5 sai. Etiquete rules com versão onde importa.
Overrides por repo. Uma rule que faz sentido no seu repo de forecasting pode não fazer no de lead-routing. Use o suporte de rules por diretório do Cursor.

Stack

Cursor — IDE e engine de rules
Diretório .cursor/rules — committed, versionado, code-reviewed
Doc de convenções — a fonte de verdade que as rules referenciam