// Generate changelog entries from merged PRs since the last release. Fetches PR data, classifies changes as normal or breaking, presents for user review, and optionally creates a PR with the updates.
| name | generate-changelog |
| description | Generate changelog entries from merged PRs since the last release. Fetches PR data, classifies changes as normal or breaking, presents for user review, and optionally creates a PR with the updates. |
Generate changelog entries by analyzing merged PRs since the last release.
Execute these phases in order:
Run:
git tag --sort=-creatordate | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -1
Record as LAST_TAG. Get the tag's date:
git log -1 --format=%aI $LAST_TAG
Record as TAG_DATE.
Read CHANGELOG.md and extract all unique [tag] patterns from changelog entries (pattern: - [tag] ...). Build a deduplicated vocabulary list preserving original casing.
gh pr list --state merged --search "merged:>TAG_DATE" --json number,title,author,body,labels,mergedAt --limit 100
Use the date portion only from TAG_DATE (e.g. 2026-02-09).
Skip rules (in order):
changelog label → skip (already tracked in a previous changelog update)dependabot or dependabot[bot] → skipSwitch to and contains -nextvX.Y.ZRelease vupdate changelog (case insensitive) → skip[x] This PR should be mentioned in the changelog → skipOverride: If the PR body contains [x] This PR should be mentioned in the changelog, always include it regardless of rules 3-5. PRs with the changelog label (rule 1) and dependabot PRs (rule 2) are always skipped.
[x] This PR introduces a breaking change → breaking[ ] This PR introduces a breaking change → normalPick the most fitting tag from the vocabulary (Step 1.2) based on PR title and body. If no tag fits, mark as uncertain: [???/best-guess].
Normal changes:
- [tag] Description [#N](https://github.com/OWNER/REPO/pull/N)
Breaking changes with migration sub-items:
- [tag] Description [#N](https://github.com/OWNER/REPO/pull/N)
- Migration detail 1
- Migration detail 2
Multiple PRs for the same change:
- [tag] Description [#N](url) [#M](url)
Formatting:
- (dash + exactly 3 spaces)- (4 spaces from parent dash)- [tag] and description text[#123](https://github.com/OWNER/REPO/pull/123)Wording:
Capitalization:
[diagram], not [Diagram]### Potentially Breaking Changes)Description cleanup from PR title:
GLSP-1234:, GH-123:, ISSUE-456:)fix:, feat:, chore:Breaking changes:
Read CHANGELOG.md in the repository root.
Active section detection:
- active suffix (e.g. ## v2.7.0 - active)- active suffix) → create a new active section above itCreating a new section:
LAST_TAG (e.g. v2.6.0 → v2.7.0)## heading:## v2.7.0 - active
### Changes
- [tag] Entry [#N](url)
### Potentially Breaking Changes
- [tag] Entry [#N](url)
- Sub-item detail
Only include "Potentially Breaking Changes" if there are breaking entries.
Merging into existing active section:
Use the Edit tool to update CHANGELOG.md directly in the current working tree. Match existing formatting conventions.
git diff CHANGELOG.md
Present the diff to the user.
List any entries flagged as uncertain (category or breaking status) and ask the user to resolve them.
Even if nothing is uncertain, ask:
"Does everything look correct, or would you like to adjust any entries?"
Do NOT proceed to Phase 4 unless the user explicitly requests a PR.
Only execute this phase if the user explicitly requests a PR (either in their initial prompt or after reviewing the changelog). If the user hasn't mentioned a PR, ask after approval:
"Would you like me to create a PR for this changelog update, or are you done?"
Check if changelog-update exists on remote:
git ls-remote --heads origin changelog-update
If it exists, increment: changelog-update-2, changelog-update-3, etc.
git checkout -b BRANCH_NAME
git add CHANGELOG.md
git commit -m "Update changelog"
git push -u origin BRANCH_NAME
If the repo has a .github/PULL_REQUEST_TEMPLATE.md, use its structure to fill in the PR body. Otherwise use a simple body describing the changelog update.
Report the PR URL.
Add the changelog label to every PR mentioned in the new entries:
gh pr edit PR_NUMBER --add-label "changelog"
Report which PRs were labeled.
Auto-fix all lint, formatting, and copyright header issues across the workspace. Use when validation (`/verify`) fails or when explicitly requested.
Run full project validation (lint, format, copyright headers) to catch issues before committing. IMPORTANT - Proactively invoke this skill after completing any code changes (new features, bug fixes, refactors) before reporting completion to the user.