changelog_skill

Overview

This skill maintains IdeaVim's CHANGES.md and the build.gradle.kts changeNotes to keep release notes accurate and in sync. It resumes changelog maintenance from version 2.28.0 and preserves the historical gap note for versions 2.10.0–2.27.0. The goal is clear, user-focused entries grouped by Features, Fixes, Changes, and Merged PRs.

How this skill works

The skill inspects the top portion of CHANGES.md (especially the [To Be Released] section), recent git tags, and merged PRs to collect user-facing changes. It examines commits, test changes, and PR descriptions to craft concise one-line entries, then updates CHANGES.md and converts the same content to HTML for the changeNotes block in build.gradle.kts. It avoids developer-only or excluded changes and ensures a new empty [To Be Released] section is left after each release.

When to use it

• Preparing a release and you need to turn unreleased changes into a version entry
• Updating CHANGES.md after reviewing merged PRs and commits on master
• Syncing build.gradle.kts changeNotes with CHANGES.md for the JetBrains Marketplace
• Reviewing commits/PRs to determine what should be user-visible in the changelog
• Checking for undocumented tags or releases that need entries

Best practices

• Always read only the top portion of CHANGES.md and focus on [To Be Released] and recent versions
• Use git tags and gh/pr lists to find merged PRs and release dates rather than relying solely on dates
• Examine commit diffs and test files — tests often show exact commands or cases to include
• Write concise, user-facing one-line entries and include examples when they clarify the user impact
• Exclude dependabot, Claude-generated PRs, internal refactors, test-only changes, API experimental module changes, and Vim Everywhere items unless guidance says otherwise
• After release, convert the documented markdown exactly to HTML for changeNotes and preserve any existing reward program text

Example use cases

• Documenting unreleased master changes into the [To Be Released] section before a release
• Creating a release entry for 2.28.0 with Features, Fixes, and Merged PRs after reading merged PRs and tests
• Updating build.gradle.kts changeNotes by converting the current [To Be Released] markdown to the required HTML format
• Reviewing recent PRs to decide which user-visible fixes to include in CHANGES.md
• Checking for undocumented plugin versions via git tags and the JetBrains plugin versions page