A Cursor rules file tuned for RevOps engineers shipping SOQL, Apex, HubSpot scripts, n8n flows, and dbt models against revenue data. Forces the model toward idempotent writes, explicit error handling, and the conventions your team actually uses. Drop it in .cursor/rules and stop relitigating “should this be a workflow or a flow” with the assistant.

What you’ll need

Cursor (any recent version with rules support)
A monorepo or a per-tool repo where the rules will live
Your team’s coding conventions doc, even if it is a half-finished Notion page

Setup

Create the rules file. Drop revops-engineer.mdc in .cursor/rules/. The file is split into sections: SOQL and Apex, HubSpot custom code, n8n authoring, dbt and SQL, secrets handling.
Edit the conventions section. The rules file ships with sensible defaults but your team has opinions: bulkified Apex, no anonymous SOQL, n8n flows over webhooks first. Override the defaults.
Set the secrets policy. The rules ban hardcoded credentials and direct the model toward your secret manager of choice (1Password CLI, Doppler, AWS Secrets Manager). Pick one.
Test on a typical task. Ask Cursor to “write a HubSpot custom code action that updates a deal stage when a contact submits a form.” The output should follow your conventions out of the box.

How it works

Cursor rules apply to every prompt in the workspace. The rules file is structured as a series of “when working with X, prefer Y, avoid Z” directives. For Salesforce work, the rules push toward bulkified patterns and explicit limits checks. For HubSpot custom code, they push toward the v4 client and away from deprecated endpoints. For n8n, they push toward typed credentials and away from inline secrets.

The most valuable rules are the negative ones. “Do not write anonymous Apex when a deploy is feasible.” “Do not put filter logic in n8n IF nodes when a Code node is clearer.” “Do not generate dbt models without a unique test on the primary key.” Negative rules cut more bad output than positive ones add good output.

Watch-outs

Rule drift. Teams add rules and never remove them. Quarterly review or the file becomes a museum.
Conflicting rules. Cursor applies all matching rules; conflicting directives produce confused output. Keep the file under three hundred lines.
Tool version churn. “Use the v4 HubSpot client” becomes wrong when v5 ships. Version-tag rules where it matters.
Per-repo overrides. A rule that makes sense in your forecasting repo may not in the lead-routing repo. Use Cursor’s per-directory rule support.

Stack

Cursor — IDE and rules engine
.cursor/rules directory — checked-in, versioned, code-reviewed
Conventions doc — the source of truth the rules reference