changelog

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

1. Folder: _changelog/ at the project root (create it if it doesn't exist).
2. Filename: YYYY.MM.DD_changelog.md using dots, e.g. 2026.06.11_changelog.md (today's date).
3. If the file already exists (earlier session today), append a new session block under a --- divider — never overwrite earlier entries.
4. 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.