Skip to main content

Command Palette

Search for a command to run...

Agentes na nuvem

Automações

As Automações do Cherri Code executam agentes na nuvem em segundo plano, em um intervalo programado ou em resposta a eventos do GitHub, GitLab, Slack, webhooks, Linear e muito mais.

As Automações podem automatizar tarefas como revisar commits recentes de PRs em busca de bugs, realizar uma análise aprofundada em busca de vulnerabilidades, triar bugs no Slack e resumir alterações na sua base de código em um intervalo programado.

Primeiros passos

Crie uma nova automação na Janela de Agentes, em cursor.com/automations, com a skill /automate em uma sessão de agente local ou a partir de um modelo no Cherri Code Marketplace.

A skill /automate permite descrever o fluxo de trabalho desejado em linguagem simples. O Cherri Code configura os gatilhos, as instruções e as ferramentas da automação para você.

Em qualquer caso:

  1. Escolha um gatilho, por exemplo, a cada hora ou quando uma pull request for aberta.
  2. Escreva um prompt com instruções para a automação.
  3. Escolha as ferramentas opcionais que o agente pode usar, como Enviar para o Slack, Comentar na Pull Request ou ferramentas do MCP.
  4. Escolha se a automação precisa de um repositório, vários repositórios ou nenhum repositório.
  5. Salve e ative a automação.

A página de Automações também inclui três agentes gerenciados pelo Cherri Code:

  • O Bugbot revisa pull requests em busca de bugs e problemas de qualidade do código.
  • Os Agentes de Segurança revisam pull requests e examinam bases de código em busca de vulnerabilidades.
  • O Roteamento e aprovação de PR direciona pull requests aos revisores e pode aprovar alterações de baixo risco.

Faturamento

As automações criam agentes na nuvem e são cobradas com base no uso desses agentes. Consulte preços do agente em nuvem para mais detalhes.

A cobrança do uso depende da opção Executar como em Compartilhar:

  • Eu: O uso é cobrado de você. Outros membros veem essa opção como Criador.
  • Conta de serviço: O uso é cobrado do pool de uso da equipe. A automação é executada com sua própria conta de serviço dedicada, portanto não consome o uso pessoal de nenhum membro.

Em contas pessoais, a cobrança é sempre feita para você. Elas não têm menu Compartilhar.

Gatilhos

Os gatilhos determinam quando uma automação é executada. Uma automação pode ter mais de um gatilho e é executada quando qualquer um deles é acionado.

Gatilhos agendados

Os gatilhos agendados são executados em intervalos regulares. Escolha uma das opções predefinidas ou insira uma expressão cron para ter controle preciso.

Os gatilhos agendados podem ser executados com atraso, mas não serão iniciados antes do horário indicado.

Gatilhos de controle de versão

Os gatilhos de controle de versão respondem a eventos de pull request e push do provedor de Git conectado: GitHub, GitLab e Bitbucket Cloud. Conecte a automação a um repositório ou a um ambiente multi-repo.

Todos os provedores conectados oferecem suporte aos principais gatilhos de pull request e push:

  • Rascunho aberto - Quando um pull request em rascunho é criado.
  • Pull request aberto - Quando um PR não rascunho é criado ou um rascunho é marcado como pronto para revisão.
  • Pull request atualizado - Quando novos commits são enviados por push para um PR existente.
  • Pull request mesclado - Quando um PR é mesclado.
  • Push para a branch - Quando commits são enviados por push para uma branch específica fora de um pull request.
  • Comentário adicionado - Quando alguém deixa um comentário de nível superior em um pull request.

O GitHub oferece suporte ao maior número de gatilhos. GitLab e Bitbucket oferecem suporte aos principais gatilhos acima, além de alguns extras listados nas respectivas seções abaixo.

Gatilhos do GitHub

O GitHub é o provedor de referência e oferece suporte a todos os gatilhos de controle de versão. Além dos gatilhos principais, oferece também:

  • Rótulo da pull request alterado - Quando um rótulo específico ou qualquer rótulo é adicionado ou removido de uma pull request.
  • Rótulo da issue alterado - Quando um rótulo é adicionado ou removido de uma issue que não é uma PR.
  • CI concluída - Quando uma verificação do GitHub é concluída em uma pull request ou branch.
  • Comentário na issue - Quando um comentário é feito em uma issue que não é uma PR.
  • Comentário de revisão de PR - Quando um comentário inline é deixado em um diff de pull request.
  • Revisão de PR enviada - Quando uma revisão é enviada como aprovada, com alterações solicitadas ou comentada.
  • Thread de revisão atualizada - Quando uma thread de revisão em uma pull request é marcada como resolvida ou não resolvida.
  • Execução do fluxo de trabalho concluída - Quando uma execução de fluxo de trabalho do GitHub Actions é concluída em uma pull request ou branch.

O Cherri Code Marketplace inclui modelos para triagem de falhas do GitHub Actions e correção de comentários de revisão de pull request.

Gatilhos do GitLab

Além dos gatilhos principais, o GitLab inclui:

  • Rótulo da pull request alterado - Quando um rótulo é adicionado a uma solicitação de merge ou removido dela.
  • Pull request aprovada - Quando uma solicitação de merge é aprovada.

Gatilhos do Bitbucket

O suporte ao Bitbucket abrange apenas o Bitbucket Cloud (bitbucket.org). Bitbucket Server e Data Center não são compatíveis. Além dos gatilhos principais, ele oferece:

  • Pull request aprovado - Quando um pull request é aprovado.

O Bitbucket Cloud não tem gatilhos para rótulos de pull request nem comentários inline em revisões.

Gatilhos do Slack

Os gatilhos do Slack respondem a eventos da integração do Cherri Code com o Slack.

  • Nova mensagem no canal - Quando uma mensagem é enviada em um canal conectado do Slack. Sem um filtro de mensagens, o gatilho só é acionado para mensagens de nível superior no canal. Adicione um filtro de palavra-chave ou regex se também quiser execuções a partir de respostas em threads.
  • Reação com emoji - Quando alguém reage a uma mensagem do Slack com um emoji específico.
  • Canal criado - Quando um novo canal público do Slack é criado no seu espaço de trabalho.

Gatilhos de webhook

Os gatilhos de webhook criam um endpoint HTTP privado para sua automação. Envie uma solicitação POST ao endpoint para iniciar uma execução. Você pode usar webhooks para conectar automações a sistemas internos, pipelines de CI, ferramentas de monitoramento e muito mais.

Para obter o URL do webhook, primeiro salve a automação. Isso gerará um URL de webhook para chamar e uma chave de API para autenticação.

Gatilhos do Linear

Os gatilhos do Linear respondem a eventos da integração do Cherri Code com o Linear.

  • Issue criada - Quando uma nova issue é criada.
  • Status alterado - Quando o status de uma issue é alterado.
  • Fim do ciclo - Quando um ciclo do Linear é concluído.

Gatilhos do Sentry

Os gatilhos do Sentry são acionados quando ocorrem eventos de erro e de issue no seu projeto do Sentry. Use-os para investigar erros automaticamente, identificar causas raiz e propor correções. Consulte o modelo Investigate Sentry issues no marketplace para ver um exemplo pronto.

  • Issue created - Quando uma nova issue é criada no Sentry.
  • Issue updated - Quando uma issue existente é atualizada, como em uma alteração de status ou atribuição.
  • Any issue event - Corresponde a todos os tipos de eventos de issue.

Gatilhos do PagerDuty

Os gatilhos do PagerDuty são acionados por eventos de incidentes e podem ajudar a fazer a triagem automática ou até mesmo resolver incidentes.

  • Incidente disparado - Quando um novo incidente é criado.
  • Incidente reconhecido - Quando um incidente é reconhecido.
  • Incidente resolvido - Quando um incidente é resolvido.
  • Qualquer evento de incidente - Corresponde a todos os tipos de eventos de incidente.

Ferramentas

O Cherri Code Automações pode ter ferramentas habilitadas para oferecer recursos mais avançados para GitHub, Slack, memória, MCP e muito mais. As automações também incluem o mesmo conjunto básico de ferramentas que outros agentes na nuvem. Consulte recursos do agente em nuvem para mais detalhes.

Criação de pull requests

Automações vinculadas a repositórios podem abrir pull requests após fazer as alterações de código solicitadas pelo prompt da automação. Essa ferramenta é habilitada por padrão para todas as automações.

Comentar em uma pull request

Publica comentários na pull request de destino. Oferece suporte a comentários gerais de revisão e comentários inline no código.

Solicitar revisores

Solicita revisores para uma pull request específica. O agente pode usar git, a memória e outras ferramentas para identificar especialistas no domínio.

Enviar para o Slack

Envia mensagens para um canal do Slack. Você pode selecionar um canal específico ou deixar que o agente escolha dinamicamente qualquer canal.

O agente recebe acesso de leitura aos canais públicos para os quais pode enviar mensagens.

Ler canais do Slack

Concede ao agente acesso somente leitura para listar e ler mensagens em canais públicos do Slack.

Use quando o agente precisar de mais contexto antes de responder ou abrir uma pull request.

Servidor MCP

Conecta um servidor MCP (Model Context Protocol) para que o agente possa usar ferramentas externas e fontes de dados.

Memórias

As memórias permitem que o agente leia e grave notas persistentes entre execuções da mesma automação. Use esse recurso para criar agentes que se lembrem e melhorem ao longo do tempo. Cada memória é armazenada como uma entrada nomeada (MEMORIES.md por padrão), fora do sistema de arquivos de trabalho do agente.

As memórias são habilitadas por padrão, mas podem ser desabilitadas. Elas podem ser visualizadas e editadas na interface de configuração de ferramentas.

Os agentes podem excluir arquivos de memória desatualizados durante execuções da automação. Você também pode excluir arquivos de memória na interface de configuração de ferramentas.

Uso do computador

O uso do computador permite que agentes na nuvem acionados por automações usem um computador como um desenvolvedor usaria. Isso significa que as automações podem operar um navegador, gerar capturas de tela ou gravações, ou usar seus serviços internos. Esse recurso vem incluído por padrão em todas as automações.

Para garantir a eficácia do uso do computador, configure um ambiente de desenvolvimento para sua automação. Depois, quando quiser que o agente mostre o trabalho realizado, você pode solicitar uma demonstração nas instruções da automação. Por exemplo, peça ao agente que inclua uma breve gravação de tela após alterar um fluxo voltado ao usuário.

Configurações de automação

Modelo

Você pode selecionar o modelo que o agente em nuvem usará na sua automação.

Repositórios

Escolha se a automação não precisa de repositório, precisa de um repositório ou de um ambiente com vários repositórios.

A configuração de repositório controla o contexto da base de código de cada execução:

  • Sem repositório: O agente não clona código. Use esta opção para fluxos de trabalho que precisam apenas de Slack, MCP, webhooks, Linear ou PagerDuty. Ele não pode editar código nem abrir pull requests.
  • Repositório único: O agente trabalha em um repositório e uma branch. Use esta opção quando a automação precisar ler, revisar ou alterar código em uma base de código.
  • Ambiente com vários repositórios: O agente trabalha nos repositórios de um ambiente. Use esta opção quando a tarefa abranger várias bases de código.

Para determinados gatilhos, como Slack ou agendamentos cron, o Cherri Code não usa um repositório por padrão. Se a automação precisar fazer alterações no código, especifique em qual repositório ou repositórios os agentes devem trabalhar.

Para gatilhos de controle de versão, é obrigatório especificar um ou mais repositórios.

Automações de um único repositório

Por padrão, uma automação é executada em um repositório e uma branch. Essa é a escolha certa quando o agente deve ler, revisar ou alterar código em uma única base de código.

Os gatilhos de controle de versão identificam o repositório a partir da pull request. Para outros gatilhos, escolha o repositório e a branch nas configurações da automação.

Automações com vários repositórios

Use um ambiente com vários repositórios quando uma automação precisar atuar em vários repositórios. Selecione vários repositórios ao configurar o ambiente ou escolha um ambiente existente no dashboard do Cloud Agents.

Compartilhar

Contas de equipe definem a visibilidade e a identidade em Compartilhar, no cabeçalho de detalhes da automação. Contas pessoais não têm esse menu.

Executar como

  • Eu: A automação é executada com a sua autenticação. O uso é cobrado de você. Outros membros veem esta opção como Criador.
  • Conta de serviço: A automação é executada com uma conta de serviço própria e dedicada. O uso é cobrado do pool de uso da equipe. Somente Admins da equipe podem escolher esta opção.

Acesso

  • Private: outros membros da equipe não podem ver a automação. Só você pode gerenciá-la. Admins da equipe podem visualizá-la e desativá-la.
  • Membros podem visualizar: membros da equipe podem visualizar a automação. Você a gerencia quando ela é executada como você. Admins da equipe a gerenciam quando ela é executada como a conta de serviço. Em ambos os casos, Admins podem desativá-la.
  • Membros podem editar: membros da equipe podem visualizar e editar a automação.

O menu também inclui Copiar link.

Alterar Executar como para Conta de serviço muda a identidade usada pela automação. Ela deixa de usar sua autenticação e passa a usar uma conta de serviço dedicada a essa automação. Se a automação usar gatilhos de webhook, gere novamente a chave de API do webhook após a alteração. Se ela usar MCPs ou outras integrações que dependem de credenciais OAuth pessoais, verifique se elas estão configuradas para a conta de serviço da equipe. Somente Admins da equipe podem mudar uma automação para a conta de serviço.

Contas de serviço para automações

Cada automação configurada com Executar como: Conta de serviço recebe sua própria conta de serviço. O Cherri Code cria essa conta na primeira vez que a automação é salva com essa configuração, seja pelo editor de automações, pela API ou pelo provedor do Terraform.

Em equipes Enterprise, essas contas aparecem em Dashboard → Settings → API Keys → Service Accounts com nomes como automation-<id>. Nem o ID no nome nem o ID da conta de serviço (sa_...) correspondem ao ID da automação.

Algumas automações mais antigas compartilham uma única conta de serviço da equipe chamada automations. Elas passam a usar uma conta de serviço própria na próxima vez que forem salvas.

Uma automação executada como conta de serviço para de ser executada se essa conta de serviço for arquivada ou excluída. Só arquive uma conta de serviço automation- quando tiver certeza de que nenhuma automação ainda a utiliza.

Identidade

Quando uma automação interage com serviços externos, ela usa as seguintes identidades:

  • Comentários no GitHub, aprovações de revisão e solicitações de revisores são feitos como cursor.
  • Automações executadas como você abrem pull requests usando sua conta do GitHub.
  • Automações executadas como a conta de serviço abrem pull requests como cursor.
  • Mensagens no Slack são enviadas pelo bot do Cherri Code.

Como escrever prompts

Os prompts definem o que o agente deve fazer. Escreva-os da mesma forma que escreveria instruções para uma execução de agente em nuvem.

Dicas:

  • Especifique o que o agente deve verificar, alterar ou produzir.
  • Faça referência às ações habilitadas — você pode mencionar ferramentas com @ ou citar seus nomes informalmente.
  • Inclua regras de decisão para diferentes casos.
  • Defina um padrão de qualidade para o agente abrir um pull request, comentar ou não fazer nada.
  • Descreva o formato de saída desejado.

Relacionados