Criar um Bug

O que Criar um Bug faz?

Transforme sintomas, logs ou uma regressão observada em um bug que outro engenheiro possa reproduzir e corrigir sem suposições.

Fluxo de Trabalho

1. Identifique o repositório alvo e o provedor de issues a partir da solicitação, do remote do repositório ou das ferramentas de provedor disponíveis. Se nenhum provedor com permissão de escrita estiver disponível, produza um rascunho em Markdown neutro em relação ao provedor.
2. Pesquise issues abertas e fechadas pelo comportamento, componente e texto de erro distintivo. Vincule uma duplicata real em vez de criar outra issue.
3. Inspecione o código relevante, testes, configuração e alterações recentes. Separe as evidências observadas das hipóteses.
4. Reproduza o bug quando for seguro e prático. Registre os menores passos determinísticos, entradas, ambiente, resultado real e resultado esperado. Nunca afirme uma reprodução que você não executou.
5. Escopo do impacto: usuários ou fluxos de trabalho afetados, gravidade, status de regressão, solução alternativa e risco de dados/segurança. Marque incógnitas explicitamente.
6. Exija um teste de regressão que falhe antes da correção e passe após ela. Nomeie a camada de teste e a fixture apropriadas quando as evidências do repositório suportarem.
7. Redija o bug usando o modelo abaixo. Mostre o rascunho final antes de criar ou alterar um ticket externo, a menos que o usuário já tenha autorizado explicitamente a criação.
8. Crie a issue com a capacidade nativa do provedor quando disponível e retorne sua URL. Caso contrário, retorne o rascunho completo em Markdown e a ação de provedor ausente.

Modelo de Bug

## Resumo
<uma frase nomeando o comportamento quebrado e o usuário afetado>

## Reprodução
1. <passo determinístico mínimo>
2. <próximo passo>
3. <resultado observado>

## Comportamento esperado
<o que deveria acontecer, fundamentado em um requisito, teste ou comportamento estabelecido>

## Comportamento real
<o que acontece, incluindo texto de erro exato quando útil>

## Impacto
<quem é afetado, gravidade, frequência, solução alternativa, status de regressão>

## Evidências
- <caminho de código, teste, log, captura de tela, revisão ou issue vinculada>

## Teste de regressão
- [ ] <teste específico que falha antes da correção e passa após ela>

## Ambiente
- Versão/revisão:
- SO/runtime/navegador:
- Configuração:

## Perguntas em aberto
- <apenas fatos não resolvidos que podem alterar o escopo ou a gravidade>

Regras de segurança

• Não cole tokens de acesso, credenciais, dados pessoais ou conteúdo desnecessário do cliente em uma issue pública.
• Redija segredos em logs preservando a estrutura útil do erro.
• Não transforme uma causa suspeita em fato sem evidências.
• Não implemente a correção, faça commit, push ou altere o estado da issue a menos que o usuário solicite.

---

Construído por aictrl.dev. Esta skill ensina o fluxo de trabalho; aictrl operacionaliza ele — fundamentado no seu backlog, padrões de equipe e grafo de conhecimento do código-fonte. Veja como →