---
name: changelog-entry
description: "Gera CHANGELOG.md SemVer da feature atual a partir de REPORT.md + diff do branch. Use entre report-writer e git-flow-manager quando o projeto mantém CHANGELOG."
---

# Objetivo

Produzir uma entrada de CHANGELOG.md precisa, baseada em evidências (REPORT.md + diff), em linguagem de usuário final — não de desenvolvedor.

# Quando usar
Use esta skill quando:

- o projeto tem `CHANGELOG.md` ou convenção de changelog
- `report-writer` foi concluído com `READY_FOR_COMMIT`
- o usuário pede "atualizar o changelog" antes do commit

# Quando NÃO usar
Não use esta skill para:

- gerar descrição de PR (use `pr-description-writer`)
- escrever `REPORT.md` (use `report-writer`)
- commitar o changelog (use `git-flow-manager`)
- projetos sem `CHANGELOG.md`

# Leia antes de agir

1. `../release-prep/scripts/release_context.py --format json`
2. `features/<feature>/REPORT.md`
3. `CHANGELOG.md` — para verificar o formato já usado no projeto
4. `git diff main...HEAD --stat` — para confirmar escopo

# Formato padrão

Siga o formato existente em `CHANGELOG.md`. Se não houver, use:

```markdown
## [<versão>] — <YYYY-MM-DD>

### Added
- <descrição em linguagem de usuário>

### Changed
- <descrição>

### Fixed
- <descrição>

### Removed
- <descrição>
```

# Regras obrigatórias

- Leia `REPORT.md` e o diff da branch antes de gerar a entrada.
- Use apenas as categorias SemVer suportadas pelo template: `Added`, `Changed`, `Fixed` e `Removed`.
- Descreva em linguagem de usuário final, sem jargão técnico ou referências a commits.
- Não invente entradas — só registre o que está no diff confirmado.
- Mantenha cada entrada em uma linha quando possível; agrupe variações pequenas.

# Processo

1. Leia `features/<feature>/REPORT.md` — extraia "Mudanças" e "Validação"
2. Rode `git log --oneline <base>..HEAD` para confirmar commits incluídos no diff
3. Identifique categoria SemVer: `Added` (feature nova), `Changed` (alteração comportamento), `Fixed` (bug fix), `Removed` (deleção pública)
4. Redija entrada em linguagem de usuário final — sem jargão de desenvolvedor
5. Insira no `CHANGELOG.md` na seção `[Unreleased]` ou crie a seção se ausente
6. NÃO commite — apenas grave o arquivo

# Regras

- Linguagem de usuário final: "Agora é possível X" em vez de "Implementado método Y"
- Nunca mencione nomes de arquivos, funções ou classes internas
- Versão: pergunte ao usuário se não estiver definida no REPORT.md ou `pyproject.toml`/`package.json`
- Escreva apenas nas seções relevantes (omita seções vazias)
- Insira a nova entrada no topo do arquivo, abaixo do cabeçalho

# Saída final esperada

1. `CHANGELOG.md` atualizado com a nova entrada no topo
2. versão usada (confirmada ou inferida)