Um arquivo de Cursor rules direcionado a GTM engineers que cabeiam o stack moderno de outbound: tabelas de Clay, campanhas de Smartlead, enrichment do Apollo, orquestração com n8n e a inevitável cola de Python entre tudo. Empurra o modelo pra scripts pequenos e composáveis, tratamento explícito de rate limits e o tipo de observabilidade que sobrevive uma segunda de manhã.
O que você vai precisar
- Cursor com suporte a rules
- Um repo pros seus scripts e flows de GTM (mono ou por ferramenta)
- Credenciais de API pras ferramentas que você de fato usa, num secret manager
Setup
- Coloque o arquivo de rules. Ponha
gtm-engineer.mdcem.cursor/rules/. As seções cobrem colunas HTTP do Clay, operações de campanha do Smartlead, enrichment em massa do Apollo, autoria de n8n, utilitários em Python. - Fixe as versões das ferramentas. APIs de ferramentas GTM evoluem semanalmente. O arquivo de rules referencia formatos atuais de endpoint; fixe e bumpe em cadência em vez de por tarefa.
- Configure os defaults de rate-limit. As rules empurram o modelo pra exponential backoff com jitter, máximo de retries e um circuit breaker depois de três falhas seguidas. Edite os defaults pra bater com os limites reais de cada ferramenta.
- Adicione o stub de observabilidade. As rules direcionam o modelo a cabear cada script com um logger estruturado e um padrão “resumo no final”. Aponte pro seu destino de logging.
Como funciona
GTM engineering é trabalho de integração disfarçado. As Cursor rules otimizam pra essa realidade. Quando o usuário pede “um script que puxa resultados do Clay e empurra pro Smartlead”, as rules forçam o modelo a perguntar “qual o table ID do Clay, qual o campaign ID do Smartlead, onde o script roda, o que acontece em falha parcial” antes de escrever código. Essa única intervenção de prompt-shaping economiza mais tempo do que qualquer outra rule do arquivo.
As rules também empurram pra idempotência. A maioria dos scripts GTM rodam agendados; a segunda rodada não deveria duplicar enrolamento de leads nem duplicar envios de sequência. As rules exigem uma chave de dedupe em cada operação de escrita.
Pontos de atenção
- Drift de superfície de API. Smartlead e Apollo dão ship em mudanças breaking trimestralmente. Uma rule referenciando um endpoint deprecado gera código quebrado. Faça diff contra changelogs mensalmente.
- Vazamento de secrets. Scripts GTM tocam muitas credenciais. As rules banem secrets inline mas o modelo às vezes embute tokens de exemplo em testes. Adicione um pre-commit hook que escaneia chaves.
- Sobre-orquestração. Engineers vão pro n8n quando um script de Python de quinze linhas resolveria. As rules empurram pra “use n8n pra human-in-the-loop, scripts pra todo o resto”. Segure a linha.
- Volume de logs. Logs estruturados em cada operação numa rodada de enrichment de cem mil linhas vão soterrar seu destino de logs. As rules limitam a verbosidade padrão a INFO com DEBUG atrás de uma flag.
Stack
- Cursor — IDE e engine de rules
.cursor/rules— versionado, revisado, fixado por ambiente- Secret manager — referenciado nas rules, nunca inline