Cursor rules para ingenieros de recruiting

Un archivo .cursorrules de Cursor afinado para los patrones de trabajo de un ingeniero de recruiting in-house (o un manager de recruiting-ops que codea): construir integraciones contra el ATS, escribir MCP servers para herramientas de recruiting, automatizar intake e integrar Ashby, Greenhouse y Lever con el resto del stack de recruiting. El artefacto es un archivo — apps/web/public/artifacts/cursor-rules-recruiting-engineer/.cursorrules — que colocas en el directorio .cursor/rules/ de tu proyecto.

La propiedad definitoria del código de recruiting es que cada línea toca data sobre personas reales que no saben que existes. Audit logging, seguridad antisesgo, cumplimiento jurisdiccional y consentimiento no son restricciones opcionales — son la diferencia entre un ingeniero de recruiting y una acción regulatoria. Las rules en este bundle codifican esa realidad para que el asistente de IA de Cursor no sugiera el tipo de código que hace que multen a la firma o que dañen a un candidato.

Cuándo usar esto

Eres un ingeniero de recruiting o un manager de recruiting-ops que escribe código de integración (Python, TypeScript) contra un ATS, una herramienta de sourcing o un vendor de assessment. Tu equipo despacha al menos algunos scripts por trimestre que tocan data de candidatos. Cursor es tu IDE.

Cuándo NO usar esto

• No tienes un rol dedicado de recruiting-engineering y tus “integraciones” son Zaps instalados por el vendor. Las rules asumen que hay un ingeniero en el loop autoreando código; no van a ayudar a un setup solo de configuración.
• Estás construyendo un producto de recruiting externo (un ATS, un vendor de assessment, etc.). Las rules están afinadas para el consumidor de APIs de recruiting, no el constructor. La postura de cumplimiento es distinta.
• Tu firma tiene cero candidatos en la UE, California, NYC o Illinois y es improbable que alguna vez los tenga. Varias rules en el bundle hacen referencia a NYC Local Law 144, Illinois AVDA, GDPR y CCPA — no son dañinas en otras jurisdicciones, pero tampoco son load-bearing ahí.

Setup

1. Copia el artefacto. Toma .cursorrules del bundle de arriba (o descarga el zip) y colócalo en el directorio .cursor/rules/ de tu proyecto. El indicador de Project Rules de Cursor debería mostrar que las rules están activas la próxima vez que abras un archivo.
2. Ajusta la lista de herramientas. Las rules cubren Ashby, Greenhouse, Lever, Gem, hireEZ y herramientas de recruiting basadas en MCP por defecto. Recorta o extiende las secciones específicas de cada herramienta para que coincidan con tu stack — un equipo que solo usa Ashby + Workable debería borrar las secciones de Greenhouse/Lever en lugar de cargar guidance muerto que el modelo tiene que sopesar.
3. Llena el destino de auditoría. Las rules requieren que cada lectura y escritura produzca una entrada de auditoría, pero no dictan dónde. Edita la sección “Audit trail” para que apunte al destino de tus logs (Datadog, BigQuery, una tabla custom de auditoría) para que las sugerencias de Cursor referencien el call real.
4. Configura el secret manager. Las rules prohíben credenciales inline y dirigen al modelo hacia tu secret manager preferido. Elige uno (1Password CLI, Doppler, AWS Secrets Manager, Vault) y edita la sección “Secrets and access” para que el modelo sugiera el call correcto.
5. Prueba con una tarea representativa. Pídele a Cursor: “escribe un script que lea las últimas 100 aplicaciones de Ashby, las puntúe contra una JD y publique las top 10 en un canal de Slack.” El output debería hacer las preguntas correctas (qué destino de auditoría, qué campos son PII, cuál es el fallback de revisión humana) antes de generar código. Si no lo hace, las rules no están cargadas — revisa el indicador de Project Rules de Cursor.

Qué hacen las rules en realidad

El bundle está estructurado como cinco capas, aplicadas a cada prompt de Cursor en el workspace:

1. Un preámbulo “antes de escribir código, pregunta”. Cinco preguntas que Cursor le hace al usuario antes de generar: qué clase de candidate-data está involucrada, qué jurisdicciones, lectura o escritura, semántica de retry, destino de auditoría. Las rules le instruyen a Cursor que rechace defaults y pregunte explícitamente. Esta es la sección con mayor leverage — desplaza las conversaciones de “aquí hay un script plausible” a “aquí hay una pregunta clarificadora que saca a la luz la forma regulatoria.”
2. Guidance específico por herramienta para Ashby, Greenhouse, Lever, herramientas de sourcing (Gem, hireEZ) y MCP servers. Cada sección nombra endpoints reales, rate limits reales, nombres de header reales y las rarezas que la documentación del vendor pasa por alto. Ejemplo: Greenhouse Harvest necesita un header On-Behalf-Of para atribución de auditoría; Cursor ahora va a sugerirlo.
3. Defaults a hacer cumplir en auditoría, sesgo/fairness, idempotencia, validación de schema, secrets, privacidad y testing. Cada default es concreto. Los logs de auditoría incluyen (timestamp, user_identity, system, action, data_scope). El auto-rechazo requiere un fallback de revisión humana para puntajes en el borde a menos del 10% del corte. Los tests corren contra instancias de staging o sandboxes del vendor; nunca producción.
4. Anti-patrones a rechazar. Cosas específicas que el modelo rechaza cuando el usuario las pide: credenciales inline en demos, saltar la auditoría “para el prototipo,” loggear payloads completos de webhook al recibirlos, construir una feature de scoring sin referenciar primero NYC LL 144 / EU AI Act.
5. Una sección “cuando el usuario está equivocado”. Los patrones a los que recurren los ingenieros bajo presión de deadline y contra los que el modelo debe empujar en lugar de ejecutar. La rule que más ahorra costo: rechazar desplegar screening con IA a candidatos residentes en NYC sin una auditoría anual de sesgo documentada, porque NYC LL 144 hace de esto un pasivo por candidato.

Realidad de costos

• Costo en tokens: cero. Las Cursor rules son contexto local que se envía al modelo en cada prompt; no agregan cargos por request más allá de los 4-5 KB de contexto que ocupan. Vas a perder 1-2% de la ventana de contexto efectiva del modelo. Vale la pena.
• Tiempo de setup: ~15 minutos para colocar el archivo y editar el destino de auditoría + secret manager.
• Overhead por tarea: el preámbulo “antes de escribir código, pregunta” suma 1-2 turnos de diálogo antes de que el modelo empiece a generar. Para una tarea de scripting de 5 minutos, esto es overhead significativo. Para un build de integración de 30 minutos, es ruido — y las preguntas sacan a la luz decisiones que de lo contrario se descubrirían en code review o, peor, en producción.
• Mantenimiento: ~1 hora por trimestre para revisar el archivo. Las versiones de las herramientas se desfasan; lo que era cierto sobre la Greenhouse Harvest API el trimestre pasado puede estar mal este trimestre. El bundle del artefacto se despacha como punto de partida, no como especificación congelada.

Cómo se ve el éxito

• Los comentarios de code review sobre audit logging caen casi a cero. Las rules sugieren los calls de auditoría inline, así que los reviewers dejan de cazar su ausencia.
• Cero incidentes de producción del tipo “se nos olvidó manejar el caso de retry.” Los handlers de webhook se despachan idempotentes en la primera escritura porque las rules lo hacen cumplir.
• Las conversaciones sobre auditoría de sesgo pasan en diseño, no en revisión legal. Cursor saca a la luz la ley relevante (NYC LL 144, Illinois AVDA, EU AI Act) cuando el usuario está generando código de screening, así la discusión pasa antes de que se escriba el código.
• Onboarding más rápido para ingenieros de recruiting nuevos. Un nuevo hire lee .cursor/rules/recruiting-engineer.md una vez y entiende la postura del equipo; no necesita absorber un trimestre de feedback de code review para aprender las convenciones.

Versus las alternativas

• Sin rules (status quo). Cursor genera código de recruiting plausible que pasa review hasta que no. La primera vez que un handler de webhook no sea idempotente y produzca 1.200 records duplicados de candidatos, vas a desear que la rule existiera.
• Un doc de convenciones de codeo del equipo que nadie lee. Funcionalmente equivalente a no tener rules — el doc no se carga al contexto de la IA, así que las sugerencias no lo reflejan. El archivo de Cursor rules es el doc de convenciones del equipo que sí se carga en cada prompt.
• Un linter o pre-commit hook. Atrapa algunos patrones (secrets hardcodeados, calls de auditoría faltantes si escribes una rule custom). No moldea las sugerencias de la IA mientras escribe — solo atrapa problemas después del hecho. La capa de Cursor rules está upstream del linter; ambos pueden coexistir, y deben.

Watch-outs

• Las rules requieren soporte de Project Rules de Cursor. Versiones viejas de Cursor no cargan .cursorrules desde la raíz del proyecto. Verifica en la versión de Cursor que usa tu equipo; el indicador en la esquina inferior derecha del editor confirma que las rules están activas. Guard: incluye un check de una línea en el README del proyecto (“Cursor 0.40+; el indicador de rules debe mostrar ‘recruiting-engineer.md active’”).
• No sobreespecifiques. Agregar rules para cada preferencia de estilo produce sugerencias sobrerrestrictivas y directivas en conflicto. Mantén el archivo enfocado en rules que prevengan riesgo material de sesgo, privacidad o candidate-data; deja que el formateo lo maneje Prettier o Black. Guard: cap duro del archivo en ~300 líneas.
• Drift de APIs de herramientas. Ashby y Greenhouse despachan cambios breaking 1-2 veces al año. Una rule que referencia un endpoint deprecado genera código roto. Guard: revisa el archivo trimestralmente contra el changelog de cada herramienta; etiqueta con versión la rule que menciona la versión de la API (e.g. # Greenhouse Harvest v1 (verified 2026-Q2)).
• Las rules no reemplazan auditorías de sesgo ni code review. Moldean lo que Cursor sugiere mientras escribe. No corren en CI, no atrapan lo que el ingeniero overridea, y no constituyen una auditoría de sesgo de NYC LL 144. Guard: mantén la infraestructura de revisión humana y auditoría separada; las rules complementan, nunca reemplazan.
• Los overrides por repo importan. Una rule que es correcta en tu repo de sourcing-automation puede ser incorrecta en tu repo de assessment-integration. Usa el soporte de rules por directorio de Cursor (overrides en .cursor/rules/<subdir>/) cuando las convenciones efectivamente diverjan. Guard: prefiere un archivo de rules compartido con excepciones documentadas a forkear el archivo por repo.

Stack

• Cursor — IDE y motor de rules
• .cursor/rules/recruiting-engineer.md — versionado en el repo, code-revisado como cualquier otra config
• Secret manager preferido — referenciado desde las rules, nunca inlineado
• Destino de auditoría — Datadog, BigQuery o una tabla de auditoría dedicada; nombrada explícitamente en las rules para que las sugerencias apunten al call real