CHANGELOG Update
Purpose
Maintain a clear, searchable record of changes in CHANGELOG.md.
Trigger Conditions
- •Completing a new feature
- •Fixing a bug
- •Making breaking changes
- •Changing existing behavior
- •Removing functionality
Format
This project follows Keep a Changelog.
Section Types
| Section | Use When |
|---|---|
Added | New feature or capability |
Changed | Existing behavior modified |
Deprecated | Feature will be removed |
Removed | Feature was removed |
Fixed | Bug fix |
Security | Security vulnerability fix |
Writing Good Entries
Principles
- •Searchable: Include keywords users would search for
- •Concise: One line per change
- •User-focused: Describe the impact, not the implementation
- •Specific: Include variable names, type names, or config names
Good Examples
markdown
### Added
- Custom variable support with `{variable-name}` syntax (hyphens allowed)
- `Variables` type for typed variable definitions
### Changed
- `PromptManager.generatePrompt()` now validates all reserved variables before replacement
### Fixed
- Fixed `{destination_path}` replacement failing when path contains spaces
Bad Examples
markdown
# Too vague ### Added - New feature for templates # Too implementation-focused ### Changed - Refactored VariableReplacer to use async/await # Missing context ### Fixed - Fixed the bug
Process
- •Read current CHANGELOG.md (create if it doesn't exist)
- •Identify change category (Added/Changed/Fixed/etc.)
- •Write one-line entry:
<What>: <Impact> (\identifier`)` - •Place under
[Unreleased]section - •During release, move entries to
[x.y.z] - YYYY-MM-DD