Transforme uma mensagem do Slack em uma issue do GitHub, e em uma correção
Descreva um bug no Slack com suas palavras. Zero escreve a issue do GitHub e a atribui, e quando a causa está em um único componente abre um pull request com a correção e um teste de regressão para você revisar.
O que Zero entrega: da mensagem no Slack a uma correção em revisão
Uma execução real que você pode abrir e ler. Zero transformou uma semana de relatos de bug no Slack em issues do GitHub e, nos casos em que conseguiu cravar a causa, em pull requests com teste de regressão. O relatório mostra o diff e diz por que corrigiu três e apenas abriu as outras quatro. Dados de exemplo em um formato de saída real.
Resumo do agente. Zero leu 24 mensagens em #bugs, #support-escalation, #design-review e #product. Nove descreviam um defeito, duas já tinham issue aberta e sete viraram novas issues do GitHub. Três dessas sete também ganharam um pull request com a correção e um teste de regressão, vinculado à issue e com CI verde. As outras quatro ficaram só como issue de propósito: tratamento de datas compartilhado, um token de design, uma decisão de produto e uma sem passos para reproduzir. Mensagens analisadas: 24, 9 descreviam um defeito. Issues abertas: 7, todas atribuídas pelos nomes exibidos no Slack. Correções em pull request: 3, com teste de regressão, 0 mescladas sem revisão.
Abrir o relatório completo de issues e correçõesO que significa criar uma issue do GitHub a partir do Slack?
Criar uma issue do GitHub a partir do Slack significa transformar um bug que alguém descreveu em uma conversa em uma issue bem estruturada no seu repositório, sem que ninguém precise sair da thread para digitar tudo de novo. A parte difícil nunca foi a chamada de API: é escrever um título claro, separar os passos para reproduzir do comportamento esperado, escolher rótulos, definir uma prioridade e achar a pessoa certa. Zero faz esse trabalho. Ele lê a mensagem do Slack e as respostas ao redor, escreve o corpo da issue, aplica rótulos e uma prioridade que consegue justificar, resolve o responsável cruzando o nome exibido no Slack com um usuário do GitHub e publica o link da issue na mesma thread, para quem relatou conferir de imediato.
Por que relatos de bug morrem nas threads do Slack
Alguém vê um bug durante uma demo, ou um cliente escreve num sábado. O caminho de sempre é longo: abrir o GitHub, achar o repositório, escrever uma issue formatada, atribuir a alguém e então esperar essa pessoa pegar a tarefa, ler o código e escrever a correção. Uma mudança de dez minutos vira um vai e vem de dias entre três pessoas, e metade dos relatos nunca sai da thread. Em vez disso, você descreve no Slack. Zero abre a issue com passos para reproduzir, rótulos e responsável, e onde a causa está contida ele segue e abre um pull request com a correção e um teste. Você revisa e publica.
Como Zero cria uma issue do GitHub a partir do Slack
Passo 1: conecte suas ferramentas
Passo 2: peça ao Zero
Passo 3: leve mais longe
As integrações de Slack e GitHub por trás do fluxo
Esta é uma integração de Slack com GitHub com um agente no meio: Zero lê a conversa no Slack e escreve o registro no GitHub. Cada conector é concedido separadamente e limitado ao que o fluxo realmente usa, então ler um canal nunca implica acesso de escrita aos seus repositórios.
Integração com Slack: a conversa que Zero lê
ObrigatórioZero lê a mensagem que você indica e as respostas ao redor, de modo que um contexto que chegou três mensagens depois também entra na issue. Ele leva junto as capturas de tela anexadas, lê o nome exibido de quem relatou para resolver o responsável e guarda o permalink da mensagem, assim toda issue aponta de volta para onde o relato começou. Escreve uma coisa só: uma resposta na mesma thread com o número e o link da issue. Zero não publica em outros canais, não envia mensagens diretas nem edita mensagens de ninguém.
Integração com GitHub: a issue que Zero abre
ObrigatórioZero cria a issue no repositório que você indicar, com um título escrito a partir do relato e não uma cópia da mensagem crua, com descrição, passos para reproduzir, comportamento esperado e a área afetada quando a thread menciona uma. Ele aplica os rótulos que você define ou os infere do texto, define uma prioridade que explica e atribui o responsável. Antes de abrir, procura nas issues abertas o mesmo sintoma e comenta na existente quando encontra correspondência. Quando também consegue corrigir o bug, envia uma branch e abre um pull request que fecha a issue e pede revisão. O acesso de escrita é limitado aos repositórios que você conceder, e essa é toda a superfície: issues, comentários e pull requests abertos para revisão. Zero não faz merge, não faz force push e não mexe nas configurações do repositório.
Zero, o app do GitHub para Slack e um construtor de automações
Levar um bug de uma mensagem do Slack até o GitHub tem três partes: capturar o relato, escrever uma issue utilizável e encaminhá-la a um responsável. As opções existentes resolvem uma cada.
O app do GitHub para Slack
Digitar /github abre uma caixa em que você mesmo preenche título, corpo, rótulos e responsável. Poupa a ida ao navegador, mas quem escreve a issue continua sendo você, e um formulário no meio da conversa é justamente o atrito que faz as pessoas dizerem “abro depois”.
Um construtor de automações
Uma ferramenta no-code consegue copiar uma mensagem do Slack para uma issue nova a partir de um gatilho. O que ela copia é a mensagem crua, então a issue herda o que quem relatou digitou na hora, e as regras de rótulos, prioridade, atribuição e duplicatas são suas para definir e manter, canal a canal.
O fluxo do Slack para o GitHub do Zero
Zero lê a thread e escreve a issue: um título de verdade, passos para reproduzir separados do comportamento esperado, rótulos e uma prioridade que ele justifica, e um responsável obtido do nome exibido de quem relatou. Quando a causa está contida em um único componente, ele segue adiante e abre um pull request com a correção e um teste de regressão, vinculado à issue e aguardando a sua revisão. Ele confere as issues abertas antes e comenta em uma duplicata em vez de criá-la, e responde na thread com o link.
Dicas para melhores resultados
Perguntas frequentes
Como criar uma issue do GitHub a partir de uma mensagem do Slack?
Conecte Slack e GitHub ao Zero, descreva o bug no canal e mencione o Zero. Ele lê a mensagem e as respostas próximas, escreve uma issue com título, passos para reproduzir, comportamento esperado, rótulos e prioridade, cria no repositório que você indicou, atribui um responsável e responde na thread com o número e o link. Você não preenche formulário nenhum.
Qual a diferença em relação ao app do GitHub para Slack?
O app do GitHub te dá uma caixa para preencher: título, corpo, rótulos e responsável são escritos por você. Zero escreve tudo isso a partir da conversa, verifica se já existe uma issue com o mesmo sintoma antes de abrir, e pode percorrer um canal inteiro de forma agendada em vez de uma mensagem por vez.
Zero só abre a issue ou consegue corrigir o bug?
Os dois, e ele diz qual fez e por quê. A issue Zero sempre abre. Quando a thread ou o código apontam para um único componente, o comportamento esperado é inequívoco e dá para escrever antes um teste que falha, ele também abre um pull request com a correção e esse teste, vincula à issue e pede revisão. Utilitários compartilhados, tokens de design e qualquer coisa que precise de decisão de produto são abertos como issue, não alterados. Zero nunca faz merge: toda correção chega como um pull request que você revisa.
Zero consegue atribuir a issue à pessoa certa automaticamente?
Sim. Zero cruza o nome que você mencionar, ou o nome exibido no Slack de quem relatou, com os usuários do GitHub no repositório e atribui a issue. Nomear o responsável na mensagem é o caminho mais confiável; quando ninguém é citado, Zero recorre a quem responde pela área que a thread aponta e registra na issue como decidiu.
Como Zero evita issues duplicadas no GitHub?
Antes de criar qualquer coisa, Zero procura nas issues abertas o mesmo sintoma, área afetada e forma de descrever. Quando encontra correspondência, adiciona a nova thread do Slack como comentário naquela issue, com autor e horário, e responde no Slack com o link da issue existente em vez de abrir uma segunda.
O que acontece quando um relato não tem passos para reproduzir?
Zero abre a issue mesmo assim, para o relato não se perder, marca que faltam passos para reproduzir e responde na thread do Slack pedindo por eles. A resposta cai então na thread que já está vinculada a partir da issue.
Zero pode abrir bugs de um canal inteiro de forma agendada?
Sim. Aponte o Zero para um ou mais canais e dê uma agenda, por exemplo toda sexta às 16h. Ele lê as mensagens da semana, abre uma issue para cada uma que descreve um defeito, comenta as duplicatas, ignora pedidos de funcionalidade e perguntas, e relata o que fez.
Funciona com Linear ou Jira em vez do GitHub?
O mesmo formato de fluxo vale para qualquer rastreador ao qual o Zero esteja conectado; esta página cobre o caminho do GitHub, que usa o conector do GitHub. O Linear é conectado do mesmo jeito, e você indica o rastreador na instrução.
Abra seu próximo bug sem sair do Slack
Conecte Slack e GitHub, descreva o bug como você contaria para um colega, e deixe o Zero escrever a issue e atribuí-la. Quando a causa está contida, o pull request também já fica esperando por você.