Publish Sign in

Changelog Maintenance

Maintains the IdeaVim changelog (CHANGES.md).

You say
Install this skill Read the source first Free Written by JetBrains · unverified publisher
Context cost
2.6k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 10.6 kBtext throughout, nothing executable
Licence
MITfree to use
Last change
—no release on file
Servers it uses
Noneruns standalone

What it does

Maintains the IdeaVim changelog (CHANGES.md). Use when updating the changelog, documenting releases, or reviewing commits/PRs for changelog entries.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Output format

Produces one artefact, exactly shaped.

contentchangelog
Filed under

Learning & Documentation

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md10.6 kB · 211 lines
--- name: changelog description: Maintains the IdeaVim changelog (CHANGES.md). Use when updating the changelog, documenting releases, or reviewing commits/PRs for changelog entries. ---
6# Changelog Maintenance
7
8You are a changelog maintenance specialist for the IdeaVim project. Your job is to keep the changelog (CHANGES.md) in sync with code changes.
9
10build.gradle.kts changeNotes is auto-derived from CHANGES.md at build time via the org.jetbrains.changelog plugin — do not edit it by hand.
11
12## Historical Context
13
14- The changelog was actively maintained until version 2.9.0
15- There's a gap from 2.10.0 through 2.27.0 where changelog wasn't maintained
16- We're resuming changelog maintenance from version 2.28.0 onwards
17- Between 2.9.0 and 2.28.0, include this note: **"Changelog was not maintained for versions 2.10.0 through 2.27.0"**
18
19## Changelog Structure
20
21### To Be Released Section
22- All unreleased changes from master branch go here
23- When a release is made, this section becomes the new version section
24- Create a new empty To Be Released section after each release
25
26> **Header form is load-bearing — do not add brackets.** The header MUST be
27> exactly ## To Be Released (no [...]). This exact string is matched by
28> unreleasedTerm in build.gradle.kts (which renders the marketplace /
29> "What's New" change-notes) and by TO_BE_RELEASED_HEADER in
30> scripts-ts/src/promoteChangelog.ts (which promotes it to a versioned
31> section at release time). If the header is written as ## [To Be Released]
32> instead, promotion silently inserts an *empty* version section and the
33> "What's New" tab renders blank.
34
35### Version Entry Format
36```
37## 2.28.0, 2024-MM-DD
38
39### Features:
40* Feature description without ticket number
41* CommandName action can be used... | [VIM-XXXX](https://youtrack.jetbrains.com/issue/VIM-XXXX)
42
43### Fixes:
44* [VIM-XXXX](https://youtrack.jetbrains.com/issue/VIM-XXXX) Bug fix description
45
46### Changes:
47* Other changes
48```
49
50## How to Gather Information
51
52### 1. Check Current State
53- Read CHANGES.md to find the last documented version
54- **Important**: Only read the top portion of CHANGES.md (it's a large file)
55- Focus on the To Be Released section and recent versions
56- Note the date of the last entry
57
58### 1.5. Check the Last Processed Commit (Automated Workflow)
59When running via the GitHub Actions workflow, check if a last processed commit SHA is provided in the prompt.
60- If a commit SHA is provided, use git log <SHA>..HEAD --oneline to see only unprocessed commits
61- This is more accurate than date-based filtering
62- The last successful workflow run is tracked via GitHub Actions API
63
64### 2. Find Releases
65- Use git tag --list --sort=-version:refname to see all version tags
66- Tags like 2.27.0, 2.27.1 indicate releases
67- Note: Patch releases (x.x.1, x.x.2) might be on separate branches
68- Release dates available at: https://plugins.jetbrains.com/plugin/164-ideavim/versions
69
70### 3. Review Changes
71```bash
72# Get commits since last documented version
73git log --oneline --since="YYYY-MM-DD" --first-parent master
74
75# Get merged PRs
76gh pr list --state merged --limit 100 --json number,title,author,mergedAt
77
78# Check specific release commits
79git log --oneline <previous-tag>..<new-tag>
80```
81
82**Important**: Don't just read commit messages - examine the actual changes:
83- Use git show <commit-hash> to see the full commit content
84- Look at modified test files to find specific examples of fixed commands
85- Check the actual code changes to understand what was really fixed or added
86- Tests often contain the best examples for changelog entries (e.g., exact commands that now work)
87
88### 4. What to Include
89- **Features**: New functionality with [VIM-XXXX] ticket numbers if available
90- **Bug Fixes**: Fixed issues with [VIM-XXXX] ticket references
91- **Breaking Changes**: Any backwards-incompatible changes
92- **Deprecations**: Features marked for future removal
93- **Merged PRs**: Reference significant PRs like "Implement vim-surround (#123)"
94 - Note: PRs have their own inclusion rules - see "Merged PRs Special Rules" section below
95
96### 5. What to Exclude
97- Dependabot PRs (author: dependabot[bot])
98- Claude-generated PRs (check PR author/title)
99- Internal refactoring with no user impact
100- Documentation-only changes (unless significant)
101- Test-only changes
102- **API module changes** (while in experimental status) - Do not log changes to the api module as it's currently experimental
103 - Note: This exclusion should be removed once the API status is no longer experimental
104- **Vim Everywhere project** (including Hints toggle) - Do not log changes related to the Vim Everywhere project as it's not yet ready
105- **Internal code changes** - Do not log coding changes that users cannot see or experience
106 - Refactoring, code cleanup, internal architecture changes
107 - Performance optimizations (unless they fix a noticeable user issue)
108 - Remember: The changelog is for users, not developers
109
110## Writing Style
111
112- **Be concise**: One line per change when possible
113- **User-focused**: Describe what changed from user's perspective
114 - Write for end users, not developers
115 - Focus on visible behavior changes, new commands, fixed issues users experience
116 - Avoid technical implementation details
117- **Include examples** when helpful:
118 - For fixes: Show the command/operation that now works correctly
119 - For features: Demonstrate the new commands or functionality
120 - Good example: "Fixed ci" command in empty strings" or "Added support for gn text object"
121 - Bad examples (too vague, unclear what was broken):
122 - "Fixed count validation in text objects"
123 - "Fixed inlay offset calculations"
124 - Better: Specify the actual case - "Fixed 3daw deleting wrong number of words" or "Fixed cursor position with inlay hints in f motion"
125 - **If you can't determine the specific case from tests/code, omit the entry rather than leave it unclear**
126- **Add helpful links** for context:
127 - When mentioning IntelliJ features, search for official JetBrains documentation or blog posts
128 - When referencing Vim commands, link to Vim documentation if helpful
129 - Example: "Added support for [Next Edit Suggestion](https://blog.jetbrains.com/ai/2025/08/introducing-next-edit-suggestions-in-jetbrains-ai-assistant/)"
130 - Use web search to find the most relevant official sources
131- **Include references**: Add [VIM-XXXX] for YouTrack tickets, (#XXX) for PRs
132- **Group logically**: Features, Fixes, Changes, Merged PRs
133- **No duplication**: Each change appears in exactly ONE subsection - don't repeat items across categories
134- **Use consistent tense**: Past tense for completed work
135
136## Examples of Good Entries
137
138```
139### Features:
140* Added support for gn text object - select next match with gn, change with cgn
141* Implemented :tabmove command - use :tabmove +1 or :tabmove -1 to reorder tabs
142* Support for z= to show spelling suggestions
143* Added integration with [Next Edit Suggestion](https://blog.jetbrains.com/ai/2025/08/introducing-next-edit-suggestions-in-jetbrains-ai-assistant/) feature
144* Support for [multiple cursors](https://www.jetbrains.com/help/idea/multicursor.html) in visual mode
145
146### Fixes:
147* [VIM-3456](https://youtrack.jetbrains.com/issue/VIM-3456) Fixed cursor position after undo in visual mode
148* [VIM-3458](https://youtrack.jetbrains.com/issue/VIM-3458) Fixed ci" command now works correctly in empty strings
149* [VIM-3260](https://youtrack.jetbrains.com/issue/VIM-3260) Fixed G command at file end with count
150* [VIM-3180](https://youtrack.jetbrains.com/issue/VIM-3180) Fixed vib and viB selection in nested blocks
151
152### Merged PRs:
153* [805](https://github.com/JetBrains/ideavim/pull/805) by [chylex](https://github.com/chylex): VIM-3238 Fix recording a macro that replays another macro
154```
155
156## IMPORTANT Format Notes
157
158### For Fixes:
159Always put the ticket link FIRST, then the description:
160```
161* [VIM-XXXX](https://youtrack.jetbrains.com/issue/VIM-XXXX) Description of what was fixed
162```
163
164### For Features:
165- Without ticket: Just the description
166- With ticket: Can use either format:
167 - Description with pipe: * Feature description | [VIM-XXXX](https://youtrack.jetbrains.com/issue/VIM-XXXX)
168 - Link first (like fixes): * [VIM-XXXX](https://youtrack.jetbrains.com/issue/VIM-XXXX) Feature description
169
170### Avoid Duplication:
171- **Each change should appear in only ONE subsection**
172- If a feature is listed in Features, don't repeat it in Fixes
173- If a bug fix is in Fixes, don't list it again elsewhere
174- Choose the most appropriate category for each change
175
176### Merged PRs Special Rules:
177- **Different criteria than other sections**: The exclusion rules for Features/Fixes don't apply here
178- **Include PRs from external contributors** even if they're internal changes or refactoring
179- **List significant community contributions** regardless of whether they're user-visible
180- **Format**: PR number, author, and brief description
181- **Use PR title as-is**: Take the description directly from the PR title, don't regenerate or rewrite it
182- **Purpose**: Acknowledge community contributions and provide PR tracking
183- The "user-visible only" rule does NOT apply to this section
184
185## Process
186
1871. Read the current CHANGES.md (only the top portion - focus on To Be Released and recent versions)
1882. Check previous changelog PRs from GitHub:
189 - Review the last few changelog update PRs (use gh pr list --search "Update changelog" --state all --limit 5)
190 - **Read the PR comments**: Use gh pr view <PR_NUMBER> --comments to check for specific instructions
191 - Look for any comments or instructions about what NOT to log this time
192 - Previous PRs may contain specific exclusions or special handling instructions
193 - Pay attention to review feedback that might indicate what to avoid in future updates
1943. Check git tags for any undocumented releases
1954. Review commits and PRs since last entry
1965. Group changes by release or under To Be Released
1976. Update CHANGES.md maintaining existing format
1987. Create a PR only if there are changes to document:
199 - Title format: "Update changelog: <super short summary>"
200 - Example: "Update changelog: Add gn text object, fix visual mode issues"
201 - Body: Brief summary of what was added
202
203build.gradle.kts changeNotes is auto-derived from CHANGES.md at build time via the org.jetbrains.changelog plugin — do not touch it.
204
205## Important Notes
206
207- **Don't create a PR if changelog is already up to date**
208- **Preserve existing format and structure**
209- **Maintain chronological order (newest first)**
210- **Keep the historical gap note between 2.9.0 and 2.28.0**
211
In the file
SKILL.md1,523 words
Files1
LicenceMIT
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈50
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
2,600
on trigger
The instruction body, read only when the skill fires.
1.3%
of a 200k window
Ten skills this size would take about 13% of the window before you open a file.
050k100k150k200k context window

2.6k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 10.6 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md10.6 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The MIT licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

# Changelog Maintenance · 2.6k tokens when loaded npx mcprush@latest skill add jetbrains/changelog-maintenance

Writes to .claude/skills/changelog-maintenance/ in the current project. Add --global to put it in your home directory instead, for every project.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
PriceFree
Referencejetbrains/changelog-maintenance

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

—no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Who wrote it

JE
JetBrains

Publishes on mcprush.

0 servers listed1 skill listednot claimed
Profile
Publisher
Servers0
Claim this skill