Como automatizar metadados de issues com o GitHub issue intent

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How to automate issue metadata with GitHub issue intents · Canal: GitHub · 03:20 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows

Resumo

O vídeo apresenta o issue intent, recurso que ajuda a automatizar a classificação e a priorização de issues, mantendo opções de controle para quem mantém o repo. As sugestões incluem nível de confiança e justificativa, e podem ser aceitas ou recusadas individualmente ou em conjunto. O nível de automação pode ser ajustado para aplicar automaticamente mudanças rotineiras e claras. O exemplo mostra como configurar um workflow com issue intent e verificar as ações recomendadas e aplicadas.

Pontos-chave

O filtro de sugestões permite encontrar issues com sugestões pendentes de issue intent.
Cada sugestão apresenta um nível de confiança e uma justificativa.
As sugestões podem ser aceitas ou recusadas uma a uma, ou aceitas em conjunto.
Os níveis de automação permitem ajustar o grau de controle sobre as mudanças aplicadas.
No nível equilibrado, mudanças rotineiras e claras são aplicadas automaticamente.
O workflow de exemplo classifica a issue, sugere uma prioridade e inclui uma justificativa curta.
Definir issue intent como true exige que o agent forneça justificativa e nível de confiança.
As safe outputs permitem conferir quais ações foram recomendadas e aplicadas.
Também é possível usar Copilot Cloud Agent Automations ou criar agents personalizados com recursos do GitHub MCP, REST ou GraphQL.

Capítulos

Início	Capítulo	Resumo
00:00	Sugestões de metadados para issues	O vídeo apresenta o issue intent e mostra como revisar sugestões com confiança e justificativa.
00:34	Níveis de automação e triagem	A demonstração ajusta o nível de automação e verifica as alterações de rótulo e prioridade aplicadas à issue.
01:39	Configuração do workflow	O exemplo explica os gatilhos, as permissões, as ferramentas e o uso de issue intent na configuração.
02:46	Resultados e alternativas de implementação	O vídeo verifica as ações e justificativas geradas e cita outras opções para criar automações.

Citações

Como encontramos o equilíbrio certo entre controle e autonomia? — 00:00

Você pode começar neste nível ou no nível cauteloso e mudar conforme sua confiança nas automações aumenta. — 00:34

Para essas ações, definimos issue intent como true. — 02:16

Este é apenas um exemplo das muitas tarefas que o issue intent pode ajudar a automatizar. — 03:20

Conceitos e entidades

issue intent (conceito): Recurso que automatiza sugestões de metadados para issues e inclui justificativa e nível de confiança.
GitHub (empresa): Empresa e plataforma na qual são demonstradas as automações de issues.
GitHub Actions (ferramenta): Ferramenta que, no exemplo, aplica alterações aos metadados da issue.
Agentic workflows (ferramenta): Workflows descritos em linguagem natural em Markdown, usados no exemplo para automatizar tarefas de triagem.
Copilot Cloud Agent Automations (ferramenta): Alternativa citada para criar automações com agents na plataforma GitHub.
GitHub MCP (ferramenta): Recurso citado como uma das formas de criar agents personalizados compatíveis com o GitHub.
safe outputs (conceito): Ações recomendadas que um workflow pode concluir, apresentadas no vídeo como parte da configuração e dos resultados da automação.
REST (conceito): Interface citada como recurso compatível para criar agents personalizados.
GraphQL (conceito): Interface citada como recurso compatível para criar agents personalizados.

Tradução completa (pt-BR)

00:00 Como mantenedor, você sabe que manter os metadados das issues recebidas atualizados pode ser um trabalho tedioso. É claro que podemos usar agents para nos ajudar a automatizar isso, mas como mantemos o controle e, ao mesmo tempo, damos autonomia? Como encontramos o equilíbrio certo? Para resolver exatamente esse problema, lançamos issue intent. Vou mostrar como funciona. Na aba de issues, podemos usar o filtro “has suggestions” para ver as issues que têm sugestões pendentes de issue intent. Vou abrir esta issue aqui e podemos ver que, para cada sugestão, temos um nível de confiança e uma justificativa. Também podemos aceitar ou recusar cada

00:34 sugestão individualmente, ou aceitar todas aqui em cima. Nas configurações do nosso repositório, em Planning, o nível atual de automação está definido como “full control”, o que significa que nenhuma sugestão será aplicada automaticamente. Você pode começar nesse nível ou no nível “cautious” e depois mudar à medida que sua confiança nas automações aumentar. Vou mudar para “balanced”, que aplica automaticamente mudanças rotineiras e claras. Vamos clicar em salvar. Agora, vamos voltar à mesma issue. Vou fechá-la e reabri-la para podermos acionar a automação novamente. Ótimo, o

01:07 workflow de triagem de novas issues foi concluído. Vamos voltar à issue e ver o que mudou. A issue está aberta. Vou rolar para baixo e podemos ver que o GitHub Actions adicionou o rótulo “bug”. Se passarmos o cursor sobre o ícone de informações, aparece: “O relatório descreve um comportamento existente inconsistente entre páginas, não uma solicitação de um novo recurso”, que é a justificativa para a aplicação do rótulo. E aqui temos a prioridade baixa definida. E aqui diz: “O impacto se limita a uma inconsistência irritante na experiência do usuário, sem nenhum bloqueio funcional declarado”. Assim, podemos ver que nossa automação de issue intent funcionou. Mas como

01:39 configuramos isso, você pode perguntar? Bem, vamos dar uma olhada agora. Para o nosso exemplo, usamos um workflow do GitHub Agentech que, como você pode ver, nos permite criar automações usando linguagem natural em Markdown. O nosso tem apenas três etapas: classificar a issue, sugerir uma prioridade e incluir uma justificativa curta. Na parte superior, temos o front matter do workflow, onde definimos os gatilhos. No nosso caso, quando uma issue é aberta ou reaberta; as permissões que nosso workflow tem; as ferramentas; e as saídas seguras, que são

02:16 as ações recomendadas com as quais um workflow pode concluir. E o segredo está aqui. Para as ações “set issue type” e “set issue field”, estamos definindo issue intent como true, o que significa que precisamos garantir que o agent forneça uma justificativa e um nível de confiança para que essas ações sejam executadas. Agora podemos [limpa a garganta] dar uma olhada na última execução desse workflow na nossa aba Actions. Vou rolar para baixo e expandir as saídas seguras

02:46 na seção de resumo do agent, e podemos ver que, de fato, tanto “set issue type” quanto “set issue field” foram recomendadas para o workflow concluir. Se eu rolar para baixo e carregar o resumo das saídas seguras, podemos ver que “set issue type” foi concluída com sucesso, assim como “set issue field”, e que ambas foram aplicadas à issue que reabri, a 897. Cliquei no job do agent e expandi apenas a saída do agent. É exatamente aqui que podemos ver o que definir issue intent como true oferece. Temos o nível de confiança e a justificativa, e os

03:20 temos para as duas saídas seguras: “set issue type” e “set issue field”. Na nossa demonstração, usamos os agent workflows, mas você pode aproveitar as automações do Copilot Cloud Agent ou criar seus próprios agents personalizados usando os recursos compatíveis do GitHub MCP REST ou GraphQL. Este é apenas um exemplo das muitas tarefas que issue intent pode ajudar você a automatizar. Vou incluir links para a documentação com todas as informações de que você vai precisar. E, por favor, conte para a gente qualquer feedback que tiver.

Transcrição original

[00:00] As a maintainer, you know that keeping incoming issues up to date when it comes to metadata can be tedious work. We can of course use agents to help us automate this, but how do we manage control with agency? How do we find that right balance? To answer this exact pain point, we shipped issue intent. Let me show you how it works. In the issues tab, we can use the has suggestions filter in order to view issues that have pending issue intent suggestions. I’ll open this issue up here and we can see for the suggestions, we have a confidence level and a reasoning. And we can also accept or decline each

[00:34] suggestion individually, or we can accept all up here. In our repository settings under planning, the current automation level is set to full control, meaning no suggestions will be auto applied. And you can begin at this level or at the cautious level and then change as your trust in the automations grow. I’m going to switch to balanced, which applies routine clear-cut changes automatically. Let’s hit save. And now let’s return to that same issue. I’ll close it and reopen it so we can trigger the automation again. Great, the

[01:07] workflow for our triage new issues has completed. Let’s revisit the issue and see what has changed. I’ve got the issue open. I’m going to scroll down and we can see that GitHub Actions added the bug label. We hover over the information icon, it says the report describes inconsistent existing behavior across pages, not a new capability request, which is the reasoning as to why that was applied. And then we have the low priority set here. And here it says the impact is limited to annoying UX inconsistency with no stated functional blocker. So we can see that our issue intent automation has worked. But how

[01:39] did we set this up, you may ask? Well, let’s take a look at that right now. For our example, we used a GitHub Agentech workflow, which as you can see, allow us to create automations using natural language in markdown. And ours is just three steps to classify the issue, suggest a priority, and include a short rationale. Up top, we have the workflows front matter, and here is where we define the triggers. So, in our case, when an issue is opened or reopened, permissions that our workflow has, the tools, and the safe outputs, which are

[02:16] the recommended actions a workflow can conclude with. And the secret sauce is in here. So, for both the set issue type and set issue field actions, we are setting issue intent to true, which means that we need to make sure the agent provides a rationale and confidence level for these actions to be done. We can now take [clears throat] a look at the last run of that workflow in our actions tab. I will scroll down, and I’m going to expand the safe outputs

[02:46] under the agent summary, and we can see indeed that both set issue type and set issue field were recommended for the workflow to conclude with. If I scroll down and load the summary of safe outputs, we can see that both the set issue type was success and set issue field, and those were applied to that issue that I reopened 897. I’ve clicked on the agent job, and I’ve expanded in just agent output, and here is exactly where we can see what issue intent set to true provides. We have that confidence and rationale, and we

[03:20] have it for both of the safe outputs. So, set issue type and set issue field. For our demo, we use the agent workflows, but you can leverage Copilot Cloud Agent Automations or build your own custom agents using supported GitHub MCP REST or GraphQL capabilities. This is just one example of the many tasks that issue intent can help you automate. I’ll make sure to link docs with all the information that you will need, and please let us know any feedback that you have.