version: "1.0.1" name: ai-assist-changelog-bump description: "Validate and fix the CHANGELOG.md version number before opening a PR, commiting, or pushing changes, and keep package.json's version aligned with it. Reads main branch to determine the current latest version, classifies changes on the current branch, and proposes the correct next semver. Use this skill when the user mentions changelog, version number, preparing a PR, release version, semver check, or says 'check the changelog', 'what version should this be', 'prepare for PR', or 'fix the version'. Also use proactively when you notice a CHANGELOG entry that may have an incorrect version number."

Local Changelog Validator

Ensure the CHANGELOG.md entry for the current branch has the correct semver version before a PR is opened, commit is made, or changes are pushed. This skill exists because parallel branches independently pick version numbers that collide or leap-frog when merged — this validates against main's actual state right before the PR.

Workflow

Step 1 — Gather state

Run these commands to understand the current situation:

# 1. Current latest version on main
git show main:CHANGELOG.md | head -20
 
# 2. Current branch name (for ticket ID extraction)
git branch --show-current
 
# 3. What this branch changed (commit subjects)
git log main...HEAD --oneline
 
# 4. Files changed on this branch
git diff main...HEAD --name-only
 
# 5. Current package.json version, if the repo has one (for alignment)
git show main:package.json | grep '"version"'

Extract from main's CHANGELOG:

• The latest version number (the first version heading — see "Version heading formats" below)
• The date of that version
• The heading format the file uses, so new entries match it exactly

If a package.json exists, also note its version field — it should track the CHANGELOG's latest released version, and this skill keeps the two aligned (see Step 6).

Extract from the branch:

• The list of changed files to classify the change type
• The commit messages for changelog entry content

Version heading formats

CHANGELOGs use different heading conventions. Both of these are valid and must be handled:

Variants of the same two styles also occur and count as matches: ## [v1.8.1], ## 1.8.1, and any of the above with –, —, (2026-08-13), or no date at all after the version.

Match version headings with a pattern that tolerates all of these, for example:

# Latest version heading on main (any supported style)
git show main:CHANGELOG.md | grep -m1 -E '^##[[:space:]]+\[?v?[0-9]+\.[0-9]+\.[0-9]+\]?'

The captured semver is [0-9]+\.[0-9]+\.[0-9]+ — strip any surrounding [/] and any leading v before comparing or incrementing. Never compare version strings raw; compare the three numeric components.

Detect the file's dominant style once and reuse it. Look at the existing version headings in CHANGELOG.md on the branch (falling back to main's if the branch has none) and record which style they use — bracketed vs. v-prefixed, whether a v appears inside brackets, and the separator before the date. Every heading this skill writes must match that style exactly. Never convert a file from one style to the other, and never mix styles within a file.

Unreleased headings appear as ## [Unreleased] or ## Unreleased — treat both as "no concrete version yet".

Step 2 — Classify the change

Determine the change type by examining what was modified on this branch:

These rules come from .agents-docs/AGENTS-contributing.md — if they've been updated, defer to the current version of that file.

Step 3 — Compute the correct version

Starting from main's latest version:

• Minor bump: increment the middle number, reset patch to 0 (e.g., 1.8.1 → 1.9.0)
• Patch bump: increment the last number (e.g., 1.8.1 → 1.8.2)

Use today's date in YYYY-MM-DD format.

Step 4 — Check the current branch's CHANGELOG

Read the current CHANGELOG.md on the branch. Look for:

1. No entry exists yet for this branch's work — the branch hasn't added a version entry above main's latest. Proceed to Step 5 to draft one.

1. An entry exists but the version is wrong — the branch has a version entry, but it doesn't match the computed correct version (common when branches were rebased or other PRs merged first). Report the discrepancy:

``` Version check for branch: {branch-name}

Main is at: {main-version} Branch claims: {branch-version} Correct version: {computed-version} ({classification})

The version needs to be updated: {branch-version} → {computed-version} ```

Ask: "Update the version to {computed-version}? (yes / no)"

1. An entry exists and the version is correct — report success:

``` Version check for branch: {branch-name}

Main is at: {main-version} Branch version: {branch-version} ({classification})

Version is correct. CHANGELOG is ready for PR. ```

Stop here unless the user asks for content changes.

Step 5 — Draft or fix the CHANGELOG entry

If no entry exists, draft a new one based on the commits and changed files, using the heading style detected in Step 1:

## [{computed-version}] - {YYYY-MM-DD}
 
### {Added|Changed|Fixed}
 
-**{skill-or-area}**: {concise description of what changed and why}

For a v-prefixed file, the same entry is written as:

## v{computed-version} - {YYYY-MM-DD}

Present the draft and ask for approval before writing.

If the version is wrong, update only the version number and date — preserve the existing content, the heading's style, and its surrounding punctuation unless the user asks for content changes too.

If the date is stale (entry exists with correct version but old date), update to today's date since this is when the PR will be opened.

After any changes, show the final CHANGELOG entry for confirmation.

Step 6 — Align package.json (if it exists)

If the repo has a package.json with a version field, keep it in sync with the CHANGELOG's latest released version (the newest version heading — in either supported style — that is a real version, not an Unreleased heading).

• After settling the CHANGELOG version in Step 5, read package.json and compare its version to that version.
• If they differ, update package.json's version to match — change only the version field, preserving all other keys, ordering, and formatting (indentation, trailing newline).
• If they already match, leave package.json untouched and note it's already aligned.
• package.json's version is always the bare semver — strip any v prefix or brackets from the CHANGELOG heading before writing it.
• If the CHANGELOG's top entry is still an Unreleased heading (no concrete version yet), do not touch package.json — there's no released version to align to. Mention that package.json will be bumped once the entry is given a real version.

Show the version change (old → new) for confirmation alongside the CHANGELOG entry. If a package-lock.json exists, remind the user it should be refreshed (e.g., via npm install) so the lockfile's top-level version matches — but don't run it automatically.

Rules

• Never create a version entry without checking main first — the whole point is to derive the version from main's current state
• Always present changes before writing — the user should see and approve the CHANGELOG entry
• Keep bullet points concise — one sentence per change, focused on what changed and why
• If multiple change types exist (Added + Changed), use multiple headings under the same version
• The date should reflect when the PR is being prepared (today), not when the work started
• If the branch has no meaningful changes vs main (e.g., only non-skill files changed), say so and ask if a CHANGELOG entry is actually needed
• Support both ## [x.y.z] and ## vx.y.z heading styles — detect which one the file already uses and write new entries in that same style
• Never rewrite a CHANGELOG from one heading style to the other, and never mix styles within a single file
• Keep package.json's version aligned with the CHANGELOG's latest released version — only edit the version field, never reformat or reorder the rest of the file
• Never align package.json to an Unreleased heading — only to a concrete x.y.z version