Eine Cursor-.cursorrules-Datei, abgestimmt auf den RevOps-Engineer (oder GTM-Engineering-nahe Person), der SOQL, Apex, HubSpot Custom Code, n8n-Flows und dbt-Modelle gegen Revenue-Daten schreibt. Das Artifact ist eine einzige Datei – apps/web/public/artifacts/cursor-rules-revops-engineer/.cursorrules – die Sie in das Verzeichnis .cursor/rules/ Ihres Projekts ablegen und aufhören, für den Rest des Quartals „sollte das bulkifiziert werden” oder „brauchen wir einen dbt-Test auf diesem Modell” mit dem KI-Assistenten zu streiten.
Die definierende Eigenschaft von RevOps-Code ist, dass er die Pipeline-Zahlen berührt, über die der CRO beim nächsten Earnings-Call berichten wird. Ein duplizierter Write im großen Maßstab, ein fehlender Dedupe-Schlüssel oder ein Stage-Progressions-Bug bricht nicht nur ein Skript – er bricht die Prognose. Die Regeln in diesem Bundle kodieren Bulkifizierung, Idempotenz, explizite Limits-Prüfungen und konservative Writes, damit Cursors Vorschläge den tatsächlichen Blast Radius eines RevOps-Fehlers widerspiegeln.
Wann einsetzen
Sie sind ein RevOps-Engineer, GTM-Engineer oder RevOps-Manager, der Integrationscode (Python, TypeScript, Apex, n8n-Flows, dbt-Modelle) gegen Salesforce oder HubSpot schreibt. Ihr Team liefert mindestens einige Änderungen pro Monat, die Pipeline-Daten berühren. Cursor ist Ihre IDE.
Wann NICHT einsetzen
Sie führen keine Engineering-Praxis in RevOps – Ihre „Automatisierung” sind admin-gebaute Workflows in der CRM-UI, kein Code in einem Repository. Die Regeln setzen Code-Reviews, Versionskontrolle und eine Deployment-Pipeline voraus; sie helfen einer Config-only-Org nicht.
Sie sind ein externer SI, der Salesforce-Lösungen für Clients aufbaut. Die Regeln sind auf den Inhouse-Operator abgestimmt, der die Konsequenzen jahrelang trägt; Berater-Wirtschaftlichkeit ist anders (Lieferumfang, Übergabedokumentation, Post-Engagement-Support-Modell).
Sie liefern ein Marketing-Attributions-Feature in Ihrem Produkt. Die Regeln sind für Ops-Engineering innerhalb des Unternehmens, das ein CRM verwendet, nicht für Engineering-Teams, die CRM-angrenzende Produkte bauen.
Setup
Artifact kopieren..cursorrules aus dem Bundle oben (oder Zip herunterladen) und in das Verzeichnis .cursor/rules/ ablegen. Cursors Project-Rules-Indikator bestätigt das Laden.
Tool-Abschnitte trimmen. Die Datei wird mit Abschnitten für Salesforce (SOQL/Apex), HubSpot Custom Code, n8n und dbt geliefert. Abschnitte löschen, die Sie nicht verwenden – Guidance, gegen die das Modell abwägen muss und die irrelevant ist, verdünnt das Signal.
Secrets-Richtlinie festlegen. Die Regeln verbieten fest kodierte Zugangsdaten und weisen das Modell auf Ihren Secret Manager hin. Den Abschnitt „Secrets und Zugang” bearbeiten, damit das Modell den richtigen Aufruf vorschlägt (1Password CLI, Doppler, AWS Secrets Manager, Vault – einen wählen).
Audit-Destination korrigieren. Mehrere Regeln erfordern eine Audit-Objekt-Referenz (Cleanup_Audit__c ist der Standard-Platzhalter). Auf das tatsächliche Audit-Objekt Ihres Teams bearbeiten, oder die Vorschläge werden einen Namen referenzieren, der in Ihrer Org nicht existiert.
Auf einer repräsentativen Aufgabe testen. Cursor fragen: „Schreibe einen Apex-Trigger, der Last_Activity_Date__c der Opportunity aktualisiert, wann immer ein zugehöriger Task geschlossen wird.” Der Output sollte bulkifiziert sein, eine Limits.getQueries()-Prüfung enthalten, mit einer Test-Klasse geliefert werden und keinen anonymen Apex enthalten. Wenn nicht, sind die Regeln nicht geladen – Cursors Project-Rules-Indikator prüfen.
Was die Regeln tatsächlich tun
Das Bundle ist als fünf Schichten strukturiert, die auf jeden Cursor-Prompt angewendet werden:
Eine „Vor-dem-Code-Schreiben-fragen”-Präambel. Fünf Fragen, die das Modell aufzeigt, bevor generiert wird: welches System ist die Source of Truth, was ist das Datenvolumen, was bedeutet Scheitern für das Revenue-Reporting, ist das einmalig oder wiederkehrend, wer liest den Audit-Trail. Die Fragen klingen offensichtlich. Sie werden nicht oft genug gestellt.
Durchzusetzende Defaults über Bulkifizierung, Idempotenz, Limits/Circuit-Breakers, Observability und Secrets. Jeder Default hat einen konkreten Wert: Bulk-Batches standardmäßig 25 Datensätze, tägliches HubSpot-Quotient hält bei 80 % verbraucht an, n8n-Flows cappen bei 1000 Items pro Ausführung.
Abzulehnende Anti-Pattern. Spezifische Muster, die das Modell ablehnt: anonymes Apex gegen Produktion, HubSpot-Schleifen ohne Circuit Breakers, n8n-IF-Nodes mit 5+ Bedingungen, dbt-Modelle ohne Unique-Tests, direkte Produktions-Writes aus Notebooks.
Ein „Wenn der Benutzer falsch liegt”-Abschnitt. Die Abkürzungen, zu denen Engineers unter Fristenruck greifen, bei denen das Modell zurückschlagen statt ausführen sollte. Die einzige kosten-sparendste Regel: eine Salesforce-Validierungsregel für einen Import zu umgehen verweigern, weil der Bypass Records produziert, die nachgelagerte Reports nicht aggregieren können, was als Prognoseabweichung auftaucht, die der CRO erklären muss.
Kostenrealität
Token-Kosten: null. Cursor-Regeln sind lokaler Kontext, der bei jedem Prompt gesendet wird – keine Per-Request-API-Gebühr jenseits der ~5 KB, die sie im Kontextfenster belegen.
Setup-Zeit: ~10 Minuten, um die Datei abzulegen, den Secret Manager festzulegen, das Audit-Objekt auf einen echten Namen in Ihrer Org zu zeigen.
Per-Aufgaben-Overhead: Die Präambel fügt 1–2 Gesprächsrunden vor der Generierung hinzu. Für ein 3-Zeilen-Skript ist das schwer. Für eine echte Integrationsaufgabe zeigt es Entscheidungen auf, die andernfalls in Code-Review oder einem SOX-Walkthrough auftauchen.
Wartung: ~30 Minuten pro Quartal. SDK-Versionen driften (v3 → v4 bei HubSpot bereits; v4 → v5 wird passieren). Salesforce-Governor-Limits sind über Releases stabil, aber es lohnt sich, sie bei einem Trailhead-Refresh pro Major-Release zu bestätigen.
Wie Erfolg aussieht
Prognoseabweichungen, die auf Datenqualitäts-Bugs zurückzuführen sind, sinken. Bulk-Muster und idempotente Writes verhindern die Doppelzeilen-Bug-Klasse, die Pipeline still aufbläht.
Code-Review konzentriert sich auf Logik, nicht auf „hast du bulkifiziert”. Die Regeln schlagen das Bulk-Muster inline vor; Reviewer hören auf, dessen Abwesenheit zu erkennen.
SOX-Walkthroughs zeigen den Audit-Trail ohne Engineer-Beteiligung auf. Jedes Schreiben produziert eine Zeile in Cleanup_Audit__c (oder Ihr Team-Äquivalent) mit (timestamp, user, object, record_id, field, old_value, new_value) – der Prüfer kann seine Fragen aus dem Audit-Objekt beantworten, nicht aus einem Slack-Thread mit dem Engineer.
Die „das hat früher funktioniert”-Debug-Session über ein veraltetes SDK passiert nicht. Versions-getaggte Regeln stellen sicher, dass das Modell aktuelle Endpunkte verwendet; der veraltete Code betritt nie das Repo.
Vergleich mit Alternativen
Keine Regeln (Status quo). Cursor generiert plausiblen Apex, der bei 200-Datensatz-Last-Tests scheitert. Das erste Mal, wenn das Bulk-Skript still abschneidet und die Prognose um $400K daneben liegt, wird das Fehlen von Regeln zum Engpass.
Ein Team-Coding-Conventions-Dokument in Notion. Funktionell äquivalent zu keinen Regeln – das Dokument wird nicht in den KI-Kontext geladen. Die Cursor-Regeldatei ist das Conventions-Dokument, das bei jedem Prompt geladen wird.
Ein Linter/Static Analyzer (PMD für Apex, dbt-checkpoint für dbt). Erkennt einige Muster, nachdem der Code geschrieben ist. Koexistiert mit den Cursor-Regeln; die Regeln verhindern, dass der Code überhaupt erst geschrieben wird, der Linter erkennt die Fälle, die durchschlüpfen.
Wichtige Hinweise
Regel-Drift. Teams fügen Regeln hinzu und entfernen sie nie. Die Datei wird zu einem Museum der „früher haben wir es so gemacht”-Guidance, die das Modell immer noch anzuwenden versucht. Guard: Vierteljährliche Überprüfung mit git blame – alles älter als 18 Monate wird neu begründet oder gelöscht.
Widersprüchliche Regeln. Cursor wendet alle passenden Regeln an; widersprüchliche Direktiven produzieren verwirrten Output. Harten Cap bei ~300 Zeilen festlegen. Guard: Beim Hinzufügen einer Regel nach bestehenden Regeln auf derselben Oberfläche suchen; konsolidieren statt anhängen.
Tool-Versions-Churn. „Das HubSpot-SDK v4 verwenden” wird falsch, wenn v5 ausgeliefert wird. Guard: Jede Regel, die eine SDK-Version erwähnt, versions-taggen (z. B. # HubSpot SDK v4 (verifiziert 2026-Q2)), damit der nächste Reviewer weiß, wann neu zu prüfen ist.
Per-Repo-Overrides. Eine Regel, die in Ihrem Prognose-Repo richtig ist, kann in Ihrem Lead-Routing-Repo falsch sein (z. B. Write-vs.-Read-Defaults). Cursors Per-Verzeichnis-Regelunterstützung verwenden; die Abweichung in der README des Repos dokumentieren. Guard: Eine gemeinsame Regeldatei mit dokumentierten Ausnahmen gegenüber dem Forken der Datei pro Repo bevorzugen.
Regeln ersetzen keine QA bei Produktionsdaten-Änderungen. Sie formen, was Cursor vorschlägt. Sie laufen nicht in CI, sie validieren nicht die Daten, die das Skript berühren wird, und sie stellen kein SOX-Kontroll dar. Guard: dbt-Tests, Validierungsregeln und Code-Review als separate Durchsetzungsschichten beibehalten.
.cursor/rules/revops-engineer.md — im Repository versioniert, code-überprüft
Secret Manager der Wahl — aus Regeln referenziert, niemals inline
Audit-Objekt — Cleanup_Audit__c oder gleichwertiges benutzerdefiniertes Objekt, explizit namentlich benannt, damit Vorschläge auf den echten Namen zeigen
# RevOps Engineer — Cursor rules
You are pairing with a RevOps engineer (or a GTM-engineering-adjacent person who codes) shipping SOQL, Apex, HubSpot custom code, n8n flows, and dbt models against revenue data. The defining property of RevOps code is that **it touches the pipeline numbers the CRO will report on the next earnings call**. A duplicate write at scale, a missed dedupe key, or a stage-progression bug doesn't just break a script — it breaks the forecast. Bulkification, idempotence, explicit limits checks, and conservative writes are non-negotiable.
## Before writing code, ask
RevOps engineering is integration work plus accounting work in disguise. Before generating any script that touches a CRM, data warehouse, or revenue system, confirm:
1. **What's the source of truth?** Salesforce for opportunities? HubSpot for marketing-qualified leads? Snowflake for reconciled revenue? Code that writes to a non-source-of-truth produces drift the CRO will discover during a board prep. If the user can't name the source of truth for the data class involved, stop and ask.
2. **What's the volume?** A script that runs once over 50 records is different from a job that runs nightly over 5M. Apex governor limits, HubSpot daily API caps, and Salesforce 10K-row transaction ceilings all break at scale. Ask the volume before generating code; the answer changes the architecture.
3. **What does failure mean for revenue reporting?** A failed enrichment script is annoying. A failed deal-stage update miscounts the forecast. The recovery posture differs: enrichment can be retried; deal-stage updates need a compensating transaction.
4. **Is this a one-off or a recurring job?** "One-off" code becomes a cron job in two weeks. Treat every script as if it will run on a schedule — idempotent, retryable, observable.
5. **Who reads the audit trail?** The CFO's auditor will, eventually. Write code that produces a trail an auditor can follow without asking the engineer.
If any answer is missing, ask. RevOps defaults vary across firms in ways that affect financial reporting.
## Tool-specific guidance
### Salesforce: SOQL and Apex
- Bulkify everything. Single-record DML inside a loop is the canonical Apex anti-pattern. Use collections + bulk DML (`insert myList;`).
- Anonymous Apex for production changes is a code smell. If the change is worth making, it's worth committing to a metadata deploy. Reserve anonymous Apex for one-off data inspection.
- Governor limits per transaction (Trailhead-stable as of 2026): 100 SOQL queries, 150 DML statements, 50K row reads, 10K row writes, 6 MB heap. Code that doesn't account for these breaks at scale. Add `Limits.getQueries()` checks in long-running transactions.
- `WITH SECURITY_ENFORCED` on SOQL when the query result is surfaced to a user. Bypassing FLS is a CRUD compliance issue, not a convenience.
- Test classes hit ≥75% coverage to deploy. Write the test class alongside the trigger; never as an afterthought.
### Salesforce: data writes
- Bulk writes default to a 25-record batch unless the user has a specific reason. Larger batches = larger blast radius on validation-rule failures.
- Always preview writes before applying. Generate a CSV of proposed changes; require explicit user approval; only then apply. Pattern: `dry_run_*` → user reviews → `apply_*` with the approved CSV as input.
- Every write logs to a `Cleanup_Audit__c` (or equivalent custom object) with `(timestamp, user, object, record_id, field, old_value, new_value)`. Reversible by design.
- Soft-delete via `IsDeleted__c` boolean, not hard-delete. Use the Recycle Bin discipline; never bypass.
### HubSpot custom code
- Use the v4 SDK (`@hubspot/api-client`) for all new code; v3 is deprecated. Endpoints under `crm/v4/` are the current generation.
- Daily API call limit (Pro/Enterprise: 250K-500K depending on tier). Custom code in workflows runs against this budget. Build in a circuit breaker that halts the workflow if 80% of daily budget is consumed before noon.
- Custom code actions have a 20-second execution timeout. Move long-running work to an external service (n8n, AWS Lambda, GCP Cloud Function) and return a webhook; don't try to fit it in the action.
- Properties API distinguishes between `internal name` and `label`. Always reference internal names in code; the label is display-only.
- Webhook subscriptions retry on 5xx for 24 hours. Idempotency is mandatory.
### n8n authoring
- Author flows in the n8n editor; export to JSON; commit the JSON. Never hand-write n8n JSON unless reviewing a diff.
- Set `executionOrder: "v1"` and `timezone` explicitly in workflow settings. Defaults differ across self-hosted and cloud instances, and the difference surfaces during DST.
- Cron node: timezone is per-node. Set it. Don't rely on the workflow default.
- Code node beats IF node when the condition has more than two branches or non-trivial logic. IF nodes become unreadable past ~3 conditions; Code nodes are testable.
- Credentials referenced by name, never inlined in the JSON. The exported JSON should contain `PLACEHOLDER_<TOOL>_CRED_ID` values that the importer fills in via the n8n credentials manager.
### dbt and SQL
- Every model has a `unique` test on its primary key and a `not_null` test on every column the downstream model joins on. Without these, a duplicate upstream silently produces inflated pipeline numbers downstream.
- Use `{{ ref() }}`, never raw `database.schema.table`.
- Incremental models declare `unique_key` and a clear `incremental_strategy`. Default to `merge` unless throughput matters more than correctness.
- Source freshness checks on every source table. A stale source silently breaks downstream forecasting; the freshness test catches it before the dashboard does.
- `dbt run` in production runs against a service account, not a user account. The audit trail names the service account, not the engineer.
### Secrets and access
- Salesforce: Connected Apps with named credentials. Never username-password OAuth flow in production code.
- HubSpot: Private App tokens with the minimum scope needed. Per-integration token, rotated quarterly.
- n8n: credentials live in the n8n credentials manager, referenced by name from the flow JSON. Rotation is via the credentials manager UI, not by editing flows.
- dbt: profile credentials in environment variables, not `~/.dbt/profiles.yml`. CI uses a service-account profile.
## Defaults to enforce
### Bulkification
- Apex code shipped without bulk patterns is rejected. Single-row DML in loops fails at 200 records.
- HubSpot custom code that processes a list does it via batch endpoints when available, not per-record loops.
### Idempotence
- Every webhook handler keys on the event source's `eventId` (or payload hash if the source doesn't provide one) and skips on second arrival.
- Every cron-triggered job tolerates replay. Two runs in a 5-minute window produce the same DB state as one run.
- Upserts use platform-native upsert when available (Salesforce `upsert`, HubSpot `upsert` endpoints) rather than read-then-write patterns that race.
### Limits and circuit breakers
- Long-running Apex includes `Limits.getQueries()` and `Limits.getDmlStatements()` checks; halts gracefully when approaching governor limits.
- HubSpot integrations track daily API consumption in a shared counter; halt when 80% consumed.
- n8n flows that could process unbounded data have an explicit cap (`Maximum items per execution: 1000`); never `unlimited`.
### Observability
- Every script ends with a summary line: items processed, succeeded, failed, skipped, runtime. This is the line on which alerting fires.
- Use a structured logger (Salesforce: custom log object or Apex `Logger`; HubSpot: console + log destination via custom code; n8n: write-to-Slack node on every error path).
- Default log level INFO. DEBUG behind a flag — bulk runs at DEBUG bury the destination.
### Secrets
- NEVER inline a credential, an API key, or an example token — including in tests. Reject suggestions to "use a fake one for the demo." Reference from secret manager by name.
- Tokens have a documented rotation cadence. Implementations read from the secrets manager on each request, no boot-time cache.
## Anti-patterns to refuse
- Anonymous Apex run against production for "a quick fix." Refuse. Use a metadata deploy or a CLI Workbench transaction with proper auth + audit.
- HubSpot custom code that calls the API in a loop without circuit breaker. Refuse — at scale this exhausts the daily quota by 10am and breaks every other workflow.
- n8n IF node with 5+ conditions. Refuse and suggest a Code node.
- dbt models without `unique` tests on the primary key. Refuse. The test is two lines and saves the forecast.
- Direct SOQL/HubSpot writes from a Notebook or local script without an audit log destination. Refuse — the audit gap becomes a compliance gap during the next SOX walkthrough.
- "Use the Salesforce admin API key for this script, it has all the permissions." Refuse. Use a named integration user with scoped permissions; admin-level service accounts have blast radius equal to the most destructive thing in the org.
## When the user is wrong
- "Just bypass the validation rule for this import, it's fine" — refuse. Validation rules exist because the data shape matters; bypass produces records that downstream reports can't aggregate. Either fix the import to satisfy the rule or change the rule via metadata deploy with documentation.
- "The forecast is off by $30K, just edit the opportunity amount in production" — refuse. Direct production edits bypass the audit trail. Use a properly scoped data-fix job with before/after CSV.
- "n8n is fine for this, it's just a webhook" — push back if the webhook is on the path of a transactional system update. n8n is great for human-in-the-loop and visual debugging; for transactional integrity, code paths with proper retry and idempotence are safer.
- "We don't need bulk patterns, we'll never have that many records" — refuse. Every Salesforce org that "will never have that many records" hits 1,000+ within 18 months of product-market fit. Bulkify from day one.
- "Skip the dbt test on this model, the source is clean" — refuse. The source is clean today. The point of the test is the day it isn't.
