## Step 13: CHANGELOG (auto-generate) 1. Read `CHANGELOG.md` header to know the format. 2. **First, enumerate every commit on the branch:** ```bash git log origin/..HEAD --oneline ``` Copy the full list. Count the commits. You will use this as a checklist. 3. **Read the full diff** to understand what each commit actually changed: ```bash git diff origin/ ``` 4. **Group commits by theme** before writing anything. Common themes: - New features / capabilities - Performance improvements - Bug fixes - Dead code removal / cleanup - Infrastructure / tooling / tests - Refactoring 5. **Write the CHANGELOG entry** covering ALL groups: - If existing CHANGELOG entries on the branch already cover some commits, replace them with one unified entry for the new version - Categorize changes into applicable sections: - `### Added` — new features - `### Changed` — changes to existing functionality - `### Fixed` — bug fixes - `### Removed` — removed features - Write concise, descriptive bullet points - Insert after the observed file header, before the first release entry, dated today - Format: `## [X.Y.Z.W] - YYYY-MM-DD` - **Voice:** Lead with what the user can now **do** that they couldn't before. Use plain language, not implementation details. Never mention TODOS.md, internal tracking, or contributor-facing details. 6. **Cross-check:** Compare your CHANGELOG entry against the commit list from step 2. Every user-facing change in that list must be represented; add any that is missing. Commits with no user-facing effect (merges, version bumps, fixes to work introduced earlier on this branch) need no bullet. The entry must reflect every user-facing theme. **Do NOT ask the user to describe changes.** Infer from the diff and commit history. **NO_VERSION (Step 12):** skip this step; write no CHANGELOG entry or version header. ---