# Gerar Pr Azure

> Gerar descrições Markdown de Pull Requests do Azure DevOps em português a partir dos commits e do diff da branch Git atual contra dev. Usar quando o usuário pedir para redigir, montar ou revisar a descrição de um PR e fornecer a descrição das tasks; extrair o número da task do nome da branch quando disponível e aceitar números informados para branches com várias tasks.

- Skill: `lopesmauro/gerar-pr-azure` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add lopesmauro/gerar-pr-azure`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lopesmauro/gerar-pr-azure/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: lopesmauro (https://skillmd.com/u/lopesmauro)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/lopesmauro/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:

```text
$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:

```markdown
## 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.