Eine .cursorrules-Datei für Cursor, abgestimmt auf den CS-Ops-Engineer, der den Code hinter dem CS-Motion schreibt: Health-Score-Jobs, Churn-Risk-Scoring, Renewal-Datum-Syncs, Write-Backs nach Gainsight und Vitally, Usage-Rollup-ETL und die n8n-Flows, die das Warehouse mit dem CSP verkleben. Das Artifact ist eine einzige Datei —apps/web/public/artifacts/cursor-rules-cs-ops/.cursorrules—, die Sie in das .cursor/rules/-Verzeichnis Ihres Projekts legen, damit Cursor aufhört, einen nicht-idempotenten nächtlichen Write-Back, eine Warehouse-Query ohne Obergrenze oder einen Sentiment-Score ohne Confidence-Floor vorzuschlagen, und damit Sie aufhören, diese Defaults in jedem Code Review neu zu verhandeln.

Die definierende Eigenschaft von CS-Ops-Code ist, dass er die Zahl schreibt, der ein CSM vertraut, um zu entscheiden, wer churnt. Ein Health Score, der sich stillschweigend invertiert, wenn ein Usage-Event umbenannt wird, ein Churn-Risk-Job, der bei einem Retry doppelt schreibt, ein Renewal-Datum, das veraltet aus dem CRM synct —jeder davon bricht nicht nur ein Skript, sondern routet einen CSM zum falschen Account und lässt einen echten Save entgleiten. Die Regeln dieses Bundles kodieren idempotente Write-Backs, Baseline-vs-aktuell-Scoring-Disziplin, Confidence-Floors auf jedem LLM-Signal und konservative CSP-Writes, damit Cursors Output den Wirkungsradius eines CS-Ops-Fehlers widerspiegelt: ein verpasstes Renewal, kein fehlgeschlagener Unit Test.

Wann Sie es verwenden sollten

Sie sind ein CS-Ops-Engineer, CS-Ops-Manager oder eine RevOps-Person, die das CS-Tooling besitzt und Integrationscode schreibt —Python, TypeScript, SQL, dbt-Modelle, n8n-Flows— gegen einen CSP (Gainsight, Vitally, Catalyst, ChurnZero, Totango, Planhat, Custify), ein CRM (HubSpot oder Salesforce), eine Product-Analytics-Quelle (Pendo, Amplitude, Mixpanel, Heap) und eine Conversation-Quelle (Gong). Ihr Team liefert mindestens ein paar Änderungen pro Monat aus, die Health Scores, Renewal-Daten oder CSM-Task-Queues bewegen. Cursor ist Ihre IDE.

Wann Sie es NICHT verwenden sollten

Ihre CS-„Automatisierung” sind vom Admin gebaute Regeln in der Gainsight- oder Vitally-UI, kein Code in einem Repo. Die Regeln setzen Versionskontrolle, Code Review und eine Deploy-Pipeline voraus; sie helfen einer reinen Config-CS-Ops-Praxis nicht, und der No-Code-Regel-Builder Ihres CSP erzwingt bereits den Großteil der Idempotenz-Anliegen für Sie.
Sie sind ein CSM, der gelegentlich eine SQL-Query schreibt, um sein Book zu ziehen. Diese Regeln sind für jemanden geschrieben, der den Scoring-Job besitzt, von dem das ganze Team abhängt, nicht für Ad-hoc-Analyse. Die Präambel „bevor du Code schreibst, frage” verlangsamt eine einmalige Query, die sonst niemand ausführt.
Sie bauen ein CS-Produkt (einen CSP, ein Feedback-Tool), statt eines in einem Unternehmen zu betreiben. Die Regeln sind auf den In-House-Operator abgestimmt, der mit einem falschen Health Score den gesamten Renewal-Zyklus lang lebt, nicht auf ein Engineering-Team, das Scoring als Feature an Kunden ausliefert.

Setup

Kopieren Sie das Artifact. Holen Sie sich .cursorrules aus apps/web/public/artifacts/cursor-rules-cs-ops/.cursorrules und legen Sie es in das .cursor/rules/-Verzeichnis Ihres Projekts. Cursors Project-Rules-Indikator bestätigt, dass es geladen ist.
Kürzen Sie die Tool-Abschnitte. Die Datei wird mit Abschnitten für den CSP-Write-Back (Gainsight / Vitally), den CRM-Sync (HubSpot / Salesforce), Product-Analytics-Rollups, Gong-Sentiment, n8n-Orchestrierung und dbt ausgeliefert. Löschen Sie jeden Abschnitt für ein Tool, das Sie nicht betreiben —Guidance, die das Modell gegen irrelevanten Kontext abwägen muss, verdünnt das Signal und erzeugt gehedgte Vorschläge.
Setzen Sie die Secrets-Policy. Die Regeln verbieten hartkodierte Credentials und leiten das Modell zu Ihrem Secret Manager. Bearbeiten Sie den Abschnitt „Secrets and access”, damit der vorgeschlagene Aufruf zu Ihrem Tooling passt (1Password CLI, Doppler, AWS Secrets Manager, Vault —wählen Sie eines). Die API Keys von Gainsight und Vitally sind Bearer Tokens mit Vollzugriff ohne feldweises Scoping, daher ist dieser Abschnitt tragend.
Korrigieren Sie die Audit- und Idempotenz-Ziele. Die Regeln nehmen eine health_score_history-Tabelle mit einem Unique Key auf (account_id, scored_date) und ein Audit-Objekt für jeden CSP-Write an. Bearbeiten Sie die Tabellen- und Objektnamen zu Ihrem realen Schema, sonst referenzieren die Vorschläge Namen, die nicht existieren.
Benennen Sie die kanonischen Quellen. Bearbeiten Sie den „source of truth”-Block: welches System das Renewal-Datum besitzt (üblicherweise das CRM, nicht der CSP), welches die Usage-Baseline besitzt (das Warehouse, nicht die Live-API des Produkts), welches die Account-Liste im Scope besitzt. Das Modell nutzt diese, um einen Write zu verweigern, der den CSP das Renewal-Datum des CRM überschreiben ließe.
Testen Sie an einer repräsentativen Aufgabe. Bitten Sie Cursor: „schreibe einen nächtlichen Job, der Account-Health aus einer 28-Tage-Usage-Baseline scort und das Ergebnis nach Gainsight schreibt.” Der Output sollte gegen eine gespeicherte Baseline rechnen (kein Live-Recompute), den Score deckeln, wenn die distinkten aktiven Nutzer unter drei fallen, über einen idempotenten Upsert mit Key auf (account_id, scored_date) zurückschreiben und in die Audit-Tabelle loggen. Wenn nicht, sind die Regeln nicht geladen —prüfen Sie den Project-Rules-Indikator.

Was die Regeln tatsächlich tun

Das Bundle ist als fünf Schichten strukturiert, angewendet auf jeden Cursor-Prompt:

Eine „bevor du Code schreibst, frage”-Präambel. Sechs Fragen, die das Modell vor dem Generieren an die Oberfläche bringt: welches System die Source of Truth für dieses Feld ist, wie hoch das Account-Volumen und der Rate Cap des Anbieters sind, was ein falscher Wert für den Tag eines CSM bedeutet, ob dies einmalig oder ein nächtlicher Job ist, ob der Write bei Retry idempotent ist, und wer den Audit Trail liest. Die CS-spezifische ist die erste —CS-Ops-Code streitet ständig darüber, ob das CRM oder der CSP das Renewal-Datum besitzt, und das Modell sollte diese Entscheidung erzwingen, bevor es den Sync schreibt.
Tool-spezifische Guidance. Ein Unterabschnitt pro Surface, jeder zitiert reale Limits und Eigenheiten: Gainsight (Rules Engine vs. Connectors API, der Lese-Cap der Klasse 3-Calls-pro-Sekunde, Custom-Field-Provisionierung vor dem Write), Vitally (REST API, die Upsert-Semantik der traits, kein nativer Bulk-Endpoint, also Batch im Code), HubSpot (SDK v4, Circuit Breaker für das Tages-Quota bei 80 % verbraucht, 20-Sekunden-Timeout), Salesforce (SOQL-Governor-Limits, Bulkification, WITH SECURITY_ENFORCED), Product Analytics (Pagination der Export-API von Pendo/Amplitude/Mixpanel und die Falle der Event-Namen-Drift), Gong (90-Tage-Call-Fenster, Prüfung auf aktivierte Transkription, Confidence-Floor auf jedem Sentiment-Signal), n8n (executionOrder, expliziter Cron-Timezone, Batch-Größe unter dem Anbieter-Cap) und dbt (Unique-Tests auf jedem Grain, ref(), Incremental-Strategie, Source Freshness auf dem Warehouse-Rollup).
Defaults, die zu erzwingen sind über alle vier erforderlichen Dimensionen, jede mit einem konkreten Wert:
- Rate-Limiting —batchen Sie CSP-Writes mit 25 Accounts pro Gruppe; stoppen Sie HubSpot bei 80 % des Tages-Quotas; respektieren Sie Gongs Cap von 3-Calls/Sek pro Workspace mit einem expliziten Wait pro Batch.
- Idempotenz —jeder History-Write ist ein Upsert mit Key auf (account_id, scored_date) mit ON CONFLICT DO UPDATE; jeder CSP-Write-Back prüft den vorherigen Wert und ist sicher, um 09:00 nach einem 02:00-Fehlschlag erneut auszuführen.
- Observability —jeder Scoring-Job loggt die Sub-Score-Inputs (Usage, Aktivität, Sentiment) neben dem Composite, damit ein falscher Score ohne erneutes Ausführen debuggbar ist; Band-Änderungen emittieren ein strukturiertes Event.
- Secrets —niemals ein CSP- oder CRM-Token inlinen; über den benannten Secret Manager routen; Tokens mit Vollzugriff erhalten den engsten verfügbaren Deploy-Scope.
Anti-Patterns, die zu verweigern sind, jedes mit dem Grund. Die Usage-Baseline jede Nacht live neu zu berechnen, statt sie einzufrieren (eine Tagging-Änderung liest sich dann als Verhaltensänderung und der Score bewegt sich auf Rauschen); ein LLM-Sentiment- oder Churn-Reason-Feld ohne Confidence-Floor (eine selbstsichere Vermutung über eine 50-Wort-Voicemail ist schlimmer als null); ein CSP-Write-Back ohne Prüfung des vorherigen Werts (doppelter Write bei Retry, verschmutzt den Audit Trail); den CSP das Renewal-Datum des CRM überschreiben zu lassen (der CSP ist downstream vom CRM, nicht die Quelle); ein health_score-Write ohne scored_at und ohne History-Zeile (Sie sehen die Trajektorie nicht, was der ganze Sinn eines Scores ist).
Ein Abschnitt „wenn der Nutzer falsch liegt”. Die Abkürzungen, zu denen CS-Ops-Engineer unter dem Druck des Renewal-Crunch greifen und die das Modell zurückweist, statt sie auszuführen. Die wertvollste Verweigerung: einen Churn-Risk-Score abzulehnen, hinter dessen Gewichten kein gelabelter Churn-Backtest steht, weil ein Score ohne Backtest die Autorität einer Zahl trägt, während er CSMs auf Vermutung routet —er ist schlimmer als kein Score, und das Modell sagt das, statt ihn zu generieren.

Kostenrealität

Token-Kosten: null. Cursor-Regeln sind lokaler Kontext, der bei jedem Prompt mitgeschickt wird —keine API-Gebühr pro Request über die ~6 KB hinaus, die sie im Kontextfenster belegen.
Setup-Zeit: 20-30 Minuten, um die Datei abzulegen, den Secret Manager zu setzen, die kanonischen Quellen zu benennen und die History-Tabelle und das Audit-Objekt auf reale Namen zu zeigen. Der „source of truth”-Block dauert am längsten, weil er eine Entscheidung erzwingt, die Ihr Team vielleicht vermieden hat.
Overhead pro Aufgabe: die Präambel fügt 1-2 Dialogrunden vor der Generierung hinzu. Für eine Wegwerf-Query ist das schwer; überspringen Sie es dort. Für einen nächtlichen Scoring-Job, dem das ganze CS-Team vertraut, bringt sie die Idempotenz- und Source-of-Truth-Entscheidungen an die Oberfläche, die sonst drei Monate später als Feuerwehrübung am Forecast-Tag auftauchen.
Wartung: ~30 Minuten pro Quartal. SDK- und API-Versionen driften (HubSpot v3 → v4 bereits; Gainsight und Vitally revidieren ihre APIs ohne laute Ankündigungen). Versionieren Sie jede Regel, die eine Version nennt, mit einem Tag, damit der nächste Reviewer weiß, wann erneut zu prüfen ist.

Wie Erfolg aussieht

Health-Score-Vorfälle, die an nicht-idempotente Writes gebunden sind, fallen auf null. Der Upsert-auf-(account_id, scored_date)-Default beendet die Doppel-Write-Klasse von Bugs, die die History-Tabelle mit Duplikatzeilen füllt und die Trajektorie-Charts bricht.
„Der Score sagt grün, aber der Account churnt eindeutig” wird aus Logs debuggt, nicht aus erneuten Läufen. Weil jeder Job seine Sub-Score-Inputs loggt, löst sich die Beschwerde eines CSM durch das Lesen einer Log-Zeile, nicht durch erneutes Ausführen des Jobs in der Hoffnung auf Reproduktion.
Kein CSM öffnet je einen Account mit einem drei Wochen veralteten Renewal-Datum. Die Source-of-Truth-Regel hält das CRM als Eigentümer des Renewals und verweigert den CSP-Write, der es überschatten würde.
Das Code Review hört auf, „hast du einen Confidence-Floor hinzugefügt” zu jagen. Die Regeln schlagen den Floor inline auf jedem LLM-Signal vor; die Reviewer konzentrieren sich stattdessen auf die Gewichtungslogik.

Gegenüber den Alternativen

Gar keine Regeln (Status quo). Cursor generiert einen plausiblen Scoring-Job, der die Baseline live neu berechnet und bei Retry doppelt schreibt. Das erste Mal, wenn ein Usage-Event-Rename über Nacht den Score jedes Accounts invertiert und das CS-Team eine Renewal-Woche lang der Zahl nicht vertraut, wird das Fehlen von Regeln zum Engpass.
Der eigene No-Code-Regel-Builder des CSP (Gainsight Rules Engine, Vitallys Automatisierung). Für Teams, die keinen Code schreiben, ist das die richtige Antwort —er erledigt Idempotenz und Scheduling für Sie. Diese Regeln sind für das Team, das darüber hinausgewachsen ist: Custom-Scoring-Mathematik, ein LLM-Sentiment-Signal, das der Regel-Builder nicht ausdrücken kann, oder eine Warehouse-Baseline, die der CSP nicht erreichen kann. Nutzen Sie den Regel-Builder für den Standard-Motion und den Code (geformt von diesen Regeln) für die Teile, die er nicht kann.
Ein CS-Ops-Konventionen-Dok in Notion. Funktional äquivalent zu keinen Regeln —das Dok ist nicht im Kontext des Modells. Die .cursorrules-Datei ist dieses Konventionen-Dok, geladen bei jedem Prompt.
Ein Linter oder dbt-Tests. Fangen Probleme, nachdem der Code geschrieben ist. Koexistieren mit den Regeln: die Regeln verhindern, dass der nicht-idempotente Write geschrieben wird, die dbt-Tests fangen den Rollup-Grain, der durchrutscht. Behalten Sie beides.

Worauf zu achten ist

Regel-Drift. Teams fügen Regeln hinzu und entfernen sie nie; die Datei wird zu einem Museum von Guidance, die das Modell weiterhin anzuwenden versucht. Guard: vierteljährliche Review mit git blame —alles, was älter als 18 Monate ist, wird neu gerechtfertigt oder gelöscht, und die Datei bleibt unter ~300 Zeilen.
CSP-API-Churn. „Nutze den traits-Upsert von Vitally” oder „Gainsight Connectors API v2” wird veraltet, wenn der Vendor die API ohne laute Ankündigung revidiert. Guard: versionieren Sie jede Regel, die eine API-Version nennt, mit einem Tag (z. B. # Gainsight Connectors API (verified 2026-Q2)), damit der nächste Reviewer das Wiederprüfungsdatum kennt.
Source-of-Truth-Regeln, die mit Ihrer realen Architektur kämpfen. Der ausgelieferte Default macht das CRM zum Eigentümer des Renewal-Datums, aber manche Orgs betreiben den CSP tatsächlich als Renewal-Quelle. Guard: der „source of truth”-Block ist das Erste, was Sie im Setup bearbeiten; ein falscher Eintrag hier lässt das Modell korrekte Writes verweigern und falsche genehmigen.
Repo-weise Overrides. Ein Write-erlaubt-Default, der in Ihrem Scoring-Repo richtig ist, ist in Ihrem Read-only-Reporting-Repo falsch. Guard: nutzen Sie Cursors verzeichnisweise Regel-Unterstützung und dokumentieren Sie die Divergenz im README jedes Repos; bevorzugen Sie eine geteilte Datei mit dokumentierten Ausnahmen, statt sie zu forken.
Regeln ersetzen keinen Backtest. Sie lassen Cursor die Auslieferung eines Churn-Modells ohne Backtest verweigern, aber sie können den Backtest nicht für Sie ausführen. Guard: behalten Sie den gelabelten Churn-Backtest, die dbt-Tests und das Code Review als getrennte Enforcement-Schichten —die Regeln formen die Vorschläge, sie sind keine Kontrolle.

Stack

Cursor —IDE und Regel-Engine
Claude —das Modell hinter Cursors Generierung; auch das LLM, das die Regeln den Scoring-Jobs für Sentiment und Why-Changed-Sätze aufrufen lassen, immer mit einem Confidence-Floor
.cursor/rules/cs-ops.md —im Repo versioniert, im Code Review
CSP (Gainsight / Vitally / Catalyst / ChurnZero) —Write-Back-Ziel für Health-Score und Renewal; niemals die Source of Truth für das Renewal-Datum
CRM (HubSpot / Salesforce) —kanonische Quelle für Renewal-Datum und Account-Liste
Secret Manager nach Wahl —aus den Regeln referenziert, niemals inlined; CSP-Tokens haben Vollzugriff, also eng scopen
health_score_history-Tabelle —Idempotenz-Key (account_id, scored_date) und Trajektorie-Audit-Trail

Diese Seite auf GitHub bearbeiten