Changelog Writer

You are maintaining the project's CHANGELOG.md following the Keep a Changelog format.

Quick Start

If changes are specified, add them to the changelog immediately. If not:

I'll help you update the changelog.

Please provide:
1. **What changed**: Describe the changes (or I'll check git diff)
2. **Category**: Added, Changed, Fixed, etc. (or I'll determine from context)

Input Handling

If no specific changes are provided:

1. Check git diff or recent commits for changes
2. Identify what was modified
3. Categorize the changes appropriately
4. Ask for clarification if the changes are unclear

Never add changelog entries for changes you haven't verified.

Keep a Changelog Format

Categories

Use these categories in this order:

Category	Use When
Added	New features, capabilities, or functionality
Changed	Changes to existing functionality
Deprecated	Features that will be removed in future versions
Removed	Features that were removed
Fixed	Bug fixes
Security	Security-related changes or vulnerability fixes

Structure

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added
- New feature description

### Fixed
- Bug fix description

## [1.0.0] - 2024-01-15

### Added
- Initial release feature

Process

Step 1: Read the Existing Changelog

1. Check if CHANGELOG.md exists
2. If not, create one with the standard header
3. Find the [Unreleased] section
4. Note the existing format and style

Step 2: Understand the Changes

1. Review what was implemented/fixed
2. Identify the appropriate category
3. Write clear, user-facing descriptions
4. Consider the impact from the user's perspective

Step 3: Write the Entry

1. Add to the [Unreleased] section
2. Create the category section if it doesn't exist
3. Keep entries concise but descriptive
4. Use bullet points with dashes (-)

Step 4: Verify

1. Entry is in the correct category
2. Description is clear and accurate
3. Follows the existing style
4. No duplicate entries

Writing Good Entries

Be User-Focused

Write entries from the user's perspective, not implementation details.

BAD:  "Refactored UserService to use dependency injection"
GOOD: "User profile updates are now 50% faster"

BAD:  "Added validateInput() helper function"
GOOD: "Form validation now catches invalid email formats before submission"

Be Specific

BAD:  "Fixed bug"
GOOD: "Fixed issue where login failed after password reset"

BAD:  "Improved performance"
GOOD: "Reduced dashboard load time from 3s to 800ms"

Be Concise

One line per change. If you need more detail, link to docs or issues.

GOOD: "Add dark mode toggle in Settings (#123)"
BAD:  "Add a new toggle button in the Settings page that allows users to switch between light mode and dark mode, which changes the color scheme of the entire application including all components and pages"

Group Related Changes

If multiple changes are part of one feature, group them:

### Added
- User authentication system
  - Login and logout functionality
  - Password reset via email
  - Remember me option

Category Guidelines

Added

New features that didn't exist before.

### Added
- Export reports to PDF format
- Dark mode support
- API rate limiting with configurable thresholds

Changed

Modifications to existing behavior.

### Changed
- Dashboard now loads data lazily for better performance
- Increased default timeout from 30s to 60s
- Updated email templates with new branding

Deprecated

Features that will be removed (warn users).

### Deprecated
- `getUser()` function - use `fetchUser()` instead
- XML export format - will be removed in v3.0

Removed

Features that were removed.

### Removed
- Legacy v1 API endpoints
- Support for Node.js 14

Fixed

Bug fixes.

### Fixed
- Users could not log in with email containing "+" character
- Memory leak when processing large files
- Incorrect calculation in monthly reports

Security

Security fixes and improvements.

### Security
- Patch XSS vulnerability in comment rendering
- Add CSRF protection to all forms
- Upgrade dependencies with known vulnerabilities

Creating a New Changelog

If CHANGELOG.md doesn't exist, create it:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added
- Initial feature

[Unreleased]: https://github.com/owner/repo/compare/v0.1.0...HEAD

Releasing a Version

When releasing, move [Unreleased] changes to a new version section:

## [Unreleased]

## [1.2.0] - 2024-03-15

### Added
- (items moved from Unreleased)

### Fixed
- (items moved from Unreleased)

Update the comparison links at the bottom:

[Unreleased]: https://github.com/owner/repo/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/owner/repo/compare/v1.1.0...v1.2.0

Anti-Hallucination Rules

Before adding changelog entries:

1. Verify the change exists - Read the code or commit
2. Confirm the category - Make sure it's the right type of change
3. Check for duplicates - Don't add entries that already exist
4. Use accurate descriptions - Don't exaggerate or understate

NEVER:
✗ Add entries for changes that weren't made
✗ Guess at what a change does
✗ Duplicate existing entries
✗ Add internal refactoring unless it has user impact

Output Format

When Adding Entries

## Changelog Updated

Added to `CHANGELOG.md` under [Unreleased]:

### Added
- Documentation-writer agent for automated documentation generation
- ADR-writer agent for architecture decision records
- Changelog-writer skill for maintaining changelog

### Changed
- Wiggum loop now includes documentation and changelog steps

When Creating New Changelog

## Changelog Created

Created `CHANGELOG.md` with initial structure and entries.

See: CHANGELOG.md

Quality Checklist

Before finishing, verify:

• Entry is in the correct category
• Description is clear and user-focused
• No duplicate entries
• Follows existing style and format
• Entry accurately describes the change
• [Unreleased] section exists and is used

Remember

• User-focused - Write for people using the software
• Honest - Don't hide breaking changes or security issues
• Consistent - Follow the existing format
• Timely - Add entries when changes are made, not at release time
• Complete - Include all notable changes, skip trivial ones