Write Changelog

Creates a clear, categorized changelog for your project, following Keep a Changelog and semantic versioning standards. No formatting or HTML.

How to use

Replace {{args}} with your list of changes, features, or bug fixes to generate a structured changelog for your repository or release.

Prompt

Generate Changelog

Please create a comprehensive changelog for the following changes:

{{args}}

Format

Follow the Keep a Changelog standard:

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.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added
- New features that have been added

### Changed
- Changes in existing functionality

### Deprecated
- Soon-to-be removed features

### Removed
- Now removed features

### Fixed
- Any bug fixes

### Security
- Vulnerabilities fixed

## [1.0.0] - 2024-01-15

### Added
- Initial release
- Feature X
- Feature Y

[Unreleased]: https://github.com/user/repo/compare/v1.0.0...HEAD
[1.0.0]: https://github.com/user/repo/releases/tag/v1.0.0

Categories

Use these standard categories:

Added

  • New features
  • New functionality
  • New capabilities

Changed

  • Changes to existing functionality
  • Performance improvements
  • Refactoring

Deprecated

  • Features that will be removed in future versions
  • APIs marked for deprecation

Removed

  • Features removed
  • APIs removed
  • Support dropped

Fixed

  • Bug fixes
  • Issue resolutions
  • Patches

Security

  • Security vulnerability fixes
  • Security improvements
  • CVE addresses

Guidelines

  1. Version Numbers: Use semantic versioning (MAJOR.MINOR.PATCH)

    • MAJOR: Breaking changes
    • MINOR: New features (backward compatible)
    • PATCH: Bug fixes (backward compatible)
  2. Dates: Use ISO format (YYYY-MM-DD)

  3. Grouping: Group changes by category

  4. Links: Link to relevant issues, PRs, or commits

  5. Clarity: Write for users, not developers

    • Focus on impact, not implementation
    • Use past tense
    • Be concise but clear
  6. Breaking Changes: Highlight these prominently

  7. Contributors: Credit contributors where appropriate

Examples

Good Entry:

### Added
- User authentication with OAuth 2.0 support (#123)
- Export data to CSV functionality (#145)

Bad Entry:

### Added
- Fixed the thing
- Updated stuff

Additional Sections (optional)

Migration Guide

For breaking changes, provide migration instructions:

### Migration from v1.x to v2.x

**Breaking Changes**:
- Function `oldFunction()` renamed to `newFunction()`
- Parameter order changed in `someMethod()`

**How to Update**:
1. Replace all instances of `oldFunction()` with `newFunction()`
2. Update method calls to match new signature

Known Issues

Document known issues for the release:

### Known Issues
- Safari browser has rendering issues with feature X (#234)
- Memory leak in long-running processes (#245) - workaround available

Generate a complete, well-organized changelog following these standards.