Configure com o seu assistente AI

Esta página é um guia destinado ao assistente AI: Claude Code, Codex, Cursor ou qualquer outro assistente capaz de ler uma página da web e, preferencialmente, trabalhar em uma cópia local do seu repositório. Ele orienta o assistente na configuração do Coroid para um ou mais repositórios. Em todas as etapas que exigem intervenção humana — como login, concessão de acesso, inserção de segredos ou aprovação de alterações — o processo é interrompido para que você possa agir.

Entregue este guia ao seu assistente#

Abra seu assistente no repositório onde deseja que o Coroid atue e forneça a ele este comando:

Set up Coroid for this repository. Follow the runbook at
https://coroid.ai/docs/export/en-US/getting-started/assistant-setup.md
step by step. Ask me before you change anything, and never ask me to paste a
password or token into this chat.

Para vários repositórios, abra o assistente em um diretório que os contenha todos e especifique seus nomes no comando. O assistente realizará a inspeção e a verificação, indicando exatamente o que você deve fazer em cada etapa que requer sua participação.

Regras básicas para o assistente#

Você está configurando o Coroid, uma plataforma de produção de software do tipo AI que transforma a descrição de uma tarefa em um pull request testado e revisado dentro do repositório do usuário. Siga estas regras durante todo o processo:

1. O usuário age; você prepara. Você não pode se cadastrar, fazer login, aceitar termos, instalar aplicativos ou conceder acesso em nome do usuário. Indique exatamente o que deve ser feito e onde, e aguarde a confirmação de que a tarefa foi concluída.
2. Mantenha os segredos fora da conversa. Nunca peça senhas, tokens de acesso pessoal, chaves de provedor ou tokens do MCP. O usuário insere esses segredos no portal do Coroid ou no próprio terminal. Se algum deles for colado no chat, oriente o usuário a revogá-lo e gerar um novo.
3. Pergunte antes de cada alteração: commits, branches e pull requests no repositório do usuário, nos projetos do Coroid e nos convites.
4. Verifique cada etapa antes de prosseguir. Se uma verificação falhar, siga as instruções dadas nessa etapa e continue somente após a aprovação ou se o usuário decidir ignorá-la.
5. Siga o produto, não suas suposições. Se o portal exibir algo que este guia não descreve, informe ao usuário o que você observou e siga as orientações do portal. Não crie configurações fictícias.
6. Mantenha um registro da configuração de cada etapa e seu resultado, para referência final.

Cada etapa vincula as páginas com os detalhes. https://coroid.ai/llms.txt O sistema indexa toda a documentação.

Etapa 1: Definir o plano#

Faça todas essas perguntas ao usuário de uma só vez, e não uma por uma:

Em seguida, repita o plano: os passos abaixo que exigem a intervenção do usuário e os repositórios em escopo.

Veja Planos e preços, Limites e cotas e Sincronizado ou apenas local.

Passo 2: Verifique se cada repositório compila e executa testes a partir de uma cópia limpa.#

Esta é a tarefa mais útil que você pode executar. Cada tarefa do Coroid roda em um ambiente Linux limpo e descartável: um clone novo, sem nada em cache e sem nenhum software instalado além da cadeia de ferramentas da imagem. Um agente que não consegue compilar e testar o projeto não pode validar seu próprio trabalho, e suas tarefas falham na verificação por motivos não relacionados à alteração.

Se você conseguir trabalhar no repositório localmente, faça o seguinte para cada um deles:

1. Identifique as linguagens, o gerenciador de pacotes e se se trata de um monorepo.
2. Encontre os comandos de instalação, compilação e teste no README, na configuração de CI e nos manifestos.
3. Pergunte antes de executar qualquer coisa. Em seguida, clone o repositório em um diretório temporário vazio e execute os comandos de instalação, compilação e teste ali, sem nenhuma outra configuração prévia. A cópia de trabalho do usuário possui caches e arquivos que mascaram problemas. .env arquivos que ocultam problemas.
4. Anote tudo o que o processo de execução precisou e que um clone novo não possui:
   • Serviços esperados pelos testes, como banco de dados, cache ou fila.
   • Etapas anteriores aos testes, como geração de código, migrações ou fixtures.
   • Variáveis de ambiente ou um .env arquivo que não foi commitado.
   • Registros de pacotes privados.
   • Um runtime que não está no ambiente do agente.

Nunca execute comandos que façam deploy, publiquem ou interajam com ambientes compartilhados. Se a suíte de testes for lenta ou utilizar serviços pagos, peça autorização ao usuário antes.

Informe uma breve verificação de prontidão por repositório: os comandos utilizados, o tempo de execução da suíte, o que foi aprovado e cada lacuna identificada com uma solução proposta.

A ausência de um runtime também não é um impedimento: um contêiner que inclua a cadeia de ferramentas resolve isso. Se você não conseguir acessar o repositório localmente, colete o máximo de informações possível do usuário e registre que a verificação do clone limpo não foi realizada.

Consulte Configuração de compilação e teste e Suporte a linguagens e o ambiente do agente.

Passo 3: Escreva as instruções que os agentes do Coroid irão ler.#

Antes de cada tarefa, os agentes do Coroid leem os arquivos de memória no repositório: AGENTS.md, CLAUDE.md ou GEMINI.md na raiz, e .cursor/rules. Os comandos que você validou no Passo 2 devem ser incluídos ali.

Proponha um AGENTS.md, ou uma adição ao existente, que contenha:

• Os comandos de instalação, compilação e teste, validados a partir de um clone limpo, e o diretório onde devem ser executados.
• As etapas e serviços necessários para os testes.
• Como executar o conjunto mais restrito e útil de testes, como um pacote ou um arquivo específico.
• Convenções e limites que o código não demonstra: módulos congelados, áreas a não serem alteradas, dependências a não serem adicionadas.

Deixe de fora o que já está explícito no código e mantenha o arquivo curto. Se CLAUDE.md ou .cursor/rules contiverem as mesmas instruções, mantenha-as apenas em AGENTS.md e importe-o do outro arquivo com uma linha @AGENTS.md .

Mostre ao usuário o diff. Com sua aprovação, faça o commit em uma nova branch e abra um pull request, ou deixe que ele faça o commit. O código precisa chegar à branch base antes da primeira tarefa, pois cada tarefa lê os arquivos de memória a partir de seu próprio checkout dessa branch. Trate as correções da Etapa 2 que o usuário aceitou da mesma forma.

Veja Configurações de contexto do projeto e Contexto do projeto.

Etapa 4: Conta e organização (o usuário)#

Pule esta etapa se o usuário já pertencer a uma organização Coroid como Proprietário ou Administrador.

Peça ao usuário para:

1. se cadastrar em https://client.coroid.ai/auth/signup com seu e-mail corporativo e verificar o endereço
2. aceitar os termos de serviço
3. criar a organização

Verifique: se o usuário consegue abrir https://client.coroid.ai/projects. A pessoa que conclui essa configuração precisa ter a função de Proprietário ou Administrador, pois apenas essas funções permitem conectar o controle de versão e adicionar chaves de provedor.

Veja Crie sua conta e organização.

Etapa 5: Conectar o controle de versão (o usuário)#

Reveja os requisitos de acesso com o usuário antes de começar. Uma instalação interrompida para esperar a aprovação de outra pessoa é a razão comum pela qual essa etapa leva um dia em vez de um minuto.

GitHub#

O usuário abre Configurações → Conexões → Controle de versão (https://client.coroid.ai/settings/connections/source-control).

GitHub App: na tela de instalação do GitHub, o usuário seleciona Selecione apenas repositórios e escolhe os acordados na Etapa 1. O app continua funcionando mesmo quando a pessoa que o instalou sai, recebe eventos de webhook e é o que permite que o Coroid publique suas verificações nos pull requests. Um token não consegue publicar verificações do GitHub.

Token de acesso pessoal: o usuário cria no GitHub com prazo de expiração e cola no portal do Coroid. Prefira um token refinado limitado aos repositórios acordados. Os pull requests são atribuídos ao proprietário do token, e a conexão é interrompida se essa pessoa perder acesso.

GitLab#

GitLab está em pré-visualização privada e aparece apenas em contas onde está habilitado. Ele se conecta com um token de acesso pessoal com o api escopo. Se o GitLab não aparecer em Controle de versão, oriente o usuário a entrar em contato com o Coroid e não planeje nada com base nele.

Proteção de branch#

Coroid abre pull requests comuns, portanto as regras de proteção de branch, verificações obrigatórias e regras de revisão continuam valendo. Recomenda-se manter a proteção ativada. Se as regras exigirem commits assinados ou uma verificação de status que Coroid não consiga gerar, seus pull requests serão abertos e permanecerão não mescláveis. Informe o usuário e não altere suas regras.

Verificar: o provedor aparece como conectado em Controle de versão. A prova real vem na Etapa 6, quando os repositórios aparecem na lista de Projetos.

Consulte Conecte seu código, GitHub, GitLab e Configurações de repositório e branch.

Etapa 6: Criar os projetos (o usuário)#

Crie um projeto por repositório; nunca crie dois projetos para um único repositório. O usuário abre Projetos → Novo (https://client.coroid.ai/projects/new) e, para cada repositório:

1. seleciona-o a partir do provedor conectado ou usa Conectar com URL para um repositório público
2. escolhe o Modo de repositório: Sincronizado, onde Coroid envia branches e abre pull requests, ou Apenas local, onde Coroid nunca grava no repositório até que alguém escolha Iniciar sincronização
3. verifica o branch padrão
4. cria o projeto

Se a equipe fizer merge em algo diferente do branch padrão, como develop, defina o branch base nas configurações de repositório do projeto. Um branch base incorreto envia pull requests para um branch que ninguém revisa.

Se um repositório estiver ausente da lista, a causa é quase sempre uma das seguintes:

• o aplicativo GitHub não recebeu permissão para acessar esse repositório
• o escopo do token é muito restrito para listá-lo
• o repositório pertence a uma organização diferente daquela conectada

Consulte Crie seu primeiro projeto e Configurações de repositório e branch.

Etapa 7: Verificar o que Coroid encontrou#

Peça ao usuário para abrir a visão geral de cada projeto e ler os Repositório detalhes e tudo o que estiver listado em Finalizar configuração:

• Status e Branch: o repositório foi clonado e está no branch base acordado. Se a visão geral indicar que o repositório ainda não foi clonado, o usuário deve escolher Clonar repositório.
• Pilha: as linguagens, frameworks, gerenciadores de pacotes e ferramentas de teste que Coroid detectou. Compare-os com sua verificação de prontidão. Se a pilha estiver vazia ou incorreta após a primeira sincronização, o usuário poderá escanear novamente a partir daí.
• Finalizar configuração: itens como "Dependências não foram instaladas corretamente" indicam as mesmas falhas da Etapa 2. Resolva-as com o usuário.

Em seguida, o usuário abre as Configurações → Conhecimento → Contexto. O arquivo de memória da Etapa 3 deve estar listado em Fontes de repositório e estar ativado. Se exibir Criar em vez disso, o arquivo ainda não chegou ao branch conectado.

Consulte Configurações de contexto do projeto e Configuração de compilação e teste.

Etapa 8: Configurações da organização (opcional)#

Pergunte se o usuário deseja configurar alguma dessas opções agora. Todas possuem valores padrão viáveis:

• Membros, em Configurações → Membros: as pessoas que irão revisar pull requests como Proprietário, Administrador, Membro ou Revisor. Recomenda-se definir como Administrador apenas para quem precisar alterar políticas e chaves de provedor. É necessário o plano Professional.
• Chaves de provedor, em Configurações → Chaves de provedor: somente para usar as contas de provedor de modelo próprias da organização. O usuário insere a chave no portal. Recomenda-se usar uma chave restrita com limite de gastos definido pelo provedor.
• Configurações de outra organização: exporte um pacote de configurações lá e importe-o em Configurações → Dados → Exportar configurações. Os segredos são transmitidos como placeholders, portanto cada needsRebind item na pré-visualização requer atenção.

Veja Crie sua conta e organização, Chaves de provedor e Exportar e importar configurações.

Etapa 9: Conecte-se ao Coroid (opcional)#

Se seu cliente for compatível com servidores MCP remotos, você poderá acessar o Coroid por meio de seu servidor MCP em https://api.coroid.ai/mcp. A configuração não depende disso, mas permite verificar os projetos e ajudar o usuário a executar tarefas posteriormente.

1. O usuário abre Configurações → Automação → Coroid MCP server (https://client.coroid.ai/settings/automation/coroid-mcp). Se essa opção não estiver disponível para sua organização, pule esta etapa.
2. Configuração do cliente mostra os comandos específicos para cada cliente. Com OAuth, o usuário aprova seu acesso no navegador. Com token de acesso pessoal, o usuário cria-o em Tokens de acesso e armazena-o em uma variável de ambiente no próprio shell. Você nunca precisa visualizar o valor.
3. Recomenda-se conceder o mínimo de acesso necessário: mcp.read para verificar a configuração, além de mcp.work.write somente se você for criar tarefas. Limite o token a esses projetos, defina um prazo de validade e configure Políticas de automação antes que qualquer cliente execute processos sem supervisão.

Verifique: chame list_projects, depois get_project para cada projeto da Etapa 6 e confirme o repositório e o branch.

Use apenas api.coroid.ai para MCP. O nome de host do portal do cliente não o disponibiliza.

Veja Coroid como servidor MCP.

Etapa 10: Rascunhe a primeira tarefa#

Termine rascunhando uma pequena primeira tarefa com o usuário em um dos novos projetos. Uma boa primeira tarefa é real, pequena, próxima aos testes existentes e tem um objetivo claro a ser alcançado. Evite autenticação, pagamentos, migrações de dados, tarefas de limpeza indefinidas e qualquer coisa que exija uma decisão de design ainda não tomada.

Descreva o resultado, não a implementação: o que deve estar certo quando o trabalho for concluído, quais arquivos são relevantes e o que não deve ser alterado. O usuário envia a tarefa a partir de Novo trabalho (https://client.coroid.ai/work/new), lê a especificação e aprova o plano. A execução de tarefas consome horas de agente; o plano Gratuito inclui 2 por dia UTC, então deixe o usuário decidir quando ela será executada.

Veja Execute sua primeira tarefa e Especificações.

Etapa 11: Faça a entrega#

Forneça ao usuário o registro de configuração:

• cada repositório, seu projeto, modo do repositório e ramificação base
• como o controle de versão está conectado e quem detém a conexão: o instalador do aplicativo, ou o proprietário do token e sua data de expiração
• por repositório, as correções aplicadas, as pendentes (como um pull request aberto com AGENTS.md), e aquelas que o usuário optou por deixar de lado
• as configurações opcionais definidas e ignoradas, além da primeira tarefa rascunhada

Em seguida, indique ao usuário para acessar Revisar e mesclar o resultado para saber o que vem com o primeiro pull request.

Próximo#

Criar sua conta e organização — a mesma configuração, feita manualmente.