# Feche um bug direto do ticket

> A squad de bug a partir do ticket é um playbook do Tallos baseado no template Personalizado com um link de tarefa do GitHub, GitLab, Linear ou Jira. Um agente líder lê o ticket, um membro reproduz o bug com um teste falhando, outro corrige a causa raiz, um terceiro revisa, e a squad para para você aceitar ou descartar.

- Canonical: https://runtallos.com/pt/squads/bug-a-partir-do-ticket
- English: https://runtallos.com/squads/bug-from-ticket.md
- Atualizado em: 2026-09-29
- Section: Squads

## Em resumo

- Template: Personalizado + link da tarefa
- Links do GitHub, GitLab, Linear ou Jira
- Reproduzir → corrigir → revisar, nessa ordem
- Limites sugeridos: 4 rodadas · 3 membros ao mesmo tempo
- Termina com correção e teste de regressão

## Quando usar a squad de bug a partir do ticket?

Use para bugs que já estão descritos num tracker e dá para reproduzir no código. A squad impõe a disciplina que a maioria das correções rápidas pula: provar o bug com um teste falhando, corrigir a causa e deixar outro ler a correção.

- **Encaixa bem:** bug de backend com passos claros, como duplicidade, total errado ou corrida em retry.
- **Encaixa bem:** regressão com referência conhecida do tipo "funcionava na versão X".
- **Não encaixa:** relato vago ("o checkout está lento"). Transforme numa meta mensurável e use a [melhor de três](https://runtallos.com/pt/squads/melhor-de-tres).

## Como montar a squad?

Abra **Squads → Nova squad**, escolha **Personalizado** e cole a URL do ticket em **Link da tarefa (opcional)**. O campo aceita links do GitHub, GitLab, Linear e Jira; qualquer outro mostra "Use um link do GitHub, GitLab, Linear ou Jira." O Personalizado começa com um membro vazio, então adicione três e escreva a função de cada um.

| Papel | Agente (exemplo) | O que faz |
| --- | --- | --- |
| Líder | Claude Code | Lê o ticket, conduz reproduzir → corrigir → revisar em ordem e escreve o relatório. Não escreve código. |
| Quem reproduz | Gemini CLI | Reproduz o bug com um teste falhando. |
| Quem corrige | Codex | Corrige a causa raiz até o teste passar. |
| Revisor | OpenCode | Revisa a correção e o teste. |

_Os agentes são exemplos. Escolha qualquer agente conectado, modelo e esforço para cada papel._

> **O que o link da tarefa faz** — O Tallos passa o link e o provedor para o líder como tarefa de origem, no primeiro prompt dele. O líder lê o ticket com as ferramentas que o próprio agente tem. Se o seu tracker é privado ou o agente não consegue abrir, cole os fatos principais no objetivo também.

## Qual objetivo colar?

Reescreva o bug em poucas linhas, mesmo com o link, e deixe clara a ordem do trabalho. Depois escreva as **Instruções do líder**: o Personalizado não traz nenhuma por padrão.

```text
Corrigir ENG-482: retries do webhook criam pedidos duplicados.

O que sabemos
- O provedor de pagamento reenvia order.paid quando nosso endpoint demora.
- Cada reenvio cria um pedido novo com o mesmo id de evento.

Pronto quando
- Um teste de regressão envia o mesmo evento duas vezes e gera um pedido só.
- Os testes de pedido existentes passam. Sem sleeps nem gambiarras de retry.
- O relatório diz a causa raiz em uma frase.
```

```text
Instruções do líder
Reproduza primeiro. Só inicie quem corrige depois que o teste de quem
reproduz falhar pelo motivo descrito no ticket. Depois mande a correção
e o teste para o revisor. Se o revisor pedir mudanças, devolva para quem corrige.
```

## Quais limites definir?

Coloque **4 rodadas** e **3 membros ao mesmo tempo**. O trabalho é quase todo sequencial, então rodadas pesam mais que vagas em paralelo: uma para reproduzir e corrigir, uma ou duas para o feedback da revisão, uma de folga.

| Configuração | Recomendado | Por quê |
| --- | --- | --- |
| Máximo de rodadas | 4 | Reproduzir + corrigir, revisão, um ajuste, uma de folga. |
| Máximo de membros ao mesmo tempo | 3 | Uma vaga por papel. O padrão de 4 também funciona. |
| Teto fixo | 20 rodadas · 12 membros | O líder não consegue iniciar membros além do seu limite. |


> Cole o link do próximo ticket numa squad e deixe ela reproduzir o bug primeiro. → https://runtallos.com/signup

## Como a execução acontece?

Uma execução de exemplo com um ticket do Linear. Ticket, código e diff são ilustrativos.

1. **O líder lê o ticket** — Abre o ENG-482 e planeja: reproduzir primeiro, depois corrigir, depois revisar.
2. **Reproduzir** — Quem reproduz escreve um teste que falha: o mesmo id de evento cria dois pedidos.
3. **Corrigir** — Quem corrige adiciona uma chave de idempotência na criação do pedido. O teste passa.
4. **Revisar** — O revisor aprova e sugere um índice único no banco como proteção extra.
5. **Uma pergunta para você** — O índice único entra nesta mudança ou numa migration separada? Você responde: separada.
6. **Relatório** — O líder entrega o relatório com `tallos squad report` e a execução espera a sua revisão.

## O que o líder pode te perguntar?

Squads de bug perguntam sobre escopo e sobre fatos que o ticket deixou de fora. O líder pergunta com `tallos squad ask`; você escolhe uma opção ou digita a sua.

- "Coloco o índice único nesta mudança ou numa migration separada?"
- "Os passos do ticket não reproduzem localmente. Você tem um payload de exemplo?"
- "Já existem duplicados em produção. Limpo aqui ou deixo para o time de operações?"

## O que você recebe no final?

- **Relatório final:** causa raiz, correção, teste de regressão e riscos em aberto. No exemplo: a criação de pedido não tinha chave de idempotência, então cada reenvio criava um pedido; teste de regressão adicionado; índice único deixado para uma migration separada.
- **Resultados por worktree:** o worktree de quem corrigiu, marcado como **Recomendado**, com **Ver alterações**.
- **Aceitar ou Descartar:** Aceitar transforma a linha recomendada em **Abrir para criar PR**. Vincule o PR ao ticket como você já faz.

Antes de aceitar, confira se o teste falha sem a correção. O guia de [como revisar código gerado por IA](https://runtallos.com/pt/aprenda/revisar-codigo-gerado-por-ia) mostra o que mais olhar.

## Quais variações funcionam bem?

- **Dois membros corrigindo.** Quando a causa raiz não é clara, coloque **Quantos** = 2 em quem corrige e peça ao líder para comparar, como na [melhor de três](https://runtallos.com/pt/squads/melhor-de-tres).
- **Sem quem reproduz.** Para um bug que já tem teste falhando, use a [construir e revisar](https://runtallos.com/pt/squads/construir-e-revisar) com o link do ticket.
- **Salve uma vez.** **Salvar como squad** guarda os três papéis. No próximo bug, mude só o link e o objetivo.

## Quais são os erros mais comuns?

- **Colar só o link.** Se o agente não consegue ler o ticket, o líder está chutando. Reescreva o bug no objetivo.
- **Corrigir antes de reproduzir.** Sem um teste falhando, não dá para diferenciar correção de coincidência. Diga a ordem nas instruções do líder.
- **Aceitar remendo de sintoma.** Proíba no objetivo sleeps, retries e try/catch que engole erro.
- **Confiar cegamente no ticket.** O texto do ticket entra no contexto do líder. Leia antes de começar.

Primeira vez? Siga [sua primeira squad](https://runtallos.com/pt/aprenda/seu-primeiro-squad), veja como as [squads](https://runtallos.com/pt/recursos/squads) funcionam ou como o líder conversa com o Tallos pela [CLI do Tallos](https://runtallos.com/pt/recursos/cli-e-skills).

## Perguntas frequentes

### Quais trackers de issues posso vincular a uma squad?

GitHub, GitLab, Linear e Jira. Cole a URL da issue em Link da tarefa; outros links são recusados.

### O Tallos importa a descrição do ticket para a squad?

O Tallos entrega ao líder o link e o provedor como tarefa de origem. O líder lê o ticket com as ferramentas do próprio agente, então vale reescrever o essencial no objetivo.

### Por que reproduzir o bug antes de corrigir?

Um teste falhando prova que o bug existe e vira o teste de regressão quando a correção entra. Ele também diz a quem corrige exatamente o que é "pronto".

### A squad fecha o ticket ou abre o pull request?

Não. A squad para esperando você aceitar ou descartar. Depois de aceitar, abra o worktree recomendado para criar o PR e atualize o ticket como de costume.

### E se a squad não conseguir reproduzir o bug?

O líder te pergunta o que falta, como um payload de exemplo, ou reporta que não conseguiu reproduzir. Nada é corrigido no chute.

### Posso usar uma issue do GitHub em vez de um ticket do Linear?

Pode. Links do GitHub, GitLab, Linear e Jira funcionam do mesmo jeito.

---

**Rode seus agentes em paralelo com o Tallos** — Claude Code, Codex, Gemini e mais de 30 agentes — cada um no seu workspace, com squads, chat, terminais e revisão num só app. Usa as assinaturas que você já tem.

https://runtallos.com/signup (macOS 13+ · Windows 10+)