A Cursor rules file aimed at GTM engineers wiring up the modern outbound stack: Clay tables, Smartlead campaigns, Apollo enrichment, n8n orchestration, and the inevitable Python glue between them. Pushes the model toward small composable scripts, explicit rate-limit handling, and the kind of observability that survives a Monday morning.
What you’ll need
- Cursor with rules support
- A repo for your GTM scripts and flows (mono- or per-tool)
- API credentials for the tools you actually use, in a secret manager
Setup
- Drop the rules file. Place
gtm-engineer.mdcin.cursor/rules/. Sections cover Clay HTTP columns, Smartlead campaign operations, Apollo bulk enrichment, n8n authoring, Python utilities. - Pin the tool versions. GTM tool APIs evolve weekly. The rules file references current endpoint shapes; lock them and bump on a cadence rather than per-task.
- Configure the rate-limit defaults. The rules push the model toward exponential backoff with jitter, max retries, and a circuit breaker after three consecutive failures. Edit the defaults to match each tool’s actual limits.
- Add the observability stub. The rules direct the model to wire every script with a structured logger and a “summary at the end” pattern. Point it at your logging destination.
How it works
GTM engineering is integration work in disguise. The Cursor rules optimize for that reality. When the user asks for “a script that pulls Clay results and pushes to Smartlead,” the rules force the model to ask “what is the Clay table ID, what is the Smartlead campaign ID, where does the script run, what happens on partial failure” before writing code. That single prompt-shaping intervention saves more time than any other rule in the file.
The rules also push toward idempotence. Most GTM scripts run on a schedule; the second run should not double-enroll leads or duplicate sequence sends. The rules require a dedupe key on every write operation.
Watch-outs
- API surface drift. Smartlead and Apollo ship breaking changes quarterly. A rule referencing a deprecated endpoint generates broken code. Diff against changelogs monthly.
- Secret leakage. GTM scripts touch a lot of credentials. The rules ban inline secrets but the model will sometimes embed example tokens in tests. Add a pre-commit hook that scans for keys.
- Over-orchestration. Engineers reach for n8n when a fifteen-line Python script would do. The rules push toward “use n8n for human-in-the-loop, scripts for everything else.” Hold the line.
- Logging volume. Structured logs on every operation in a hundred-thousand-row enrichment run will bury your log destination. The rules cap default verbosity at INFO with DEBUG behind a flag.
Stack
- Cursor — IDE and rules engine
.cursor/rules— versioned, reviewed, environment-pinned- Secret manager — referenced from rules, never inline