Os agentes leem seu repositório. Isso cobre a maior parte do que eles precisam — mas não as decisões que estão na mente das pessoas, em uma wiki ou em uma conversa de dois anos atrás.
Contexto do projeto combina as instruções do repositório com as orientações que você mantém em Coroid.
As instruções do repositório também são contexto
Coroid lê arquivos de memória como o arquivo de nível raiz AGENTS.md, CLAUDE.md e
GEMINI.md, além das regras do Cursor em .cursor/rules. As fontes habilitadas são incluídas no contexto do projeto do agente antes do início do trabalho. Configurações locais do repositório @ podem trazer outros arquivos de instrução. Imports repetidos, ciclos e corpos de instrução idênticos são incluídos apenas uma vez. Você não precisa copiar essas instruções para uma entrada de contexto do aplicativo.
Em Configurações → Conhecimento → Contexto, Fontes do repositório controlam quais arquivos os agentes recebem, enquanto Contextos do aplicativo armazenam notas manuais e contexto gerado em Coroid. As fontes são habilitadas a menos que sejam desativadas explicitamente; desative instruções sobrepostas ou conflitantes que você não deseja combinar.
As instruções do repositório viajam com o código no Git. Os contextos do aplicativo são úteis para orientações e referências que você mantém fora do repositório. Ambos precisam de manutenção quando uma convenção muda. Veja Configurações de contexto do projeto para caminhos suportados, detecção de arquivos e controles.
O que o Coroid determina sozinho
Somente a partir do repositório, os agentes podem ver:
- as linguagens, frameworks e bibliotecas em uso
- como o projeto é compilado, testado e executado
- padrões existentes — como erros são tratados, como os módulos são estruturados e como as coisas são nomeadas
- o que depende do quê
Você não precisa documentar nada disso. Reafirmar essas informações é um esforço desperdiçado e corre o risco de ficar desatualizado em relação ao código, que é a fonte mais autoritativa de qualquer forma.
O que ele não consegue inferir
O código mostra o que você fez, nunca porquê:
- uma biblioteca escolhida em vez de uma alternativa óbvia por um motivo que ainda é válido
- um padrão que parece duplicação, mas é uma separação deliberada
- um módulo que ninguém deve tocar sem falar com uma equipe específica
- convenções que vocês acordaram, mas ainda não aplicaram em lugar nenhum
- restrições externas ao código-fonte — conformidade, contratos, uma migração em andamento
Isso é o que deve fazer parte do contexto do projeto. O teste é simples: alguém conseguiria trabalhar apenas lendo o repositório? Se sim, deixe de fora. Se não, anote.
O repositório mostra o quê
Os agentes leem isso em toda tarefa. Não há necessidade de reafirmar.
- Linguagens, frameworks e bibliotecas
- Como é compilado, testado e executado
- Padrões e nomenclaturas existentes
- O que depende do quê
Você adiciona o porquê
O contexto do projeto contém o que vive na mente das pessoas.
- Por que uma biblioteca foi escolhida em vez de uma alternativa óbvia
- Duplicação que é uma separação deliberada
- Módulos que ninguém deve tocar sem autorização de uma equipe específica
- Convenções acordadas, mas ainda não aplicadas em nenhum lugar
- Restrições externas: conformidade, contratos, uma migração em andamento
O teste: Alguém que leia apenas o repositório conseguiria resolver isso? Se sim, ignore. Se não, anote.
Adicionando contexto
Anexe documentos, políticas e referências na seção de Contexto do projeto. Notas de arquitetura, registros de decisões, guias de estilo e contratos do API funcionam bem.
Um bom contexto é curto e específico. Um guia de integração de 40 páginas escrito para humanos é majoritariamente narrativa; os três parágrafos nele que indicam restrições reais são o que importam. Extraia esses trechos.
Contexto por tarefa
O contexto anexado ao projeto se aplica a tudo. Para algo relevante a uma única tarefa — um ticket, um documento de design, um relatório de cliente — anexe-o à tarefa em vez disso.
Mantenha o contexto do projeto apenas para informações permanentes e verdadeiras. Uma nota específica de tarefa no contexto do projeto vira ruído em todas as tarefas futuras.
Manter a precisão
Um contexto desatualizado é pior do que nenhum contexto, pois os agentes o tratam como autoritativo. Quando uma convenção mudar, atualize o contexto na mesma alteração que modifica o código.
Se você perceber que está corrigindo repetidamente a mesma coisa nos comentários de retrabalho, isso indica que algo está faltando no contexto — ou que algo nele está incorreto.