Como atribuir uma issue ao Copilot coding agent
O passo a passo completo de 2026: entregue uma issue do GitHub ao agente de código do Copilot — documentado agora como cloud agent —, veja ele planejar, abrir um draft PR e rodar testes dentro do GitHub Actions e, depois, revise, itere e faça o merge. Cada passo está amarrado ao minuto exato dos vídeos de origem.
TL;DR — atribuir issues ao Copilot em 2026
- Atribuir é um clique: abra a issue, clique em Assignees, escolha Copilot. O agente reage com um emoji de olhos, inicia um ambiente efêmero do GitHub Actions e abre um draft PR que você acompanha pela linha do tempo da issue.
- A documentação do GitHub agora o chama de Copilot cloud agent — o mesmo produto que a interface e os posts do blog continuam chamando de coding agent. Os dois nomes funcionam em buscas, tickets de suporte e neste guia.
- Você precisa de um plano pago do Copilot e acesso de escritura ao repositório. Contas no plano gratuito não veem o Copilot na lista de assignees; no Business e no Enterprise, um admin precisa ativar a política antes.
- A revisão segue humana: o Copilot pede sua revisão ao terminar, comentários @copilot mandam mudanças de volta, e o PR só recebe merge após a aprovação de uma pessoa. A execução da demo deste guia terminou em 8 min 14 s.
Use GitHub Copilot Coding Agent to Solve Open Issues in a GitHub Repository
Canal: :The Code Wolf13:00
How to Get the Most Out of the Copilot Coding Agent
Canal: :GitHub1:56
How the GitHub Copilot coding agent works | GitHub Checkout
Canal: :GitHub6:58
Starting GitHub Copilot sessions
Docs: :docs.github.com
About the Copilot cloud agent
Docs: :docs.github.com
Os frames deste guia vêm das duas gravações de tela limpas creditadas acima; cada still foi conferido em tamanho cheio. A entrevista do GitHub Checkout serve só como fonte de fatos — seus trechos de tela levam a câmera do apresentador sobreposta, então nenhum frame foi tirado dela.
Capturas de tela são usadas para identificação e comentário. “Use GitHub Copilot Coding Agent to Solve Open Issues in a GitHub Repository” © The Code Wolf; “How to Get the Most Out of the Copilot Coding Agent” e “How the GitHub Copilot coding agent works” © GitHub. Todos os nomes de produtos são marcas de seus respectivos donos.
Atribuir, acompanhar, mesclar: o passo a passo em 13 etapas
Antes de atribuir a issue
- 1
Abra a aba Issues do repositório e escolha uma tarefa bem delimitada
As issues normalmente vêm do seu product owner, do seu time ou da comunidade. No repositório da demo há três abertas — um conector Snowflake, colunas ordenáveis e favoritos nomeados. Qualquer uma é uma feature do tamanho de um PR, exatamente o tamanho que o coding agent lida melhor. Você pode atribuir várias issues de uma vez; cada uma ganha sessão e draft PR próprias.
A aba Issues do repositório de demo com três pedidos de features da comunidade em aberto.Ver em 9:31 - 2
Escreva o problema e os critérios de aceitação na issue
O Copilot só vê o título da issue, a descrição e os comentários que existem no momento da atribuição. Uma boa issue descreve o problema, por que ele importa e os critérios de aceitação — o exemplo do GitHub lista critérios em tópicos que deixam o sucesso verificável. O que esquecer pode ser adicionado depois, mas apenas como comentário no pull request que o Copilot abre, porque ele não relê a issue.
Uma issue bem delimitada: descrição, motivação e critérios de aceitação verificáveis.Ver em 0:17 - 3
Confira se o agente está habilitado para a sua conta
Só é possível atribuir issues ao Copilot com um plano pago. Verifique github.com/settings/copilot/features — a página de configurações pessoais lista Coding agent (Preview) sob Copilot na barra lateral, junto aos interruptores Enabled do Copilot na CLI, do Chat no GitHub Mobile e das demais funções de prévia dos editores. No Copilot Business ou Enterprise, um administrador precisa habilitar a política da organização antes de a opção aparecer.
A página de recursos do Copilot em que Coding agent (Preview) mostra o estado habilitado.Ver em 4:00
Atribua a issue ao Copilot
- 4
Abra o menu Assignees e escolha o Copilot
Abra a issue e clique em Assignees na barra lateral direita. O menu lista pessoas e additional options — incluindo o Copilot, legendado “Your AI pair programmer”. Selecione como escolheria um colega; a documentação avisa que atribuir issues ao Copilot está em public preview e pode mudar. Prefere o teclado? gh agent-task create (GitHub CLI 2.80.0 ou mais recente, public preview) inicia o mesmo tipo de sessão direto do terminal.
O menu Assignees com o Copilot — Your AI pair programmer — em destaque.Ver em 4:16 - 5
Confirme a atribuição e defina orientações opcionais
O Copilot agora aparece ao lado dos assignees humanos. O diálogo de atribuição também oferece um campo de prompt opcional para contexto, restrições ou requisitos específicos, menus para trocar o repositório de destino e o branch inicial — você precisa de acesso de escritura ao repositório escolhido e o cloud agent deve estar habilitado lá — além de seletores de custom agent, modelo de IA e raciocínio. Tudo é opcional: atribuído sem extras, o Copilot parte só do texto da issue.
Material oficial do GitHub mostrando o Copilot sendo escolhido no menu Assignees.Ver em 0:04 - 6
Veja a linha do tempo confirmar que o Copilot pegou a tarefa
Em segundos a issue reage: o Copilot adiciona uma reação de olhos e um evento “Copilot has started work” chega à linha do tempo. Nesta gravação dá para ver os eventos de atribuição, os comentários do próprio Copilot e — um minuto depois — “Copilot linked a pull request that will close this issue” apontando para o novo rascunho WIP. Você também recebe e-mails conforme a sessão avança.
Linha do tempo da issue: eventos de atribuição, comentários do Copilot e o pull request WIP linkado.Ver em 5:22
Acompanhe a execução em segundo plano
- 7
Acompanhe a execução no GitHub Actions
O cloud agent trabalha em um ambiente efêmero movido a GitHub Actions. Abra a aba Actions e você encontrará uma execução com o nome da issue — aqui “Fixing issue #5” — com um job copilot cujos passos se chamam Prepare Copilot, Start MCP Servers, Processing Request, Clean Up e Save Data. Pode ser que um revisor precise clicar em “Approve and run workflows” antes de os pushes do Copilot executarem sua CI.
Os passos ao vivo do job copilot dentro da execução do GitHub Actions da issue.Ver em 5:00 - 8
Abra o draft PR que o Copilot abre
O Copilot não fica calado até o fim — ele abre um draft pull request imediatamente e segue atualizando. A linha do tempo da issue linka direto para ele (“a pull request that will close this issue”), e o corpo do PR começa como cópia da issue e vai se preenchendo com o plano do agente e o progresso marcado enquanto trabalha. Acompanhe como o branch de um colega.
O evento de pull request linkada na linha do tempo apontando para o novo draft PR.Ver em 5:31 - 9
Leia as notas de PR do Copilot
Quando a sessão termina, o draft pull request se lê como se um bom colega o tivesse escrito: “Copilot wants to merge 3 commits into main from copilot/fix-5-4”, uma seção What's Added decompondo implementação do núcleo, integração de UI e integração de sistema, mais uma seção Connection String Format. A barra lateral mostra “Copilot is done — completed after 8m 14s”. Esta execução levou uns nove minutos de ponta a ponta.
A descrição escrita pelo próprio draft PR com o tempo de conclusão na barra lateral.Ver em 5:38
Revise, itere, faça o merge
- 10
Inspecione o diff em Files changed
A aba Files changed mostra cada commit do agente: aqui, seis arquivos, incluindo um novo SnowflakeDatabaseService.cs com 119 linhas adicionadas — iniciado por um comentário avisando que foi gerado por IA —, o pacote NuGet adicionado ao csproj e o serviço registrado para injeção de dependência como seus irmãos Oracle, PostgreSQL e SQL Server. Leia exatamente como o PR de um colega.
Files changed no pull request 14: seis arquivos e o novo serviço gerado.Ver em 12:15 - 11
Revise quando o Copilot pedir
Sessões concluídas avisam — um banner mostra “Copilot requested your review on this pull request” com um botão Add your review. Comente qualquer linha ou deixe uma revisão normal; o Copilot acata comentários de revisão e menções @copilot de quem tem acesso de escritura e empurra novos commits para o mesmo PR. Iterações seguintes são mais rápidas porque ele lembra do contexto das sessões anteriores naquele pull request.
O banner de revisão solicitada acima do resumo de mudanças do próprio Copilot.Ver em 9:38 - 12
Faça o merge como qualquer outro pull request
Quando o diff estiver bom, faça o merge normalmente. A caixa de merge até lembra o que fechar o PR vai fazer: “Successfully merging this pull request may close these issues” — linkando o pedido de feature do Snowflake de que o agente partiu. A aprovação humana é o portão; o agente nunca mescla sozinho, e execuções de CI podem precisar do clique em “Approve and run workflows” antes de rodar sobre os commits do Copilot.
A caixa de merge linkando o pull request de volta à issue que o originou.Ver em 12:45 - 13
Conduza execuções futuras com copilot-instructions.md
Para regras permanentes, adicione um arquivo .github/copilot-instructions.md — convenções, passos de build/test/lint, estrutura do repositório. O exemplo do próprio GitHub define Code Standards e uma checklist Required Before Each Commit começando com npm run lint; a demo do Code Wolf pede comentários minuciosos atribuídos à IA e o diff gerado depois segue à risca. Servidores MCP para ferramentas além do GitHub — Notion, Linear, bancos de dados — são configurados na página de settings de Copilot do repositório.
Um arquivo copilot-instructions.md com padrões de código que o agente segue.Ver em 0:47
Pré-requisitos: planos, permissões e o interruptor de ativação
Três coisas condicionam a opção Assignees → Copilot. Primeiro, o plano: pela documentação do GitHub, “o cloud agent do Copilot está disponível para todos os planos pagos” — Pro, Pro+, Business e Enterprise. Contas do plano gratuito não veem o Copilot na lista de assignees de jeito nenhum, o motivo mais comum de acharem que a função não existe.
Segundo, a habilitação. Contas pessoais podem checar a página de recursos das configurações do Copilot (github.com/settings/copilot/features), onde Coding agent (Preview) aparece sob Copilot na barra lateral. No Business e no Enterprise, “um administrador precisa habilitar a política correspondente” antes de alguém da org ter a opção — se ela falta num repositório da organização, é papo de admin, não bug.
- 1Um plano pago do Copilot (Pro, Pro+, Business ou Enterprise) — contas gratuitas não têm a opção de atribuir ao Copilot
- 2Acesso de escritura ao repositório de destino — você só pode escolher repositórios onde pode escrever e onde o cloud agent está habilitado
- 3O agente habilitado: github.com/settings/copilot/features para contas pessoais, uma política no nível da org para Business e Enterprise
- 4GitHub Actions disponível no repositório — o agente roda num ambiente efêmero movido a Actions, e Enterprise Managed Users não conseguem usá-lo em repositórios pessoais
Terceiro, conheça o runtime: atribuições estão em public preview, cada sessão executa num ambiente efêmero do GitHub Actions com teto duro de 59 minutos, e o acesso à internet pela sandbox é bloqueado por padrão. Sessões que travam dão timeout depois da hora — a solução é desatribuir e atribuir a issue de novo.
Logs de sessão: como vigiar um agente trabalhando em segundo plano
Toda sessão deixa rastro de log em três lugares. A linha do tempo da issue registra a atribuição, os comentários do Copilot e o draft PR linkado. A aba Actions mostra os passos internos do job copilot — preparar o ambiente, iniciar os servidores MCP, processar a requisição, limpar. E o próprio PR vira a página de status do agente: o corpo começa como cópia da issue e se preenche com um plano que vai sendo marcado conforme o trabalho chega.
Você não precisa ficar pollando. O Copilot manda e-mail quando o draft PR está no ar e de novo quando pede sua revisão, e a reação de olhos mais o evento “Copilot has started work” confirmam em segundos que a sessão começou de verdade. A visão de logs de sessão da documentação vai além: dá para acompanhar o trabalho ao vivo e até abrir o pull request com um clique a partir dos logs.
Na demo, uma feature moderada — um conector Snowflake completo em seis arquivos — ficou pronta após 8 min 14 s de tempo de agente, com o link do PR aparecendo na issue uns nove minutos depois da atribuição. Edições simples costumam voltar em poucos minutos; o que ainda rodar perto da hora, trate como travado e reatribua.
Iteração e proteções: comentários, instruções e MCP
O ciclo de atribuir e revisar parte do princípio de que o primeiro rascunho do Copilot não será perfeito. Cinco alavancas moldam o resultado sem você jamais abrir um IDE:
- 1Comentários @copilot — mencione o @copilot num comentário do PR (requer acesso de escritura, só PRs abertos) e ele inicia uma sessão de acompanhamento no mesmo PR; comentários de revisão individuais podem ser delegados com Fix with Copilot ou agrupados
- 2copilot-instructions.md — um arquivo .github/copilot-instructions.md leva suas convenções, comandos de build/test/lint e regras de commit para cada sessão; o exemplo do próprio GitHub traz uma checklist Required Before Each Commit
- 3Servidores MCP — configurados nas settings de Copilot do repositório, entregam ao agente ferramentas além do GitHub; a demo Checkout do GitHub mostra ele lendo uma especificação de produto no Notion via MCP
- 4O prompt opcional na hora de atribuir — contexto, restrições e requisitos específicos que viajam junto com a issue
- 5Seletores de custom agent, modelo e raciocínio — escolha uma configuração diferente por sessão no diálogo de atribuição ou mude o padrão nas settings
As proteções ficam do seu lado: as mudanças ficam confinadas a um repositório por sessão, o agente não pode aprovar nem mesclar o próprio trabalho, e os workflows que ele dispara esperam “Approve and run workflows”, salvo se você os colocar na allowlist. A revisão do PR que você faz é a rede de segurança — o botão de merge nunca é do agente.