Gerar Pr Azure

Gerar PR para Azure DevOps

Produzir uma descrição de PR fiel ao código alterado. Não criar nem publicar o PR, salvo quando o usuário pedir isso explicitamente.

Entrada obrigatória

Exigir no prompt uma descrição curta de cada task. Aceitar, por exemplo:

$gerar-pr-azure
#6383 — Erro ao gerar PDF sem responsável técnico
#6384 — Equipamento sem capacidade definida

Se o prompt não descrever a task, pedir essa informação antes de redigir o PR. Não usar somente o texto dos commits como substituto.

Identificar as tasks

1. Obter o nome da branch atual.
2. Extrair o número de nomes no padrão tipo/numero-descricao, como bug/5424-ajuste-de-layout-ao-exibir-nome-extenso.
3. Reconhecer como prefixos usuais bug, fix, hotfix, feature, feat, chore e refactor.
4. Se a branch não contiver um número inequívoco, usar os números fornecidos no prompt.
5. Se faltar algum número ou não for possível associar cada descrição a uma task, pedir a informação ausente.

Referenciar tasks somente como #numero. Não repetir título nem status; o Azure DevOps renderiza esses dados.

Analisar a branch

Usar dev como branch-base:

1. Confirmar que o diretório atual é um repositório Git e que dev existe. Se não existir, verificar origin/dev; se ambas faltarem, pedir a base.
2. Ler os commits exclusivos da branch atual.
3. Inspecionar o resumo, os arquivos e o diff usando a comparação de três pontos contra a base.
4. Relacionar cada mudança com a descrição da task correspondente.
5. Descrever apenas comportamentos comprovados pelo diff ou explicitamente informados.

Não inventar regras de negócio, perfis, mensagens, telas, IDs, testes ou impactos. Quando a associação entre alteração e task estiver ambígua, pedir esclarecimento.

Redigir

• Escrever em português claro, com tom técnico e objetivo.
• Gerar um título curto que resuma o objetivo comum das tasks, sem Pull Request:.
• Explicar o comportamento entregue sem transformar detalhes internos em benefícios inexistentes.
• Consolidar alterações repetidas e eliminar redundâncias.
• Preservar mensagens de erro exatas somente quando confirmadas no diff.
• Criar uma subseção por task em Solução Implementada, inclusive quando houver uma única task.

Classificar o tipo

Exibir todas as opções e marcar com [x] somente as aplicáveis:

• Bug fix: corrige comportamento defeituoso.
• Nova feature: adiciona funcionalidade percebida pelo usuário.
• Breaking change: introduz incompatibilidade comprovada para consumidores ou fluxos existentes.
• Melhoria técnica: refatora, melhora performance ou aplica melhores práticas; não marcar por consequência incidental de uma feature ou correção.
• Documentação / Wiki: documentação é parte material da entrega.

Marcar mais de uma quando forem independentemente aplicáveis.

Formato de saída

Entregar primeiro o título sugerido em uma linha e depois um único bloco Markdown pronto para copiar:

## Descrição
[Resumo do que o PR implementa e do objetivo operacional.]

---

## Task
#1234

---

## Problema
[Estado anterior e impactos concretos.]

---

## Solução Implementada

### #1234 — [Resumo da solução]
[Alterações relacionadas à task.]

---

## Screenshots (se aplicável)

Inclua aqui screenshots ou gifs que demonstrem as mudanças visuais, se aplicável.

---

## Tipo de Mudança

- [ ] Bug fix (correção de algum bug)
- [ ] Nova feature (mudança que adiciona uma nova funcionalidade)
- [ ] Breaking change (fix ou feature que causaria uma mudança significativa na funcionalidade existente)
- [ ] Melhoria técnica (refatoração, melhorias de performance, melhores práticas)
- [ ] Documentação / Wiki

Para várias tasks, listar cada #numero em uma linha na seção Task e criar subseções correspondentes, na mesma ordem, em Solução Implementada.

Não adicionar links ou imagens por conta própria. Manter sempre o texto padrão da seção de screenshots.