Boas práticas
Onde cada regra deve ficar
Escolha o lugar de uma regra pelo propósito dela e por quem deve poder alterá-la.
Escolha um lugar
| O que você quer dizer ao HeyDeer | Coloque em | Onde o HeyDeer lê |
|---|---|---|
| Convenções da equipe e contexto do projeto: estrutura, nomenclatura, quais helpers usar | AGENTS.md | O pull request. Um arquivo em subdiretório vale para o próprio diretório. |
| Uma regra que todo pull request que altera determinados arquivos precisa cumprir | .agents/checks/ | A branch base |
| Um método ou conhecimento de domínio que várias verificações compartilham | .agents/skills/ | O pull request |
| Prioridades de revisão, o que deixar de lado e tom para todos os repositórios | Instruções da organização | Configurações da organização → Instruções de revisão |
| O mesmo para um repositório | Instruções do repositório | Repositórios → (um repositório) → Instruções de revisão |
| Contexto fora do repositório, como tickets ou documentos internos | Servidores MCP | Configurações da organização → Servidores MCP, ou os Servidores MCP de um repositório |
| Quais pull requests são revisados automaticamente | Filtros de revisão automática | Regras de revisão |
| Quantos problemas encontrados são publicados | Escopo do feedback | Regras de revisão |
| O idioma em que o HeyDeer escreve | Idioma da revisão | Regras de revisão |
As instruções de revisão têm precedência sobre o AGENTS.md quando os dois entram em conflito.
Branch base ou pull request
As verificações vêm da branch base, então um pull request não pode enfraquecer uma verificação que as próprias alterações dele quebrariam. Uma nova verificação vale para pull requests revisados depois do merge dela.
O AGENTS.md e as skills vêm do pull request, então sempre correspondem ao código em revisão, e qualquer pessoa que abra um pull request pode editá-los. Coloque as regras que precisam valer, diga o que disser um pull request, em uma verificação ou nas instruções de revisão.