cli: Skill for Claude Code

Generate Release Changelog

Produce a tight, human-readable changelog for the latest published Git tag and print it as the final assistant message. This skill is read-only — do not write, edit, or create any files, directories, or git/GitHub objects at any point.

The product owner reads this to understand what changed for users, not what was implemented. Optimize for impact density: every bullet must answer "what is different now from a user's seat?". Cut anything that does not.

Hard constraints (non-negotiable)

• No file writes: do not use Write, Edit, Bash mkdir/touch, or any equivalent.
• No remote writes: do not run git commit, git tag, git push, or gh release create/edit.
• Output is a single chat message in Markdown. No preamble ("Here's your changelog:"), no follow-up questions, no commentary after the changelog ends.
• If the commit range is empty, print a single line: No commits found between <previous> and <latest>. and stop.

Step 1 — Resolve the tag range

Run in parallel:

git tag --sort=-creatordate | head -5
git describe --tags --abbrev=0

• latest = output of git describe --tags --abbrev=0.
• previous = the next tag in the sorted list. If no previous tag exists, use git rev-list --max-parents=0 HEAD | head -1 and note "initial release" in the changelog.
• If the user provides a tag argument, treat that as latest; derive previous from the sorted list.

Step 2 — Collect commits

git log <previous>..<latest> --no-merges --pretty=format:'%H%x09%s%x09%an'

For each commit, capture changed files:

git show --stat --pretty=format:'' <sha> | head -40

For commits with ambiguous subjects (e.g., chore: misc, wip, update), inspect the diff only for paths that look load-bearing — skip obvious docs: / chore: commits:

git show <sha> -- <relevant-paths>

Step 3 — Classify commits

Map every commit to exactly one bucket. Conventional Commit prefixes are a hint; the diff is authoritative — a chore: commit that ships user-visible behavior belongs in Features.