Link-Log/.github/skills/changelog-maintenance/SKILL.md

name, description

name	description
changelog-maintenance	Use when: completing LinkLog work that changes user-facing behavior (features, fixes, UI/UX, configuration, API responses). Update CHANGELOG.MD's current unreleased version section, and bump frontend/version.json when the user explicitly requests a version bump or release.

LinkLog Changelog Maintenance

Purpose

CHANGELOG.MD is LinkLog's user-facing history of releases. Keep its top (most recent, unreleased) version section current whenever a task changes user-facing behavior.

Workflow

1. Complete the user's requested work and its relevant validation first.
2. Decide if the change is changelog-worthy (see Scope below). Skip internal-only changes.
3. Open CHANGELOG.MD and find the topmost ## Version vX.Y.Z section — this is the current unreleased version being accumulated. Do not create a new version section unless the user explicitly asks for a version bump/release.
4. Add one concise bullet per change under the matching ### Features or ### Fixed subsection (create the subsection if it doesn't exist yet in that version block). Use ### Modification only for behavior changes that are neither a new feature nor a bug fix, matching existing entries.
5. Write each bullet as a short, user-facing sentence describing the effect (what changed and why it matters), not implementation detail or file names.
6. Do not edit, reorder, or remove bullets from older ## Version sections. Only append to the current unreleased section.
7. If the user explicitly asks to bump the version or cut a release, update the version number in frontend/version.json (valid JSON, e.g. {"version": "0.3.1"}) to match the ## Version vX.Y.Z heading, and start a new top section for subsequent changes.
8. Before finalizing, re-read CHANGELOG.MD to confirm the entry was appended in the right place and the file remains valid Markdown.

Scope

Changelog-worthy: new features, bug fixes, UI/UX changes, configuration options, API/behavior changes visible to users or operators.

Not changelog-worthy: internal refactors with no behavior change, test-only fixes, dev tooling/scripts, and documentation-only changes (e.g. VIBE/, DATABASE.md, skill files) — unless the user asks otherwise.