Use o Linear com o Ottermind: da lista de issues aos próximos passos

Traga suas issues do Linear para uma conversa sobre o que precisa acontecer a seguir. Com a skill do Linear configurada no Ottermind, seu agente pode ler issues e comentários acessíveis, ajudar a preparar uma revisão e redigir encaminhamentos com o contexto que sua equipe já registrou. Após aprovação, as operações de escrita compatíveis permitem levar esse trabalho de volta ao Linear.

Isso é útil quando os detalhes estão no sistema de acompanhamento, mas você ainda precisa relacioná-los. Qual issue precisa de uma decisão? Dois relatos de clientes descrevem a mesma falha? Que informações deixariam o próximo chamado pronto para um engenheiro?

O passo a passo abaixo usa uma versão fictícia com um problema nos links de convite. Os IDs das issues, os fatos de origem e os exemplos de resultado são ilustrativos; não representam um teste em um workspace conectado.

Conecte a equipe com a qual você quer trabalhar

Use a skill da API do Linear publicada por byungkyu. Essa skill de terceiros se conecta pelo Maton e exige autenticação no Maton e uma conexão OAuth ativa com o Linear. A conexão determina o workspace e os recursos que o agente pode acessar.

Ative a skill e vincule-a ao agente responsável pela tarefa, seguindo o guia de Skills do Ottermind. Se tiver várias conexões com o Linear, especifique o workspace desejado. Comece pedindo ao agente que leia uma issue conhecida e confirme seu ID e título.

A documentação da skill abrange busca, consultas, criação e atualização de issues, além de comentários. Operações de escrita exigem aprovação explícita, e algumas operações podem precisar de escopos adicionais. As instruções de configuração da skill descrevem esses requisitos.

Prepare a revisão com foco nas decisões que a equipe precisa tomar

Suponha que sua equipe esteja preparando uma versão e três issues mencionem links de convite. Uma já tem responsável, outra recebeu um comentário recente pedindo esclarecimentos, e a terceira contém um relato de cliente cujo problema ainda não foi reproduzido.

Abrir o quadro mostra onde as issues estão. Preparar a revisão exige entender quais fatos precisam ser discutidos em conjunto. Peça ao agente que leia as descrições e os comentários relevantes e organize uma pauta curta com links para as evidências.

Prepare uma pauta de revisão da versão de [projeto] no workspace do Linear de [equipe].
Leia as issues ativas e os comentários necessários para entender o estado atual de cada uma.

Para cada item de discussão, inclua ID, título, status e responsável da issue,
o problema ou a pergunta registrada e um link para a issue que fundamenta o item.
Agrupe a pauta em decisões necessárias, informações ausentes e impedimentos confirmados.
Use fatos registrados. Não conclua que uma issue está bloqueada só porque é antiga.
Informe o que você revisou e quais registros não conseguiu recuperar. Não edite issues.

Uma boa pauta tem detalhes suficientes para que qualquer colega entenda por que cada item está ali. No exemplo fictício, a diferença poderia ser esta:

Nesse pedido, o papel do agente é reunir evidências e formular as perguntas. A ausência de um passo de reprodução é uma lacuna concreta. Afirmar que a versão inteira está em risco exigiria mais informações.

O Linear permite filtrar issues por propriedades e relações. Delimitar um projeto, uma equipe ou um conjunto de issues mantém a revisão focada e facilita avaliar sua abrangência.

Leitura do conjunto de issues: Referência de filtros do Linear · Guia de GraphQL do Linear

Quando a pauta estiver pronta, peça uma versão mais enxuta: “Prepare uma abertura de cinco minutos para a revisão. Comece pela decisão sobre os convites e deixe os pedidos de informação para depois.” A tabela completa de evidências continua disponível quando alguém precisar consultar um detalhe.

Compare relatos semelhantes sem apagar suas diferenças

A frase “o link de convite não funciona” pode descrever várias falhas. Uma pessoa pode ter aberto um link expirado. Outra pode estar conectada à conta errada. Uma terceira pode ver um erro depois de aceitar um convite válido.

Antes de criar uma issue, use a busca para encontrar possíveis correspondências. Depois, peça uma comparação das descrições, das condições e do comportamento esperado. Isso transforma uma correspondência ampla de palavras-chave em uma hipótese que pode ser revisada sobre quais relatos devem ser tratados em conjunto.

Busque nas issues de [equipe] relatos de links de convite que expiram ou não abrem.
Leia as descrições e os comentários das issues relevantes.

Compare o comportamento relatado, as condições de reprodução, o contexto afetado
e o resultado esperado. Inclua o ID da issue e o link de origem em cada linha.
Sugira pares que valha a pena revisar como possíveis duplicatas e justifique cada um.
Mantenha separadas as correspondências incertas. Não encerre, mescle ou modifique issues.

Este é um pequeno exemplo da comparação a solicitar. Os IDs e relatos são fictícios:

DEMO-41 e DEMO-63 são candidatas à mesma discussão. Isso não comprova que tenham a mesma causa raiz. DEMO-58 também menciona convites, mas sua condição de reprodução aponta para outra questão.

Uma boa pergunta de continuidade é: “Que evidência nos permitiria saber se DEMO-41 e DEMO-63 devem ser tratadas em uma única issue?” A resposta pode indicar a necessidade de capturas de tela correspondentes, mensagens de erro exatas ou uma comparação dos passos de reprodução. Ela deve partir dos relatos, sem inventar um diagnóstico.

Essa distinção importa na triagem. O objetivo é reduzir investigações duplicadas sem perder informações de que um engenheiro possa precisar depois.

Transforme o comportamento acordado em um chamado que possa ser implementado

Agora suponha que a revisão leve a uma decisão: um convite expirado deve explicar o problema e orientar a pessoa a pedir um novo convite a um administrador do workspace. A decisão não inclui mudanças nas regras de validade dos convites.

Essas anotações bastam para redigir uma issue com escopo delimitado. Continue na mesma conversa para manter disponíveis os relatos relacionados e o motivo da decisão.

Redija uma issue do Linear com base nestas decisões de produto aprovadas: [anotações].
Use [equipe] e [projeto]. Vincule os relatos relacionados que acabamos de revisar.

Inclua um título conciso, comportamento observado, comportamento esperado,
trabalho dentro do escopo, exclusões explicitadas nas anotações e critérios de aceitação.
Não invente uma abordagem de implementação. Deixe responsável e prioridade sem definição,
a menos que constem nas anotações. Mostre o rascunho completo antes de criar a issue.
Depois que eu aprovar a criação, retorne o ID e a URL da issue.

Para a decisão fictícia, o rascunho poderia conter:

• Título: Explicar o próximo passo quando um convite expirar.
• Comportamento observado: O fluxo relatado de link expirado termina sem uma ação útil de recuperação.
• Comportamento esperado: Explicar que o convite expirou e orientar a pessoa a solicitar um novo convite a um administrador.
• Fora do escopo: Mudanças nas regras de validade dos convites.
• Verificação de aceitação: Abrir um convite expirado exibe a explicação e a orientação de recuperação acordadas.

Este é um exemplo de redação, não uma afirmação de que o Ottermind criou ou testou uma issue. A intenção é mostrar como tornar uma decisão executável sem acrescentar requisitos silenciosamente.

Revise o comportamento esperado e os critérios de aceitação em conjunto. Se as anotações não disserem se a orientação de recuperação deve ser um botão ou texto simples, sinalize essa questão como pendente. Uma pergunta precisa agora é mais útil do que um detalhe de design inventado no chamado.

A skill selecionada permite criar issues e adicionar comentários. Depois de aprovar a operação de escrita exata, peça o link da issue resultante. Se a decisão pertencer a uma issue existente, prepare ali um comentário objetivo, em vez de criar outro lugar para acompanhar o mesmo trabalho.

Mantenha o próximo passo ligado ao relato original

Uma boa sessão pode gerar três materiais relacionados: uma pauta de revisão, uma comparação de issues e um rascunho que reflita a decisão da equipe. Cada um deve apontar para os registros que explicam por que o trabalho existe.

Comece com a skill do Linear e um grupo de issues que precise de atenção. A introdução às Skills explica como disponibilizar essa capacidade ao agente. Para entender a abordagem de trabalho mais ampla, o guia de gestão de projetos com IA aborda revisão e passagem de trabalho, enquanto o guia de workspaces para agentes mostra como o contexto sustenta o trabalho entre etapas.