changelog
Maintain project changelogs automatically
Keeping changelogs updated is time-consuming and error-prone. This skill automates the process by analyzing commits, PRs, and releases to generate accurate, user-focused changelog entries following the IdeaVim format.
Download the skill ZIP
Upload in Claude
Go to Settings → Capabilities → Skills → Upload skill
Toggle on and start using
Test it
Using "changelog". Update changelog for commits since last release
Expected outcome:
- ## 2.29.0, 2024-01-15
- ### Features:
- * Added support for `g;` and `g,` commands to navigate through change list
- * Implemented `:history` command to show command history
- ### Fixes:
- * [VIM-3456] Fixed visual block mode with wrapped lines
- * [VIM-3458] Fixed `ci"` in strings with escaped quotes
- ### Merged PRs:
- * [850] by contributor: Add surround plugin improvements
Using "changelog". Convert changelog to HTML for marketplace
Expected outcome:
- <b>Features:</b><br>
- * Added support for <code>g;</code> and <code>g,</code> commands<br>
- * <a href="https://youtrack.jetbrains.com/issue/VIM-3456">VIM-3456</a> Fixed visual block mode<br>
Security Audit
SafeThis is a pure documentation skill containing only markdown instructions. It provides guidelines for maintaining the IdeaVim changelog and contains NO executable code, network calls, or file operations. All 110 static findings are false positives from the analyzer misinterpreting markdown code block syntax as shell commands and documentation URLs as network indicators.
Risk Factors
⚙️ External commands (59)
🌐 Network access (21)
📁 Filesystem access (1)
Quality Score
What You Can Build
Automate release documentation
Keep your project's changelog updated with minimal effort by automatically analyzing commits and PRs for user-facing changes.
Standardize release notes
Ensure consistent, professional release documentation that follows established patterns and includes proper references to issues and PRs.
Document community contributions
Properly acknowledge external contributors by automatically including their PRs in the changelog, even for internal changes.
Try These Prompts
Update the IdeaVim changelog for the upcoming 2.29.0 release. Check commits since the last documented version and include all user-facing changes.
Update the [To Be Released] section with recent commits from the master branch. Focus on user-visible features and bug fixes.
Review PR #1234 and determine if it needs a changelog entry. If so, prepare the appropriate entry following the changelog format.
Convert the latest [To Be Released] changelog entries to HTML format for the build.gradle.kts changeNotes section.
Best Practices
- Always review generated changelog entries for accuracy and clarity before committing
- Include specific examples of commands or features when describing fixes or new functionality
- Link to relevant documentation or JetBrains blog posts for new IntelliJ integrations
Avoid
- Don't include internal refactoring or code cleanup that doesn't affect users
- Avoid vague descriptions like "Fixed bugs" without specifying what was fixed
- Never skip the manual review step - automated changelog still needs human verification