- Emphasize using git show to see full commit content
- Note that test files contain good examples for changelog
- Encourage looking at actual code changes for better understanding
- Help find specific command examples from tests
- Emphasize reading PR comments from previous changelog updates
- Add gh command to view PR comments
- Note that review feedback may indicate what to avoid
- Help ensure special instructions from PR discussions are followed
- Clarify that CHANGES.md is a large file
- Instruct to focus on [To Be Released] section and recent versions
- Avoid reading the entire file unnecessarily
- Create separate section with detailed instructions for changeNotes
- Clarify that content should match CHANGES.md exactly (no summarizing)
- Provide HTML formatting guidelines and examples
- Emphasize not to create shorter or condensed versions
- Include example showing Markdown to HTML conversion
- Specify that PR descriptions should be taken directly from PR titles
- Don't regenerate or rewrite PR descriptions
- Maintain author's original wording for PR entries
- Clarify that PRs have different inclusion criteria than Features/Fixes
- Note that internal changes and refactoring PRs should be included
- Emphasize acknowledging community contributions regardless of visibility
- Make clear that "user-visible only" rule doesn't apply to PRs section
- Add "Fixed inlay offset calculations" as bad example
- Show better alternative with specific user-visible case
- Reinforce that technical internal fixes should either have clear user impact or be omitted
- Include bad example: "Fixed count validation in text objects" (too vague)
- Show better alternative: specific command that was fixed
- Emphasize: if unable to determine specific case, omit entry rather than be unclear
- Help ensure all changelog entries are meaningful to users
- Clarify that each change should appear in only ONE subsection
- Add note that features can also use YouTrack link format
- Emphasize no duplication between Features, Fixes, and other categories
- Update both Format Notes and Writing Style sections for clarity
- Change PR title format to "Update changelog: <super short summary>"
- Add example showing how to summarize key changes in title
- Update both GitHub workflow and changelog instructions for consistency
- Guide to search for and include official documentation links
- Add links to JetBrains features and Vim commands when relevant
- Include examples showing linked IntelliJ features (Next Edit Suggestion, multiple cursors)
- Help users find more information about mentioned features
- Add instruction to include examples of commands/operations in changelog entries
- Update example entries to demonstrate including specific commands
- Show how to describe what now works for both fixes and features
- Help users understand how to use new features or what was fixed
- Clarify that internal code changes should not be logged
- Emphasize that changelog is for users, not developers
- Strengthen user-focused writing style guidelines
- Exclude refactoring, code cleanup, and internal architecture changes
- Simplified CLAUDE.md to avoid redundancy with other docs
- Created .claude/changelog-instructions.md with detailed changelog maintenance guide
- Updated GitHub Action to reference the new changelog instructions doc
- Added instructions for updating changeNotes in build.gradle.kts
- Added notes about excluding API module changes (experimental status)
- Added step to check previous changelog PRs for special instructions
The append, prepend, and remove functions now correctly handle empty
option values. When an option is empty (""), we use an empty list
instead of splitting the empty string which would result in [""].
This fixes test failures in OptionScopeTest for operations on empty options.
This workflow runs daily at 5 AM UTC (or manually) and uses Claude to:
- Review commits and update CHANGES.md with meaningful changes
- Maintain the exact format used before the changelog gap
- Include YouTrack links for fixes (format: [VIM-XXXX](url))
- Reference merged PRs (excluding dependabot and Claude PRs)
- Handle the historical gap between versions 2.9.0 and 2.28.0
- Create PRs only when there are actual changes to document
Claude has access to git, GitHub CLI, and can fetch from YouTrack,
GitHub, and JetBrains plugin pages to gather accurate information.
This workflow runs three times a year (August 15, April 30, December 1)
and uses Claude to check if new IntelliJ versions need to be added to
TeamCity test configurations. Claude will automatically create a PR if
a new version is needed.
The workflow can also be triggered manually for testing.
