Update CHANGELOG.md for the changes on the current branch, following Keep a Changelog format. Use when the user asks to update the changelog, prep release notes, or before opening a PR in repos that keep a changelog.
Instalación
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Update CHANGELOG.md for the changes on the current branch, following Keep a Changelog format. Use when the user asks to update the changelog, prep release notes, or before opening a PR in repos that keep a changelog.
Changelog update
Update CHANGELOG.md to reflect the work on the current branch.
Steps
Find the changes to describe: git log --oneline <default-branch>..HEAD plus git diff --stat <default-branch>...HEAD. If the branch has no commits yet, use the staged/working changes instead.
Open CHANGELOG.md. If it doesn't exist, create it with a # Changelog header, a note that it follows Keep a Changelog, and an ## [Unreleased] section.
Add entries under ## [Unreleased], grouped by category — only include categories that have entries:
### Added — new features
### Changed — changes to existing behavior
### Fixed — bug fixes
### Removed — removed features
### Security — vulnerability fixes
Write entries for users of the software, not for developers reading the diff: describe visible behavior ("Fixed window position not restored on second monitor"), not implementation ("refactored WindowManager").
One entry per meaningful change; fold trivial commits (typo fixes, CI tweaks) into nothing — they don't belong in a changelog.
Don't invent a version number or date — releases get cut separately. Entries stay under [Unreleased] until then.
On release (only when explicitly asked to cut a version)
Rename [Unreleased] to [X.Y.Z] - YYYY-MM-DD (matching the version in package.json), and add a fresh empty [Unreleased] section above it.
