Saída estruturada
Todo relatório de bug segue esta estrutura:
- Título — resumo conciso (máximo 8 palavras)
- O que acontece — descrição do comportamento do bug
- Contexto do git — branch atual e mudanças recentes
- Passos de reprodução — inferidos da descrição ou placeholder
- Esperado vs Real — formato comparativo
Detecção automática de severity
O sistema infere a severity a partir da sua descrição:
| Severity | Palavras-gatilho | Exemplo |
|---|---|---|
| Critical | crash, perda de dados, segurança, fora do ar, bloqueia | ”O app crasha no startup” |
| High | quebrado, falha, não consigo, regressão | ”Form de login falha na validação” |
| Medium | errado, incorreto, inesperado, lento | ”API retorna dados errados” |
| Low | menor, cosmético, typo, alinhamento | ”Botão desalinhado no mobile” |
Integração com o git
Uma única chamada Bash captura:
- Nome da branch atual
- Resumo das mudanças recentes (últimos commits)
- Arquivos modificados relevantes para a área do bug
Esse contexto é incluído automaticamente no relatório, para o próximo desenvolvedor ver o que mudou perto do bug.
Quando usar /note-bug
Use /note-bug em vez de /note quando quiser:
- Tag automática de severity
- Contexto do git no relatório
- Formato estruturado de passos de reprodução
- Cor rosa para identificação fácil