changelog-format

# Keep a Changelog Format

This skill provides guidelines for writing and formatting changelogs following the [Keep a Changelog](https://keepachangelog.com/) specification.

## Core Principles

1. **Changelogs are for humans** - Write for users, not machines
2. **Every version gets a section** - Including `[Unreleased]` for upcoming changes
3. **Changes are grouped by type** - Consistent categorization
4. **Versions are linkable** - Each version header links to comparison
5. **Latest version comes first** - Reverse chronological order
6. **Release dates are shown** - ISO format: YYYY-MM-DD

## Change Categories

Use these categories in this order:

| Category | Description | When to Use |
|----------|-------------|-------------|
| **Added** | New features | New functionality users can now do |
| **Changed** | Changes in existing functionality | Behavior modifications, improvements |
| **Deprecated** | Soon-to-be removed features | Features marked for future removal |
| **Removed** | Removed features | Features that no longer exist |
| **Fixed** | Bug fixes | Corrections to existing functionality |
| **Security** | Security vulnerability fixes | Security-related changes |

### Category Guidelines

**Added**
- New user-facing features
- New API endpoints
- New configuration options
- New integrations

**Changed**
- Performance improvements
- UX/UI changes
- Default value changes
- Behavior modifications

**Deprecated**
- Features planned for removal
- APIs being replaced
- Include migration path when possible

**Removed**
- Breaking changes (removed functionality)
- Deleted APIs or features
- Always note what replaced it (if applicable)

**Fixed**
- Bug corrections
- Error handling improvements
- Edge case fixes

**Security**
- Vulnerability patches
- Security-related fixes
- Always include CVE if available

## Entry Writing Guidelines

### Use Imperative Mood

Start entries with imperative verbs:

| Do | Don't |
|----|-------|
| Add support for... | Added support for