Cursor-Regeln für Recruiting-Engineers

Eine Cursor-.cursorrules-Datei, abgestimmt auf die Arbeitsmuster eines Inhouse-Recruiting-Engineers (oder eines Recruiting-Ops-Managers, der programmiert): ATS-Integrationen bauen, MCP-Server für Recruiting-Tools schreiben, Intake automatisieren und Ashby, Greenhouse und Lever mit dem Rest des Recruiting-Stacks verkleben. Das Artifact ist eine einzige Datei – apps/web/public/artifacts/cursor-rules-recruiting-engineer/.cursorrules – die Sie in das Verzeichnis .cursor/rules/ Ihres Projekts ablegen.

Die definierende Eigenschaft von Recruiting-Code ist, dass jede Zeile Daten über echte Menschen berührt, die nicht wissen, dass Sie existieren. Audit Logging, Bias-Sicherheit, jurisdiktionale Compliance und Einwilligung sind keine optionalen Einschränkungen – sie sind der Unterschied zwischen einem Recruiting-Engineer und einer Durchsetzungsmaßnahme. Die Regeln in diesem Bundle kodieren diese Realität, damit Cursors KI-Assistent nicht den Code vorschlägt, der eine Firma mit einer Geldstrafe belegt oder einem Kandidaten schadet.

Wann einsetzen

Sie sind ein Recruiting-Engineer oder ein Recruiting-Ops-Manager, der Integrationscode (Python, TypeScript) gegen ein ATS, ein Sourcing-Tool oder einen Assessment-Anbieter schreibt. Ihr Team liefert mindestens einige Skripte pro Quartal, die Kandidatendaten berühren. Cursor ist Ihre IDE.

Wann NICHT einsetzen

• Sie haben keine dedizierte Recruiting-Engineering-Rolle und Ihre „Integrationen” sind vom Anbieter installierte Zaps. Die Regeln setzen voraus, dass ein Engineer in der Schleife ist und Code schreibt; sie helfen einem Config-only-Setup nicht.
• Sie bauen ein externes Recruiting-Produkt (ein ATS, einen Assessment-Anbieter usw.). Die Regeln sind auf den Konsumenten von Recruiting-APIs abgestimmt, nicht auf den Erbauer. Die Compliance-Haltung ist anders.
• Ihre Firma hat null Kandidaten in der EU, Kalifornien, NYC oder Illinois und wird voraussichtlich nie welche haben. Mehrere Regeln im Bundle referenzieren NYC Local Law 144, Illinois AVDA, DSGVO und CCPA – sie sind in anderen Jurisdiktionen nicht schädlich, aber auch nicht tragend.

Setup

1. Artifact kopieren. .cursorrules aus dem Bundle oben (oder Zip herunterladen) und in das Verzeichnis .cursor/rules/ Ihres Projekts ablegen. Cursors Project-Rules-Indikator sollte beim nächsten Dateiöffnen anzeigen, dass die Regeln aktiv sind.
2. Tool-Liste anpassen. Die Regeln decken Ashby, Greenhouse, Lever, Gem, hireEZ und MCP-basierte Recruiting-Tools standardmäßig ab. Die tool-spezifischen Abschnitte trimmen oder erweitern, um Ihrem Stack zu entsprechen – ein Team, das nur Ashby + Workable verwendet, sollte die Greenhouse/Lever-Abschnitte löschen statt veraltete Guidance zu tragen, gegen die das Modell abwägen muss.
3. Audit-Destination befüllen. Die Regeln erfordern, dass jedes Lesen und Schreiben einen Audit-Eintrag produziert, schreiben aber nicht vor, wo. Den „Audit Trail”-Abschnitt bearbeiten, um auf Ihr Log-Ziel zu verweisen (Datadog, BigQuery, eine benutzerdefinierte Audit-Tabelle), damit Cursors Vorschläge den echten Aufruf referenzieren.
4. Secret Manager festlegen. Die Regeln verbieten Inline-Zugangsdaten und weisen das Modell auf Ihren Secret Manager Ihrer Wahl hin. Einen wählen (1Password CLI, Doppler, AWS Secrets Manager, Vault) und den Abschnitt „Secrets und Zugang” bearbeiten, damit das Modell den richtigen Aufruf vorschlägt.
5. Auf einer repräsentativen Aufgabe testen. Cursor fragen: „Schreibe ein Skript, das die letzten 100 Ashby-Bewerbungen liest, sie gegen eine Stellenbeschreibung bewertet und die Top 10 in einen Slack-Channel postet.” Der Output sollte die richtigen Fragen stellen (welche Audit-Destination, welche Felder sind PII, was ist der Fallback für menschliche Überprüfung), bevor Code generiert wird. 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 im Workspace angewendet werden:

1. Eine „Vor-dem-Code-Schreiben-fragen”-Präambel. Fünf Fragen, die Cursor dem Benutzer aufzeigt, bevor generiert wird: welche Kandidaten-Datenklasse beteiligt ist, welche Jurisdiktionen, Lesen-oder-Schreiben, Retry-Semantik, Audit-Destination. Die Regeln weisen Cursor an, Defaults zu verweigern und explizit zu fragen. Das ist der einzige Abschnitt mit dem höchsten Hebel – er verschiebt Gespräche von „hier ist ein plausibles Skript” zu „hier ist eine klärende Frage, die die regulatorische Form aufzeigt.”
2. Tool-spezifische Guidance für Ashby, Greenhouse, Lever, Sourcing-Tools (Gem, hireEZ) und MCP-Server. Jeder Abschnitt nennt echte Endpunkte, echte Rate Limits, echte Header-Namen und die Eigenheiten, die die Anbieter-Dokumentation übergeht. Beispiel: Greenhouse Harvest benötigt einen On-Behalf-Of-Header für Audit-Attribution; Cursor wird ihn jetzt vorschlagen.
3. Durchzusetzende Defaults über Audit, Bias/Fairness, Idempotenz, Schema-Validierung, Secrets, Datenschutz und Testing. Jeder Default ist konkret. Audit-Logs beinhalten (timestamp, user_identity, system, action, data_scope). Auto-Ablehnung erfordert einen menschlichen Überprüfungs-Fallback für Grenzwert-Scores innerhalb von 10 % des Schwellenwerts. Tests laufen gegen Staging-Instanzen oder Anbieter-Sandboxes; niemals Produktion.
4. Abzulehnende Anti-Pattern. Spezifische Dinge, die das Modell ablehnt, wenn der Benutzer darum bittet: Inline-Zugangsdaten in Demos, Audit für „den Prototyp” überspringen, vollständige Webhook-Payloads beim Empfang loggen, ein Scoring-Feature bauen ohne NYC LL 144 / EU-KI-Gesetz zuerst zu referenzieren.
5. Ein „Wenn der Benutzer falsch liegt”-Abschnitt. Die Muster, zu denen Engineers unter Fristenruck greifen, bei denen das Modell zurückschlagen statt ausführen sollte. Die einzige kosten-sparendste Regel: KI-Screening in NYC-Ansässige Kandidaten nicht ohne eine dokumentierte jährliche Bias-Prüfung deployen, weil NYC LL 144 daraus eine Per-Kandidaten-Haftung macht.

Kostenrealität

• Token-Kosten: null. Cursor-Regeln sind lokaler Kontext, der bei jedem Prompt zum Modell gesendet wird; sie fügen keine Per-Request-Gebühren jenseits der 4–5 KB Kontext hinzu, die sie belegen. Sie verlieren 1–2 % des effektiven Kontextfensters des Modells. Lohnenswert.
• Setup-Zeit: ~15 Minuten, um die Datei abzulegen und Audit-Destination + Secret Manager zu bearbeiten.
• Per-Aufgaben-Overhead: Die „Vor-dem-Code-Schreiben-fragen”-Präambel fügt 1–2 Gesprächsrunden vor der Generierung hinzu. Für eine 5-minütige Scripting-Aufgabe ist das bedeutsamer Overhead. Für eine 30-minütige Integrations-Build ist es Rauschen – und die Fragen zeigen Entscheidungen auf, die andernfalls in Code-Review oder, schlimmer, in Produktion entdeckt würden.
• Wartung: ~1 Stunde pro Quartal zur Überprüfung der Datei. Tool-Versionen driften; was letztes Quartal über die Greenhouse Harvest API stimmte, kann dieses Quartal falsch sein. Das Artifact-Bundle liefert einen Ausgangspunkt, keine eingefrorene Spezifikation.

Wie Erfolg aussieht

• Code-Review-Kommentare über Audit Logging sinken auf nahe null. Die Regeln schlagen die Audit-Aufrufe inline vor, sodass Reviewer deren Abwesenheit nicht mehr erkennen.
• Null „Wir haben vergessen, den Retry-Fall zu behandeln”-Produktionsvorfälle. Webhook-Handler werden beim ersten Schreiben idempotent geliefert, weil die Regeln es durchsetzen.
• Bias-Audit-Gespräche finden im Design statt, nicht in der Rechts-Überprüfung. Cursor zeigt das relevante Gesetz auf (NYC LL 144, Illinois AVDA, EU-KI-Gesetz), wenn der Benutzer Screening-Code generiert, sodass die Diskussion stattfindet, bevor der Code geschrieben ist.
• Schnelleres Onboarding für neue Recruiting-Engineers. Ein neuer Mitarbeiter liest .cursor/rules/recruiting-engineer.md einmal und versteht die Haltung des Teams; er muss kein Quartal Code-Review-Feedback aufnehmen, um die Konventionen zu lernen.

Vergleich mit Alternativen

• Keine Regeln (Status quo). Cursor generiert plausiblen Recruiting-Code, der die Überprüfung besteht, bis er es nicht mehr tut. Das erste Mal, wenn ein Webhook-Handler nicht idempotent ist und 1.200 doppelte Kandidatendatensätze produziert, werden Sie sich wünschen, die Regel existiert hätte.
• Ein Team-Coding-Conventions-Dokument, das niemand liest. Funktionell äquivalent zu keinen Regeln – das Dokument wird nicht in den KI-Kontext geladen, sodass Vorschläge es nicht widerspiegeln. Die Cursor-Regeldatei ist das Team-Conventions-Dokument, das bei jedem Prompt tatsächlich geladen wird.
• Ein Linter oder Pre-Commit-Hook. Erkennt einige Muster (fest kodierte Secrets, fehlende Audit-Aufrufe, wenn Sie eine benutzerdefinierte Regel schreiben). Formt nicht die KI-Vorschläge während des Schreibens – es erkennt nur Probleme nachher. Die Cursor-Regeln-Schicht ist dem Linter vorgelagert; beide können koexistieren und sollten es.

Wichtige Hinweise

• Regeln erfordern Cursor Project Rules Unterstützung. Ältere Cursor-Versionen laden .cursorrules nicht aus dem Projektstammverzeichnis. Auf der Cursor-Version Ihres Teams verifizieren; der Indikator rechts unten im Editor bestätigt, dass Regeln aktiv sind. Guard: Eine einzeilige Prüfung in Ihre Projekt-README aufnehmen („Cursor 0.40+; Regeln-Indikator muss ‘recruiting-engineer.md aktiv’ zeigen”).
• Nicht über-spezifizieren. Regeln für jede Stil-Präferenz hinzuzufügen produziert zu restriktive Vorschläge und widersprüchliche Direktiven. Die Datei auf Regeln konzentrieren, die material Bias-, Datenschutz- oder Kandidatendaten-Risiken verhindern; lassen Sie Formatierung sich mit Prettier oder Black handhaben. Guard: Harten Cap bei ~300 Zeilen festlegen.
• Tool-API-Drift. Ashby und Greenhouse liefern 1–2× jährlich Breaking Changes. Eine Regel, die einen veralteten Endpunkt referenziert, generiert kaputten Code. Guard: Die Datei vierteljährlich gegen den Changelog jedes Tools überprüfen; die Regel, die die API-Version erwähnt, versions-taggen (z. B. # Greenhouse Harvest v1 (verifiziert 2026-Q2)).
• Regeln ersetzen keine Bias-Audits oder Code-Reviews. Sie formen, was Cursor während des Schreibens vorschlägt. Sie laufen nicht in CI, sie erkennen nicht, was der Engineer überschreibt, und sie stellen kein NYC-LL-144-Bias-Audit dar. Guard: Menschliche Überprüfung und Audit-Infrastruktur als separate Durchsetzungsschichten beibehalten; die Regeln ergänzen, ersetzen sie nie.
• Per-Repo-Overrides sind wichtig. Eine Regel, die in Ihrem Sourcing-Automatisierungs-Repo richtig ist, kann in Ihrem Assessment-Integrations-Repo falsch sein. Cursors Per-Verzeichnis-Regelunterstützung verwenden (.cursor/rules/<Unterverzeichnis>/-Overrides), wenn die Konventionen tatsächlich abweichen. Guard: Eine gemeinsame Regeldatei mit dokumentierten Ausnahmen gegenüber dem Forken der Datei pro Repo bevorzugen.

Stack

• Cursor — IDE und Regel-Engine
• .cursor/rules/recruiting-engineer.md — im Repository versioniert, code-überprüft wie jede andere Konfiguration
• Secret Manager der Wahl — aus Regeln referenziert, niemals inline
• Audit-Destination — Datadog, BigQuery oder eine dedizierte Audit-Tabelle; explizit namentlich in den Regeln benannt, damit Vorschläge auf den echten Aufruf zeigen