Cursor rules para engenheiros de recrutamento

Um arquivo .cursorrules do Cursor afinado para os padrões de trabalho de um engenheiro de recrutamento in-house (ou um recruiting-ops manager que codifica): construindo integrações de ATS, escrevendo MCP servers para tools de recrutamento, automatizando intake, e grudando Ashby, Greenhouse, e Lever no resto do stack de recrutamento. O artefato é um arquivo — apps/web/public/artifacts/cursor-rules-recruiting-engineer/.cursorrules — que você solta no diretório .cursor/rules/ do seu projeto.

A propriedade definidora do código de recrutamento é que cada linha toca dados sobre pessoas reais que não sabem que você existe. Logging de auditoria, segurança de viés, compliance jurisdicional, e consentimento não são constraints opcionais — são a diferença entre um engenheiro de recrutamento e uma ação de enforcement. As rules nesse bundle codificam essa realidade para que o AI assistant do Cursor não sugira o tipo de código que faz uma firma ser multada ou um candidato ser prejudicado.

Quando usar isso

Você é um engenheiro de recrutamento ou um recruiting-ops manager que escreve código de integração (Python, TypeScript) contra um ATS, sourcing tool, ou vendor de assessment. Seu time embarca pelo menos alguns scripts por trimestre que tocam dados de candidato. O Cursor é seu IDE.

Quando NÃO usar isso

• Você não tem um papel dedicado de engenharia de recrutamento e suas “integrações” são Zaps instaladas por vendor. As rules assumem que um engenheiro está no loop e autorando código; não vão ajudar um setup config-only.
• Você está construindo um produto externo de recrutamento (um ATS, um vendor de assessment, etc.). As rules são afinadas para o consumidor de APIs de recrutamento, não o construtor delas. A postura de compliance é diferente.
• Sua firma tem zero candidatos na EU, Califórnia, NYC, ou Illinois e é improvável que tenha algum dia. Várias rules no bundle referenciam NYC Local Law 144, Illinois AVDA, GDPR, e CCPA — não são prejudiciais em outras jurisdições mas também não são load-bearing.

Setup

1. Copie o artefato. Pegue .cursorrules do bundle acima (ou baixe o zip) e solte no diretório .cursor/rules/ do seu projeto. O indicador de Project Rules do Cursor deve mostrar que as rules estão ativas na próxima abertura de arquivo.
2. Ajuste a lista de tools. As rules cobrem Ashby, Greenhouse, Lever, Gem, hireEZ, e tools de recrutamento baseadas em MCP por default. Apare ou estenda as seções tool-specific para casar com seu stack — um time que usa só Ashby + Workable deve deletar as seções Greenhouse/Lever em vez de carregar orientação morta que o modelo tem que pesar.
3. Preencha o destino de auditoria. As rules requerem que toda read e write produza uma entrada de auditoria, mas não ditam onde. Edite a seção “Audit trail” para apontar para o seu destino de log (Datadog, BigQuery, uma tabela custom de auditoria) para que as sugestões do Cursor referenciem a chamada real.
4. Defina o secret manager. As rules banem credenciais inline e direcionam o modelo para o seu secret manager de escolha. Escolha um (1Password CLI, Doppler, AWS Secrets Manager, Vault) e edite a seção “Secrets and access” para que o modelo sugira a chamada certa.
5. Teste numa tarefa representativa. Peça pro Cursor: “escreva um script que lê as últimas 100 applications do Ashby, dá score contra uma JD, e posta os top 10 num canal do Slack.” O output deve fazer as perguntas certas (qual destino de auditoria, quais campos são PII, qual é o fallback de human-review) antes de gerar código. Se não faz, as rules não estão carregadas — verifique o indicador de Project Rules do Cursor.

O que as rules realmente fazem

O bundle é estruturado em cinco camadas, aplicadas a todo prompt do Cursor no workspace:

1. Um preâmbulo “antes de escrever código, pergunte.” Cinco perguntas que o Cursor superficializa para o usuário antes de gerar: qual classe de dados de candidato está envolvida, quais jurisdições, read-ou-write, semântica de retry, destino de auditoria. As rules instruem o Cursor a recusar defaults e perguntar explicitamente. Essa é a seção single de mais alto leverage — desloca conversas de “aqui está um script plausível” para “aqui está uma pergunta clarificadora que superficializa o formato regulatório.”
2. Orientação tool-specific para Ashby, Greenhouse, Lever, sourcing tools (Gem, hireEZ), e MCP servers. Cada seção nomeia endpoints reais, rate limits reais, nomes de header reais, e as peculiaridades que os docs do vendor passam por cima. Exemplo: Greenhouse Harvest precisa de um header On-Behalf-Of para atribuição de auditoria; o Cursor vai sugerir isso agora.
3. Defaults para enforçar através de auditoria, viés/fairness, idempotência, schema validation, secrets, privacidade, e testing. Cada default é concreto. Logs de auditoria incluem (timestamp, user_identity, system, action, data_scope). Auto-rejeição requer um fallback de human-review para scores borderline dentro de 10% do cutoff. Testes rodam contra instâncias de staging ou sandboxes de vendor; nunca produção.
4. Anti-patterns para recusar. Coisas específicas que o modelo rejeita quando o usuário pede: credenciais inline em demos, pular auditoria “para o protótipo,” logar payloads completos de webhook no recebimento, construir uma feature de scoring sem referenciar NYC LL 144 / EU AI Act primeiro.
5. Uma seção “quando o usuário está errado”. Os padrões que os engenheiros buscam sob pressão de deadline e que o modelo deve empurrar de volta em vez de executar. A rule single mais cost-saving: recusar deploy de AI screening para candidatos residentes em NYC sem um bias audit anual documentado, porque NYC LL 144 faz disso uma liability per-candidato.

Realidade de custo

• Custo de tokens: zero. Cursor rules são contexto local enviado ao modelo em cada prompt; não adicionam cobranças per-request além dos 4-5 KB de contexto que ocupam. Você vai perder 1-2% da janela de contexto efetiva do modelo. Vale a pena.
• Tempo de setup: ~15 minutos para soltar o arquivo e editar o destino de auditoria + secret manager.
• Overhead per-task: o preâmbulo “antes de escrever código, pergunte” adiciona 1-2 turnos de diálogo antes do modelo começar a gerar. Para uma tarefa de scripting de 5 minutos, isso é overhead significativo. Para um build de integração de 30 minutos, é ruído — e as perguntas superficializam decisões que de outra forma seriam descobertas em code review ou, pior, em produção.
• Manutenção: ~1 hora por trimestre para revisar o arquivo. Versões de tools derivam; o que era verdade sobre a Greenhouse Harvest API no último trimestre pode estar errado nesse trimestre. O bundle de artefato embarca como ponto de partida, não como especificação congelada.

Como o sucesso se parece

• Comentários de code review sobre logging de auditoria caem perto de zero. As rules sugerem as chamadas de auditoria inline, então reviewers param de pegar a ausência delas.
• Zero incidentes de produção do tipo “esquecemos de tratar o caso de retry”. Webhook handlers embarcam idempotentes no primeiro write porque as rules enforçam isso.
• Conversas de bias-audit acontecem em design, não em legal review. O Cursor superficializa a lei relevante (NYC LL 144, Illinois AVDA, EU AI Act) quando o usuário está gerando código de screening, então a discussão acontece antes do código ser escrito.
• Onboarding mais rápido para engenheiros novos de recrutamento. Um novo contratado lê .cursor/rules/recruiting-engineer.md uma vez e entende a postura do time; não precisa absorver um trimestre de feedback de code review para aprender as convenções.

Versus as alternativas

• Sem rules de jeito nenhum (status quo). O Cursor gera código de recrutamento plausível que passa em review até não passar. A primeira vez que um webhook handler não é idempotente e produz 1.200 registros duplicados de candidato, você vai desejar que a rule existisse.
• Um doc de convenções de código do time que ninguém lê. Funcionalmente equivalente a sem rules — o doc não é carregado no contexto do AI, então as sugestões não refletem ele. O arquivo de Cursor rules é o doc de convenções do time que é de fato carregado em todo prompt.
• Um linter ou pre-commit hook. Pega alguns padrões (secrets hard-coded, chamadas de auditoria faltando se você escreve uma rule custom). Não molda as sugestões do AI durante a escrita — só pega problemas depois do fato. A camada de Cursor rules é upstream do linter; ambos podem coexistir, e devem.

Pontos de atenção

• As rules requerem suporte de Project Rules do Cursor. Versões mais antigas do Cursor não carregam .cursorrules da raiz do projeto. Verifique na versão do Cursor que seu time usa; o indicador no canto inferior direito do editor confirma que as rules estão ativas. Guard: inclua um check de uma linha no README do projeto (“Cursor 0.40+; o indicador de rules tem que mostrar ‘recruiting-engineer.md active’”).
• Não super-especifique. Adicionar rules para toda preferência de estilo produz sugestões super-restritivas e diretivas conflitantes. Mantenha o arquivo focado nas rules que previnem risco material de viés, privacidade, ou dados de candidato; deixe o drift de formatação se virar com Prettier ou Black. Guard: cap duro do arquivo em ~300 linhas.
• Drift de API de tool. Ashby e Greenhouse embarcam mudanças breaking 1-2x por ano. Uma rule que referencia um endpoint depreciado gera código quebrado. Guard: revise o arquivo trimestralmente contra o changelog de cada tool; version-tag a rule que menciona a versão da API (ex. # Greenhouse Harvest v1 (verificado 2026-Q2)).
• As rules não substituem bias audits ou code review. Elas moldam o que o Cursor sugere durante a escrita. Não rodam em CI, não pegam o que o engenheiro sobrescreve, e não constituem um bias audit de NYC LL 144. Guard: mantenha a infra de review humano e auditoria separada; as rules complementam, nunca substituem.
• Overrides per-repo importam. Uma rule que está certa no seu repo de sourcing-automation pode estar errada no seu repo de assessment-integration. Use o suporte de rule per-diretório do Cursor (overrides em .cursor/rules/<subdir>/) quando as convenções de fato divergem. Guard: prefira um arquivo único de rules compartilhado com exceções documentadas em vez de forkar o arquivo per repo.

Stack

• Cursor — IDE e engine de rules
• .cursor/rules/recruiting-engineer.md — versionado no repo, code-reviewed como qualquer outro config
• Secret manager de escolha — referenciado das rules, nunca inline
• Destino de auditoria — Datadog, BigQuery, ou uma tabela de auditoria dedicada; nomeado explicitamente nas rules para que as sugestões apontem para a chamada real