From changelog
This skill should be used when the user asks to "update the changelog", "add to the changelog", "changelog for new release", "update CHANGELOG.md", or when the main changelog skill detects an existing CHANGELOG.md file. Appends new version entries by analyzing commits since the last documented version.
npx claudepluginhub florianbuetow/claude-code --plugin changelogThis skill uses the workspace's default tool permissions.
Update an existing `CHANGELOG.md` with new entries by analyzing commits since the last documented version. Follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) with [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Update an existing CHANGELOG.md with new entries by analyzing commits since the last documented version. Follows Keep a Changelog with Semantic Versioning.
Read CHANGELOG.md from the project root (case-insensitive: also check changelog.md, Changelog.md).
Parse to determine:
## [X.Y.Z] heading.[Unreleased] section? — Note its position and any existing bullets.The boundary commit is the last commit already documented in the changelog. Everything after it is new.
Strategy (try in order until one succeeds):
1.2.0) has a corresponding git tag (v1.2.0 or 1.2.0), use that tag as the boundary: git log <tag>..HEAD.## [1.2.0] – 2026-03-15) and find commits after that date: git log --after="2026-03-15".If none of these strategies produce a clear boundary, inform the user and ask which commit to start from.
Run these commands in parallel:
git tag --sort=-version:refname # All tags, newest first
git log --oneline --date=short --format="%h %ad %s" <boundary>..HEAD # Commits since boundary
git remote get-url origin 2>/dev/null # Remote URL for version links
Determine:
[Unreleased].For each new version range, classify commits into six categories:
| Category | Signals |
|---|---|
| Added | feat:, "add", "new", "introduce", "implement" |
| Changed | refactor:, "update", "change", "rename", "migrate", "improve" |
| Deprecated | deprecate:, "sunset" |
| Removed | remove:, "drop", "delete", "strip" |
| Fixed | fix:, "bug", "patch", "resolve", "correct" |
| Security | security:, "CVE", "vulnerability" |
Skip merge commits — Merge commits (e.g., "Merge branch ...", "Merge pull request ...") duplicate the merged commits.
Omit commits that are purely internal (CI/CD, docs-only, trivial chores) unless user-facing.
Prefix priority — When a conventional commit prefix is present (e.g., feat:, fix:), use it to determine the category. Only fall back to keyword matching when no recognized prefix exists.
Synthesize, do not copy — Group related commits into single user-facing bullet points. Write short, specific, past-tense descriptions focused on what the user sees or feels.
Consult ../changelog/references/format-guide.md for formatting rules.
Insertion rules:
## [Unreleased] (or below the header/intro if no Unreleased section exists)[Unreleased] bullets and add a fresh empty [Unreleased] section above the new version[Unreleased] section, merging with any existing bullets thereUse ISO date format (YYYY-MM-DD). Only include category headings that have entries.
Show only the new section(s) that were added, not the entire file.
**BREAKING:**, describe impact, provide migration path.../changelog/references/format-guide.md — Complete format spec, template, style rules, antipatterns, breaking change handling