Changelog Generator
Maintain a CHANGELOG.md that records what happened over time. Date-based entries, no versions, no semver, no boilerplate. Just content.
Structure
Entries are grouped by date. Each date is a section. Time progresses downward (newest at top). Within a date, use Added/Changed/Removed categories only when needed — skip empty ones.
# Changelog
## 2026-02-07
### Added
- ag:changelog skill — auto-maintains changelog from git + conversation context
### Changed
- Agent commands renamed from `ai:*` to `ag:*` prefix
## 2026-02-05
### Added
- cly bundle command — unified package management
No [Unreleased], no version numbers, no links to keepachangelog, no summary sections. Just dates and entries.
When to Auto-Invoke
Trigger automatically when:
- A new feature is added
- A feature is removed or deprecated
- Architecture changes
- A breaking change is introduced
Workflow
Step 1 — Determine Scope
git log --oneline --no-merges -20
git status --short
git diff --name-status
git diff --cached --name-status
- New commits since last changelog date: Add a new date entry (or update today's if it already exists)
- No new commits, just uncommitted changes: Update today's entry with current state
Step 2 — Gather What Changed
- Git commits since the last changelog date
- Uncommitted changes — include in today's entry
- Conversation context — decisions and rationale from the session
- Verify existence — for every entry, confirm the file/feature actually exists now. Don't document ghosts.
Step 3 — Reconcile
Read existing CHANGELOG.md before writing:
- Remove stale entries — if something listed as "Added" no longer exists, delete it
- Remove reversed changes — added then removed in same period = no entry
- Update descriptions — if behavior changed since logged, fix the description
- Deduplicate — multiple commits for one thing = one entry
- If today's date already exists — update it in place, don't create a duplicate
The changelog must be truthful. Every entry must reflect current reality.
Step 4 — Write
If no CHANGELOG.md exists, ask before creating.
Append/update entries. Present proposed changes to the user before applying.
Rules
- Date-based, not version-based — no semver, no
[Unreleased], just YYYY-MM-DD - Truthful — every entry must be verifiable against current codebase
- Remove when gone — deleted feature = delete its entry
- Update today, don't duplicate — if today already has an entry, update it
- No fluff — no boilerplate headers, no summary sections, no links, no preamble beyond
# Changelog - No trivial changes — skip typos, formatting, WIP commits
- Deduplicate — one feature = one entry regardless of commit count
- Concise — one line per change, rationale after dash if worth mentioning