Os agentes leem seu código e os arquivos de instrução do seu repositório. Contexto reúne esses arquivos de memória com as notas do projeto, o contexto gerado e as referências.
Para entender o motivo de algo estar aqui, leia Contexto do projeto em Conceitos. Esta página aborda como gerenciá-lo.
Arquivos de memória do repositório
Abrir Configurações → Conhecimento → Contexto e procure em Fontes do repositório. O Coroid lê esses arquivos do repositório conectado:
AGENTS.mdna raiz do repositório: instruções gerais para agentesCLAUDE.mdna raiz do repositório: instruções para o ClaudeGEMINI.mdna raiz do repositório: instruções para o Gemini.cursor/rules: regras de projeto do Cursor, seja o diretório de.mdcarquivos de regra (incluindo subpastas) ou um único arquivo legado
Esses são frequentemente chamados de arquivos de memória. O conteúdo habilitado deles é incluído no contexto do projeto do agente antes do início do trabalho. Os nomes não os restringem a um modelo específico: as fontes habilitadas são combinadas para os agentes do Coroid.
Os arquivos existentes aparecem com um Editar ação, uma contagem estimada de tokens e uma switch que controla se os agentes receberão esses arquivos. As fontes ficam habilitadas a menos que você explícito as desative. Se vários arquivos se repetirem ou contradizerem uns aos outros, mantenha habilitadas as fontes que deseja que os agentes sigam e desative as outras.
Salvar uma edição em um projeto com um repositório GitHub ou GitLab conectado abre uma pull request com a alteração, em uma nova branch a partir da pull request base do projeto. O Coroid não faz commit na sua branch padrão, e os agentes leem a nova versão assim que a pull request for mesclada. Um projeto cujo repositório é hospedado pelo Coroid recebe um commit. O editor informa isso antes de você salvar.
O Coroid lê as regras do Cursor da mesma forma que o Cursor as aplica:
| Regra | O que os agentes recebem |
|---|---|
alwaysApply: true | Toda a regra |
globs conjunto | Toda a regra, com os arquivos aos quais ela se aplica |
Apenas um description | O caminho e a descrição da regra, para que o agente a leia quando for relevante |
| Nenhum desses | Nada: o Cursor a aplica somente quando alguém a menciona |
Um arquivo comum .md em .cursor/rules é ignorado, pois o Cursor também o ignora. As regras no
diretório são editadas no repositório, então essa linha não tem Editar ação.
Criar significa que o arquivo foi confirmado como ausente no checkout do repositório do Coroid. Se a leitura falhar, a página oferece Tentar novamente; uma falha de acesso não indica que o arquivo está ausente. Verifique se o arquivo foi commitado na branch do repositório conectado. Para a execução de tarefas, o agente lê o checkout da tarefa, portanto as alterações nos arquivos de instrução dessa branch se aplicam à tarefa.
Os arquivos de memória habilitados podem importar Markdown do repositório com @path, por exemplo
@AGENTS.md em CLAUDE.md ou @docs/conventions.md. Os caminhos são resolvidos de forma relativa ao
arquivo que contém a referência. O Coroid segue importações aninhadas, interrompe ciclos
e inclui cada arquivo e cada corpo de instrução idêntico apenas uma vez. Importações dentro de exemplos de código e endereços de e-mail são deixadas de lado. Referências fora do
repositório não são carregadas, e as importações não podem contornar uma fonte de repositório explicitamente desabilitada.
Apenas as fontes listadas são detectadas automaticamente. Uma AGENTS.md pode
ser incluída por meio de uma @ importação; o escopo do diretório dela não é inferido.
Contextos de aplicativo
Em Contextos de aplicativo, mantenha instruções e referências armazenadas no Coroid. Notas manuais e o contexto de projeto gerado podem ser habilitados ou desabilitados independentemente dos arquivos do repositório. Use essas entradas para informações que pertencem fora do Git.
Adicionar contexto
Escolher Adicionar contexto e adicione uma entrada. Cada uma tem um título e corpo, e pode ser editada ou removida posteriormente.
Boas entradas são curtas, específicas e duráveis. Decisões de arquitetura, convenções de estilo, contratos do API, limites de propriedade e proibições explícitas se encaixam aqui. A narrativa de onboarding e qualquer coisa já óbvia no repositório não devem ser incluídas.
Mantenha as entradas separadas e nomeadas
Uma entrada por tópico, com título indicando o que ela abrange. "Convenções de tratamento de erros" e "Módulos congelados" são recuperáveis; uma única entrada chamada "Notas" contendo ambos não é.
Isso é importante porque o contexto é carregado seletivamente com base no trabalho em questão — veja Habilidades progressivas. Entradas bem separadas permitem que a entrada certa seja carregada para a tarefa certa.
Referências
Além das entradas escritas, você pode anexar referências — links e documentos que apontam para materiais armazenados em outro lugar. Use-os quando a cópia oficial estiver em uma wiki ou ferramenta de design e você não quiser que uma segunda cópia fique desatualizada.
Contexto por tarefa
O contexto do projeto se aplica a tudo nele. Para materiais relacionados a uma única tarefa — um chamado, um relatório de cliente, um documento de design — anexe-os àquela tarefa específica. Uma nota específica de tarefa incluída no contexto do projeto vira ruído em todas as tarefas futuras.
Mantendo a precisão
Um contexto desatualizado é pior do que a ausência de contexto, pois os agentes o tratam como autoritativo. Quando uma convenção mudar, atualize a entrada na mesma alteração que modifica o código.
Revisando o que existe
Leia seu contexto ocasionalmente como se fosse um novo usuário. As entradas se acumulam, e aquelas criadas durante uma migração concluída há um ano agora são ativamente enganosas.