Changelog

Skill puukis/lstack/skills/changelog

A personal Claude Code environment. Persistent memory, loop detection, 15 skills, and lifecycle hooks. macOS, Linux, and Windows.

Install

npx -y skills add puukis/lstack --skill changelog

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generate a CHANGELOG.md entry from git log since last tag — invoked via /changelog

SKILL.md

2.2 KB, 508 tokens by cl100k_base, as published. Nobody here has run it

Changelog — generate changelog entry from git history

Activation

Invoked via /changelog. Use before any release or when CHANGELOG.md needs updating.

Process

Find the last git tag: Bash: git describe --tags --abbrev=0 2>/dev/null || echo "none"
Get commits since that tag (or all commits if no tag): Bash: git log --oneline --no-merges [last-tag]..HEAD 2>/dev/null If no tag: git log --oneline --no-merges | head -30
Read the existing CHANGELOG.md to understand the format.
Categorize the commits into: Added / Changed / Fixed / Removed / Security Use the commit message as the source of truth. Ignore: chore, docs, style, test commits unless they are significant. Keep each item to one line, past tense, user-facing language.
Determine the version number:
- If the user specified one, use it.
- Otherwise, read the latest version from CHANGELOG.md and suggest the next patch version (e.g. 1.0.0 → 1.0.1).
- Use AskUserQuestion to confirm the version: AskUserQuestion({ questions: [{ question: "Which version is this release?", header: "Version", multiSelect: false, options: [ { label: "[suggested patch]", description: "Increment patch version" }, { label: "[suggested minor]", description: "Increment minor version" }, { label: "[suggested major]", description: "Increment major version" }, { label: "I'll type it", description: "Provide a custom version string" } ] }] })
Write the new entry to CHANGELOG.md, inserting it after the

[Unreleased] section (or at the top if none exists).

Format: ## [X.Y.Z] - YYYY-MM-DD
```
### Added
- ...

### Fixed
- ...
```
Confirm: "CHANGELOG.md updated. Review it before tagging."

Constraints

Never invent changes not in git log.
Never include internal refactoring or test changes unless significant.
Never overwrite existing entries — only insert above them.
Max 15 items total per entry. Summarize if more.

Gives 1 of the 12 instructions most readme changelog skills give in 508 tokens

Counted across 471 of the 478 authors here whose files we hold, read 2026-08-06

follow the Keep a Changelog formatin 31 of 471, across 26 files
omit empty sectionsin 21 of 471
Run from the git repository rootin 20 of 471, across 7 files
save output directly to CHANGELOG.mdin 20 of 471, across 7 files
Group commits into logical categoriesin 19 of 471, across 6 files
Review the generated changelog before publishingin 19 of 471, across 6 files
Apply changelog guidelines and brand voicein 18 of 471, across 5 files
Exclude internal commits like refactoring and testsin 18 of 471, across 5 files
Specify date ranges for focused changelogsin 17 of 471, across 4 files
Convert technical commits into customer languagein 17 of 471, across 4 files
group commits by conventional commit typein 14 of 471
insert new entry below unreleased sectionhere, and in 14 of 471

Said here and by no other author read

ignore chore docs style test commits
summarize if more than 15 items

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.