Configurando regras de cursor para que a IA pare de quebrar seu estilo de base de código
A configuração .cursor/rules que uso em um repositório de equipe: um arquivo global, um arquivo por diretório e as três regras que removeram 90% dos meus commits de correção de estilo.
No meu primeiro mês com o Cursor, todas as edições de agente funcionaram e ainda pareciam erradas – guias onde meu repositório usa espaços, exportações padrão em uma base de código de nomes, testes escritos em um estilo que nosso CI rejeita. A correção não foi melhor solicitada. Eram arquivos de regras, configurados corretamente.
O cursor lê regras de .cursor/rules em seu repositório. Comece com um arquivo de regras em nível de projeto cobrindo os itens não negociáveis: gerenciador de pacotes, ordem de importação, convenções de nomenclatura e os dois ou três padrões que sua base de código usa que diferem dos padrões comuns. Mantenha-o abaixo de 50 linhas – um arquivo de regras que ninguém mantém se torna um ruído que o modelo aprende a ignorar.
O recurso subestimado são as regras por diretório. Nosso diretório de componentes recebe uma regra: apenas componentes de função, props digitados inline, sem exportação padrão. Nosso diretório de servidores recebe outro: sem importações do lado do cliente, cada manipulador valida a entrada. Essa divisão fez mais pela qualidade da saída do que qualquer coisa que escrevi no arquivo global, porque o modelo vê apenas as regras que se aplicam aos arquivos que está tocando.
Três regras ganharam seu lugar através da pura repetição. Primeiro: 'Após a edição, execute o comando lint existente e corrija todos os erros que você introduziu.' Segundo: 'Corresponda ao estilo de importação do arquivo que você está editando, não ao estilo de sua preferência.' Terceiro: 'Se uma mudança exigir uma nova dependência, pare e pergunte em vez de instalar.' Esse último veio depois que encontrei cinco novos pacotes em um diff que precisava de um.
O que parei de fazer: repetir instruções de estilo em todas as mensagens do chat. Com as regras em vigor, meus prompts descrevem a intenção – o que construir, o que evitar – e o arquivo de regras trata do estilo da casa. O prompt ficou mais curto e a saída ficou mais consistente, que é o jogo inteiro.
Um hábito de manutenção: quando o agente cometer o mesmo erro repetidamente, adicione uma regra em vez de repreendê-lo no chat. As correções de bate-papo morrem com a conversa; arquivos de regras compostos. Meu arquivo de regras cresceu cerca de duas linhas por semana, e cada linha contém uma correção de bug.
Perguntas frequentes:
P: Os arquivos de regras tornam o Cursor mais lento?
R: Não visivelmente. Eles são injetados no contexto junto com o seu prompt. O custo real é um arquivo de regras inchado que dilui a atenção, e é por isso que limito o meu e excluo regras que a base de código superou.
P: As regras devem ser comprometidas com o repo?
R: Sim, se você deseja que toda a equipe se beneficie – trate-os como uma configuração de linter. Mantenha as preferências pessoais nas regras de nível de usuário em vez do arquivo do projeto.
P: Qual a diferença entre as regras e apenas escrever um bom prompt do sistema?
R: As regras se aplicam automaticamente a todas as solicitações em seu escopo, sobrevivem nas sessões e são versionadas com o código. Um prompt do sistema em sua cabeça não beneficia ninguém além de você e desaparece toda vez que você inicia um novo bate-papo.