changelog

Generate CHANGELOG.md

Analyze git history and produce a CHANGELOG.md following the Keep a Changelog format.

If $ARGUMENTS is provided, use it as the new version number (e.g. 1.2.0). Otherwise auto-detect from package.json or use Unreleased.

Step 1 — Detect Version

From $ARGUMENTS: Use as-is. Strip leading v if present for the version number, keep v for git tags.

Auto-detect: Read package.json → version field. If not found, use Unreleased.

Step 2 — Get Git Log

Run:

git tag --sort=-version:refname | head -1

to find the latest existing tag.

If a tag exists, run:

git log {latest-tag}..HEAD --pretty=format:"%H|%s|%an|%ad" --date=short

If no tags exist, run:

git log --pretty=format:"%H|%s|%an|%ad" --date=short

If git is not available or no commits exist, report and stop.

Step 3 — Parse and Classify Commits

For each commit line (hash|subject|author|date):

Parse Conventional Commits format (type(scope): subject):

Commit type	Changelog section
feat	Added
fix	Fixed
refactor, perf	Changed
style	Changed
docs	Changed
chore, test, ci	— (omit from changelog unless meaningful)
revert	Fixed
Breaking change (! or BREAKING CHANGE:)	⚠ Breaking

For non-conventional commits, classify by keywords in the subject:

• add, create, implement, new → Added
• fix, bug, patch, resolve, correct → Fixed
• update, change, improve, refactor, optimize → Changed
• remove, delete, drop, deprecate → Removed
• security, cve, vulnerability, auth → Security

Skip these commits:

• Merge commits (Merge branch, Merge pull request)
• WIP commits (wip, work in progress)
• Release commits that only bump version

Step 4 — Read Existing CHANGELOG.md

If CHANGELOG.md exists, read it.

The new version entry will be prepended before the existing entries, preserving all previous history.