Copilot no Slack e Teams: como usar contexto de conversas sem perder a origem

O GitHub Copilot no Slack e no Microsoft Teams pode transformar uma conversa em contexto para investigar um repositório, planejar mudanças, criar issues e abrir pull requests. A atualização anunciada em 25 de setembro de 2026 ampliou os tipos de contexto aceitos e reforçou a rastreabilidade entre a conversa e o trabalho criado no GitHub. Para usar esse fluxo sem perder a origem, o ponto principal é entender que a thread compartilhada pode virar o contexto de decisão do agente e que a integração mantém links entre o resultado e a discussão que o originou.

Isso não significa que qualquer mensagem concede poder para alterar um repositório. O contexto da conversa, a identidade usada pela integração e a autorização para executar ações são camadas diferentes. Em uma conversa compartilhada, participantes podem acrescentar informações, mas apenas usuários com acesso de escrita ao repositório podem acionar mudanças. Em mensagens diretas, o agente usa as permissões da conta GitHub vinculada.

O que mudou nas integrações em 25 de setembro de 2026

Segundo o changelog oficial do GitHub, o Copilot passou a aproveitar mais material que já existe nas conversas. No Slack, a atualização acrescentou suporte a arquivos compatíveis, anexos e links de mensagens como contexto. No Teams, o agente passou a trabalhar com imagens inline, contexto de mensagens encaminhadas e histórico de canais e threads.

O mesmo anúncio também reforçou a ligação entre discussão e execução. Antes de criar uma nova issue, o Copilot pode verificar se existem issues semelhantes. Quando cria trabalho no GitHub, a integração fornece links diretos para o resultado e mantém um link de retorno para a conversa de origem. O objetivo é permitir que alguém que chegue depois ao issue ou pull request consiga recuperar a discussão que levou àquela ação, em vez de receber apenas o artefato final sem contexto.

Há ainda controles de fluxo. É possível trocar o modelo para a próxima mensagem e manter essa escolha durante a conversa. No Slack, também é possível definir repositórios e responsáveis padrão. O changelog registra ainda melhorias para tarefas longas, reconexão após inatividade, respostas interrompidas, troca segura de repositório e retenção mais confiável de histórico em threads do Teams.

Como usar o contexto da conversa sem perder a origem

1. Escolha a conversa certa. Se a decisão está em uma thread específica, invoque o GitHub nessa thread. A documentação de Slack e Teams informa que o agente pode usar a conversa inteira como contexto. Por isso, misturar assuntos diferentes na mesma thread também mistura contexto.
2. Mencione @GitHub com uma tarefa explícita. Diga o que precisa ser investigado, planejado ou alterado e, quando possível, informe o repositório e a branch. Um pedido objetivo reduz a chance de o agente inferir o destino errado a partir de uma conversa extensa.
3. Confirme o repositório de trabalho. Slack e Teams podem usar um repositório padrão do canal quando nenhum repositório é informado. Se a tarefa pertence a outro projeto, declare o repositório no pedido antes de iniciar o trabalho.
4. Revise o escopo do contexto. A documentação alerta que a thread inteira pode ser capturada e armazenada nos artefatos gerados pelo agente. Se parte da conversa não deve entrar no trabalho, comece uma nova thread ou use uma mensagem direta para limitar o contexto.
5. Acompanhe os links de ida e volta. O resultado deve apontar para os artefatos criados no GitHub, enquanto a integração mantém a ligação com a conversa que iniciou a tarefa. Essa relação é o mecanismo de rastreabilidade mais importante do fluxo.

De onde vem o contexto em Slack e Teams

A diferença prática não está apenas na interface. No Slack, a documentação descreve um canal dedicado chamado Slack Code para uma tarefa de agente, que concentra a continuidade da sessão. No Teams, a iteração ocorre na própria thread e o agente incorpora mensagens posteriores para refinar o trabalho. Em ambos os casos, a conversa compartilhada é uma fonte de contexto, não um substituto para a revisão do artefato criado.

O que significa preservar a origem na prática

Preservar a origem tem duas dimensões. A primeira é técnica: o GitHub informa que os artefatos criados podem manter ligação com a conversa que forneceu o contexto. A segunda é operacional: a equipe precisa usar threads, repositórios e tarefas de forma consistente para que esse link continue útil.

Se uma thread contém decisões sobre três serviços diferentes, um link de retorno para essa conversa ainda existe, mas a origem fica menos clara para quem revisar o resultado. Por isso, uma boa prática é manter uma thread por problema ou decisão relevante, especificar o repositório e a branch quando necessário e evitar reaproveitar uma sessão antiga para um trabalho sem relação com o original.

Também vale revisar os links do artefato depois que o agente terminar. A rastreabilidade ajuda a descobrir por que uma issue ou pull request existe, mas não substitui a checagem humana do conteúdo, especialmente porque as páginas oficiais lembram que o Copilot usa IA e pode cometer erros.

Permissões: contexto de conversa não é autorização de escrita

As páginas oficiais de Slack e Teams separam claramente colaboração de autorização. Em contexto compartilhado, o Copilot cria artefatos usando a identidade do aplicativo. Em mensagem direta, ele usa as permissões da conta GitHub pessoal vinculada para executar ações.

• Acesso de escrita: somente usuários com permissão de escrita no repositório podem acionar o agente para fazer mudanças.
• Contribuição de contexto: outros participantes da conversa podem fornecer informações que serão consideradas pelo agente, mesmo quando não podem iniciar uma alteração.
• Convidados e colaboradores externos: a documentação informa que esses perfis não podem iniciar nem conduzir uma sessão do Copilot nessas integrações.
• Regras de repositório: pull requests criados em contexto compartilhado usam a identidade do aplicativo. Quando o repositório já exige aprovação, regras podem exigir uma aprovação adicional porque o autor não é uma pessoa.

Há também permissões da própria integração. As páginas de permissões do GitHub no Slack e de permissões do GitHub no Teams listam acessos de leitura necessários para mostrar código e prévias, além de permissões de escrita usadas para criar issues, pull requests e iniciar sessões do agente. Em ambientes corporativos, administradores ainda podem restringir quais repositórios o aplicativo pode acessar.

Como limitar contexto excessivo ou ambíguo

A recomendação mais importante é tratar a thread como parte da entrada do agente. Antes de mencionar @GitHub, confira se aquela conversa contém apenas informações adequadas à tarefa. O guia geral de integrações do Copilot afirma que o agente captura a thread ou item de trabalho para entender o contexto e que esse contexto é armazenado nos artefatos criados.

• Abra uma nova thread quando o assunto mudou ou quando a conversa acumulou hipóteses antigas.
• Use mensagem direta se quiser reduzir o escopo de contexto em vez de aproveitar uma discussão compartilhada inteira.
• Declare repositório e branch quando houver risco de ambiguidade.
• Inclua critérios objetivos, como comportamento esperado, arquivo afetado ou condição de aceite, sem depender apenas de referências vagas a mensagens anteriores.
• Depois de trocar de repositório, confira o repositório exibido pela sessão antes de continuar.
• Para uma tarefa nova, evite reutilizar uma sessão antiga apenas porque ela já está aberta.

Disponibilidade e limites que ainda importam

As integrações continuam marcadas como preview público nas páginas operacionais consultadas. O changelog de 25 de setembro descreve o pacote de melhorias como disponível em preview público para organizações em GitHub Copilot Business e Enterprise e avisa que algumas capacidades têm implantação gradual. Já as páginas atuais de Slack e Teams indicam disponibilidade das integrações para planos pagos do Copilot. Como as formulações não são idênticas, a disponibilidade real de um recurso específico deve ser confirmada no próprio workspace e nas políticas da organização.

O uso do agente também depende de sandboxes de nuvem e, em organizações ou empresas, de políticas administrativas que podem precisar ser habilitadas. O fato de a integração estar instalada não garante acesso a todos os repositórios. O usuário ainda precisa ter autorização adequada e o aplicativo precisa ter acesso ao repositório escolhido.

Por fim, mais contexto não significa contexto ilimitado nem resposta infalível. Arquivos ou imagens precisam estar entre os formatos e caminhos aceitos pela integração, recursos podem chegar gradualmente e tarefas interrompidas ou sessões antigas ainda exigem atenção. A atualização melhora a recuperação e o status dessas situações, mas a equipe continua responsável por verificar o repositório, os artefatos gerados e o conteúdo final.

Checklist rápido para usar o recurso com rastreabilidade

• Confirme que a integração GitHub está instalada e que sua conta está vinculada.
• Verifique se o agente e os sandboxes de nuvem estão habilitados para sua organização.
• Escolha uma thread que represente um único problema ou decisão.
• Antes de enviar, confira se a thread não contém contexto que não deve ser armazenado no artefato.
• Mencione @GitHub e informe claramente tarefa, repositório e branch quando necessário.
• Confira se você tem acesso de escrita ao repositório para acionar mudanças.
• Use arquivos, anexos, links de mensagens ou imagens apenas quando forem relevantes à tarefa.
• Depois da execução, abra os links do issue ou pull request e verifique a ligação com a conversa de origem.
• Revise o resultado humano antes de mesclar ou tratar a saída como decisão concluída.

Fontes e referências

• GitHub Changelog: Updates to GitHub Copilot for Slack and Microsoft Teams
• GitHub Docs: About Copilot integrations
• GitHub Docs: Integrating Copilot cloud agent with Slack
• GitHub Docs: Integrating Copilot cloud agent with Teams
• GitHub Docs: Permissions for GitHub in Slack
• GitHub Docs: Permissions for GitHub in Teams