| name | changelog |
| description | Daily changelog habit. Use when the user asks to log/record today's work, write a changelog, or wrap up the day — and proactively offer it after a substantial work session. Writes a per-day markdown entry in the project's _changelog folder named YYYY.MM.DD_changelog.md, appending if the file already exists. |
Daily changelog
Record what changed in the project today, one file per day, so the project's
history is readable without digging through chat transcripts or diffs.
File rules
- Folder:
_changelog/ at the project root (create it if it doesn't exist).
- Filename:
YYYY.MM.DD_changelog.md using dots, e.g. 2026.06.11_changelog.md (today's date).
- If the file already exists (earlier session today), append a new session
block under a
--- divider — never overwrite earlier entries.
- Entries describe what changed and why it matters, not a play-by-play of the
conversation. Reference files as relative repo paths.
Entry format
# Changelog — 2026.06.11
## Session: <short description of the session's goal> (HH:MM)
### Added
- <new capability / file> — one line on what it does. (`path/to/file`)
### Changed
- <behavior change> — what's different for the user/system. (`path`)
### Fixed
- <bug> — symptom → cause → fix in one line. (`path`)
### Security
- <finding or hardening> — only when applicable.
### Database
- <proc/schema changes> — note whether executed or proposed-only. Only when applicable.
### Docs
- <docs written/updated> — only when applicable.
### Open / next
- <unfinished thread or decision needed> — keep to real follow-ups.
Writing rules
- Omit empty sections; never pad.
- Lead each bullet with the noun that changed, not "I" or "Claude".
- One line per item; two only when the why is non-obvious.
- Note proposed vs executed for anything irreversible (DB scripts, deploys).
- If multiple projects were touched in one session, write a changelog in each
project's own
_changelog/ folder covering only that project's changes.
