| name | changelog-generator |
| description | Gerar e publicar releases de forma consistente a partir do histórico de commits. Usar esta skill quando for necessário atualizar `CHANGELOG.md`, definir próxima versão SemVer, criar tag Git, dar push da tag e criar release no GitHub. Aplicar em pedidos como "gerar changelog", "preparar release", "versionar projeto", "criar tag/release", ou quando houver necessidade de consolidar os últimos commits em notas de versão. |
Changelog Generator
Conduzir o fluxo completo de release com rastreabilidade: commits recentes -> entrada de changelog -> versão -> tag -> release no GitHub.
Modelo de Versionamento
Este projeto usa lockstep versioning: todos os packages (@lets-ui/tokens, @lets-ui/styles, @lets-ui/components) compartilham sempre a mesma versão. A tag canônica é vX.Y.Z (na raiz). Não existem tags por package.
O único CHANGELOG.md relevante é o da raiz do monorepo. Os arquivos em cada package são stubs que apontam para ele.
Fluxo Obrigatório
- Verificar branch atual, árvore limpa e sincronismo com remoto.
- Levantar commits desde a última tag.
- Definir bump de versão (SemVer).
- Atualizar
CHANGELOG.md (raiz).
- Atualizar
version nos três package.json publicáveis para o mesmo valor.
- Criar commit de release.
- Criar tag anotada da versão.
- Dar push da branch e da tag.
- Criar release no GitHub usando as notas do changelog.
Pré-checks (Bloqueantes)
Executar antes de editar arquivos:
- Confirmar
git status --porcelain vazio.
- Confirmar branch de release (normalmente
main).
- Confirmar que a branch local está atualizada (
git fetch --tags e comparação com remoto).
- Identificar última tag com
git describe --tags --abbrev=0 (formato vX.Y.Z).
- Interromper se a nova versão já existir em tag remota/local.
Coletar Commits
Extrair mudanças relevantes:
- Com tag anterior:
git log <ultima-tag>..HEAD --pretty=format:'%h %s'.
- Sem tag anterior:
git log --pretty=format:'%h %s'.
- Agrupar por tipo (
feat, fix, perf, refactor, docs, chore, test, build, ci).
- Ignorar commits irrelevantes para release notes (ex.: merges ruidosos) quando necessário.
Versionamento
Definir SemVer com base nos commits:
major: breaking change.minor: novas features sem quebra.patch: correções e ajustes sem quebra.
Se a versão não vier no pedido:
- Inferir pelos commits.
- Explicar a inferência na saída.
Atualizar CHANGELOG.md (raiz)
Seguir o padrão em references/changelog-format.md.
Incluir:
- Cabeçalho da versão no formato
## [vX.Y.Z] - DD-MM-YYYY.
- Seções por tipo de mudança.
- Links de comparação quando aplicável.
Não inventar mudanças: usar apenas commits reais.
Atualizar package.json dos packages publicáveis
Alterar o campo version em:
packages/lets-ui-tokens/package.jsonpackages/styles/package.jsonpackages/lets-ui-components/package.json
Todos devem receber o mesmo valor.
Publicação (Tag + GitHub Release)
Executar nesta ordem:
- Commitar
CHANGELOG.md e os três package.json com a nova versão.
- Criar tag anotada:
git tag -a vX.Y.Z -m "vX.Y.Z".
- Dar push da branch.
- Dar push da tag:
git push origin vX.Y.Z.
- Criar release no GitHub com título/tag
vX.Y.Z e notas derivadas do changelog.
Preferir gh release create vX.Y.Z --title "vX.Y.Z" --notes-file <arquivo-temp-com-notas>.
Critérios Adicionais Recomendados
Além dos critérios pedidos, aplicar:
- Validar que o link/referência da release aponta para commit/tag corretos.
- Evitar pular versão (ex.:
v1.2.0 após v1.1.9, salvo pedido explícito).
- Incluir resumo objetivo e lista de mudanças por categoria.
- Reportar pendências que bloqueiam release (working tree suja, falta de permissão GitHub, ausência de commits desde última tag).
- Não forçar publicação parcial: se falhar tag/release, reportar estado exato e próximos comandos seguros.
Formato de Saída
Sempre informar:
- Última tag encontrada.
- Intervalo de commits usado.
- Versão escolhida e justificativa (
major/minor/patch).
- Arquivos alterados (
CHANGELOG.md, três package.json).
- Status de commit, tag, push e release GitHub.
- Pendências ou falhas, com comando recomendado para recuperação.
Referências
- Ler
references/changelog-format.md para o template mínimo do CHANGELOG.md.
