changelog-generator

name	changelog-generator
description	Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
hints	["Check existing project files for CHANGELOG.md patterns and formats if available.","Exclude developer-only noise (e.g. chore, simple refactoring, config updates) from user-facing logs.",{"Group additions into cohesive, standard categories":"Features, Improvements, Bug Fixes, Breaking Changes, Security."},"Translate technical implementation terms (e.g., class names, SQL keys) into user-facing benefits and actions.","Highlight breaking changes or required migration steps prominently at the top of the changelog notes."]

Changelog Generator

This skill transforms technical git commits into polished, user-friendly changelogs that your customers and users will actually understand and appreciate.

When to Use This Skill

• Preparing release notes for a new version
• Creating weekly or monthly product update summaries
• Documenting changes for customers
• Writing changelog entries for app store submissions
• Generating update notifications
• Creating internal release documentation
• Maintaining a public changelog/product updates page

Overview

1. Scans Git History: Analyzes commits from a specific time period or between versions
2. Categorizes Changes: Groups commits into logical categories (features, improvements, bug fixes, breaking changes, security)
3. Translates Technical → User-Friendly: Converts developer commits into customer language
4. Formats Professionally: Creates clean, structured changelog entries
5. Filters Noise: Excludes internal commits (refactoring, tests, etc.)
6. Follows Best Practices: Applies changelog guidelines and your brand voice

Workflow

1. Identify release scope (version range, commit range, or date range).
2. Gather relevant commits and exclude maintenance noise.
3. Group changes into user-facing categories.
4. Rewrite each item in plain customer language.
5. Format output as publish-ready markdown and verify clarity.

Usage

Basic Usage

From your project repository:

Create a changelog from commits since last release

Generate changelog for all commits from the past week

Create release notes for version 2.5.0

With Specific Date Range

Create a changelog for all commits between March 1 and March 15

With Custom Guidelines

Create a changelog for commits since v2.4.0, using my changelog 
guidelines from CHANGELOG_STYLE.md

Example

User: "Create a changelog for commits from the past 7 days"

Output:

# Updates - Week of March 10, 2024

## ✨ New Features

- **Team Workspaces**: Create separate workspaces for different 
  projects. Invite team members and keep everything organized.

- **Keyboard Shortcuts**: Press ? to see all available shortcuts. 
  Navigate faster without touching your mouse.

## 🔧 Improvements

- **Faster Sync**: Files now sync 2x faster across devices
- **Better Search**: Search now includes file contents, not just titles

## 🐛 Fixes

- Fixed issue where large images wouldn't upload
- Resolved timezone confusion in scheduled posts
- Corrected notification badge count

Inspired by: Manik Aggarwal's use case from Lenny's Newsletter

Tips

• Run from your git repository root
• Specify date ranges for focused changelogs
• Use your CHANGELOG_STYLE.md for consistent formatting
• Review and adjust the generated changelog before publishing
• Save output directly to CHANGELOG.md

Related Use Cases

• Creating GitHub release notes
• Writing app store update descriptions
• Generating email updates for users
• Creating social media announcement posts

Common Rationalizations

Rationalization	Reality
I'll just dump raw commit logs directly.	Raw commits contain internal technical jargon (e.g. refactor: fix database constraints) that confuses users.
No one reads changelogs, so formatting doesn't matter.	Well-structured changelogs demonstrate project health, building trust with users and stakeholders.

Red Flags

• Including chore commits (chore: update eslint) or test commits in user-facing release notes.
• Highlighting internal module names or database parameters instead of functional product capabilities.
• Obfuscating or hiding major breaking changes in fine print.

Verification

After completing the skill, confirm:

• Technical jargon is completely rewritten to represent user-facing value and utility.
• Internal/engineering noise (tests, configs, refactors) is filtered out.
• Markdown formatting is verified clean, readable, and properly categorized.