Skip to main content

Cursor Rules – Personalizando sua Experiência de Desenvolvimento

· 6 min read
Bruno Carneiro
Bruno Carneiro
Fundador da @TautornTech

Uma das funcionalidades mais poderosas do Cursor são as Rules (Regras). Elas permitem que você crie instruções persistentes que guiam o comportamento do Agent, garantindo consistência, padronização e personalização completa da sua experiência de desenvolvimento.

O que são Cursor Rules?​

Rules são instruções de nível de sistema que fornecem contexto persistente para o Agent. Diferente de prompts em uma conversa, as Rules são:

  • Persistentes: Aplicadas automaticamente em todas as conversas
  • Reutilizáveis: Compartilhadas entre membros do time
  • Contextuais: Podem ser aplicadas baseadas em arquivos, padrões ou manualmente
  • Versionáveis: Armazenadas em .cursor/rules e versionadas com Git

Tipos de Rules​

Cursor suporta quatro tipos de Rules:

1. Project Rules​

Armazenadas em .cursor/rules, versionadas e escopadas ao seu codebase. Perfeitas para:

  • Conhecimento específico do domínio
  • Padrões de arquitetura do projeto
  • Workflows automatizados
  • Templates e convenções

2. User Rules​

Regras globais no seu ambiente Cursor. Usadas para:

  • Estilo de comunicação preferido
  • Convenções de código pessoais
  • Preferências de desenvolvimento

3. Team Rules​

Gerenciadas no dashboard do Cursor (planos Team e Enterprise). Permitem:

  • Padrões organizacionais
  • Compliance e segurança
  • Boas práticas da empresa
  • Enforçamento obrigatório

4. AGENTS.md​

Arquivo simples de markdown na raiz do projeto. Alternativa mais simples para casos diretos.

Como Rules Funcionam?​

As Rules são incluídas no início do contexto do modelo, fornecendo orientação consistente. Isso significa que:

  1. Contexto Persistente: O Agent sempre sabe as regras do projeto
  2. Consistência: Mesmas instruções aplicadas em todas as conversas
  3. Menos Repetição: Não precisa repetir instruções a cada conversa
  4. Compartilhamento: Time inteiro usa as mesmas regras

Estrutura de uma Rule​

Cada Rule é uma pasta contendo um arquivo RULE.md:

.cursor/rules/
  my-rule/
    RULE.md           # Arquivo principal da regra
    scripts/          # Scripts auxiliares (opcional)

Formato do RULE.md​

---
description: "Esta regra define padrões para componentes frontend"
alwaysApply: false
globs: ["**/*.tsx", "**/*.ts"]
---

# Minha Rule

Quando trabalhar em componentes:
- Sempre use TypeScript
- Prefira componentes funcionais
- Use Tailwind para estilização
- Siga o padrão de nomenclatura do projeto

@component-template.tsx

Tipos de Aplicação​

Always Apply​

Aplicada em toda conversa. Use para regras fundamentais do projeto.

---
alwaysApply: true
---

- Sempre use TypeScript
- Siga os padrões de código do projeto

Apply Intelligently​

O Agent decide quando aplicar baseado na descrição. Use para regras contextuais.

---
description: "Padrões para componentes React"
alwaysApply: false
---

Quando criar componentes React:
- Use functional components
- Prefira hooks sobre classes

Apply to Specific Files​

Aplicada quando arquivos correspondem ao padrão. Use para regras específicas de tipo de arquivo.

---
globs: ["**/*.test.ts", "**/*.spec.ts"]
---

Para arquivos de teste:
- Use Jest como framework
- Siga o padrão AAA (Arrange, Act, Assert)

Apply Manually​

Aplicada quando mencionada com @ no chat. Use para regras opcionais.

---
description: "Template para criar novos serviços"
alwaysApply: false
---

@my-rule Crie um novo serviço seguindo este template

Exemplos Práticos​

Rule para Padrões de API​

---
description: "Padrões para criação de endpoints de API"
globs: ["**/api/**/*.ts", "**/routes/**/*.ts"]
---

# API Standards

Ao criar endpoints:
- Use validação com Zod
- Retorne status codes apropriados
- Inclua tratamento de erros
- Documente com JSDoc
- Adicione testes unitários

@api-template.ts

Rule para Componentes React​

---
description: "Estrutura padrão para componentes React"
globs: ["**/*.tsx"]
---

# React Component Standards

Componentes devem:
- Ser funcionais
- Usar TypeScript
- Ter props tipadas
- Seguir naming convention: PascalCase
- Estar em arquivos separados

Estrutura:
```tsx
interface Props {
  // props aqui
}

export function ComponentName({ prop }: Props) {
  // implementação
}

### Rule para Workflows

```markdown
---
description: "Workflow para análise de aplicação"
alwaysApply: false
---

Quando pedir para analisar a aplicação:
1. Execute `npm run dev`
2. Capture logs do console
3. Analise performance
4. Sugira melhorias priorizadas

Best Practices​

✅ DO​

  • Seja específico: Instruções claras e concretas
  • Use exemplos: Referencie arquivos com @filename
  • Mantenha focado: Rules menores e específicas
  • Documente: Explique o "porquê" das regras
  • Version controle: Mantenha Rules no Git

❌ DON'T​

  • Não seja vago: Evite "seja consistente"
  • Não exagere: Rules muito longas são menos efetivas
  • Não duplique: Reutilize Rules quando possível
  • Não ignore contexto: Rules devem fazer sentido para o projeto

Benefícios no Dia a Dia​

Consistência​

  • Todo o time segue os mesmos padrões
  • Código mais uniforme e manutenível
  • Menos debates sobre estilo

Produtividade​

  • Menos tempo explicando padrões
  • Agent já conhece as regras do projeto
  • Menos erros de convenção

Onboarding​

  • Novos membros do time aprendem padrões rapidamente
  • Documentação viva e sempre atualizada
  • Menos perguntas sobre "como fazer"

Qualidade​

  • Padrões aplicados automaticamente
  • Menos code review sobre estilo
  • Foco em lógica e arquitetura

Case Study: Rules para Documentação​

Em um projeto recente, criamos Rules específicas para documentação:

---
description: "Padrões para documentação técnica"
globs: ["**/docs/**/*.md"]
---

# Documentation Standards

Ao criar documentação:
- Use Markdown com Docusaurus
- Siga estrutura: Overview → Concepts → Usage → API
- Inclua exemplos práticos
- Valide contra código fonte
- Mantenha links atualizados

Tópicos principais:
- Datasets
- Training
- Inference Server
- Connectors

Isso garantiu que toda documentação criada seguisse o mesmo padrão, melhorando significativamente a qualidade e consistência.

Integração com Commands​

Rules funcionam perfeitamente com Commands. Você pode criar Commands que utilizam as Rules do projeto, criando workflows poderosos e reutilizáveis.

Conclusão​

Cursor Rules são fundamentais para criar uma experiência de desenvolvimento verdadeiramente personalizada. Elas transformam o Cursor de uma ferramenta genérica em um assistente que entende profundamente seu projeto e seus padrões.

Ao investir tempo criando Rules bem estruturadas, você:

  • Aumenta a produtividade do time
  • Melhora a qualidade do código
  • Acelera o onboarding
  • Padroniza workflows

No próximo artigo, vamos explorar Cursor Commands e como criar workflows automatizados poderosos.

Próximos Passos​

  • Crie sua primeira Rule para um padrão do seu projeto
  • Explore diferentes tipos de aplicação
  • Compartilhe Rules com o time
  • Leia sobre Cursor Commands

Aprofunde seu Conhecimento​

Quer aprender mais sobre Cursor? Explore nossa trilha completa de documentação:

Artigos Relacionados:

Referências: