Help us improve
Share bugs, ideas, or general feedback.
From slim-rebranding
Creates and maintains human-readable changelogs following Keep a Changelog standards. Useful for documenting releases, version history, and transparent communication.
npx claudepluginhub nasa-ammos/slim --plugin slim-changelogHow this skill is triggered — by the user, by Claude, or both
Slash command
/slim-rebranding:slim-changelogThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A changelog is a vital tool for documenting significant changes in software over time in a format accessible **to humans**. Unlike developer-oriented commit messages or GitHub's auto-generated release notes, changelogs focus on **feature changes** rather than code-level details, making them essential for transparency and user communication.
Generates CHANGELOG.md files in Keep a Changelog format with templates for Added, Changed, Deprecated, Removed, Fixed, and Security sections. Includes guidelines and examples for version history.
Automates changelog generation from commits, PRs, and releases following Keep a Changelog format. Use for release workflows, generating release notes, or standardizing commit conventions.
Generates or updates CHANGELOG.md from git history in Keep-a-Changelog format using parallel haiku subagents per version range.
Share bugs, ideas, or general feedback.
A changelog is a vital tool for documenting significant changes in software over time in a format accessible to humans. Unlike developer-oriented commit messages or GitHub's auto-generated release notes, changelogs focus on feature changes rather than code-level details, making them essential for transparency and user communication.
This skill helps you create and maintain professional CHANGELOG.md files following the Keep a Changelog standard, ensuring your project's evolution is clearly communicated to users, contributors, and stakeholders.
Q: Why maintain a CHANGELOG.md if GitHub has auto-generated release notes?
A: They are complementary tools serving different audiences:
Changelogs ensure:
Before implementing changelogs, discuss their importance with your team:
Copy the template:
cp assets/CHANGELOG.md CHANGELOG.md
Customize the header:
Add your first release entry:
[INSERT SEMANTIC VERSION...] with actual version (e.g., [1.0.0] - 2024-01-15)For each release, add a new section above previous releases:
## [1.1.0] - 2024-02-15
### Added
- New dashboard feature for user analytics
- Export functionality for reports
### Changed
- Improved performance of search queries
- Updated user interface design
### Fixed
- Fixed login issue with special characters
- Resolved memory leak in background processing
### Removed
- Deprecated legacy API endpoints
Link from README.md:
## Changelog
See [CHANGELOG.md](CHANGELOG.md) for a detailed history of changes.
Reference in release communications:
Use these categories consistently:
The provided CHANGELOG.md template includes:
[INSERT...] markers for easy customization[INSERT...] sections### Changed
- **BREAKING**: Authentication now requires API keys (see migration guide)
- Updated user permissions model
### Security
- Fixed XSS vulnerability in user input validation
- Updated dependencies to address security advisories
### Deprecated
- Legacy API endpoints (will be removed in v2.0.0)
- Old configuration format (use new YAML format)
CHANGELOG.md: Complete Keep a Changelog template with standard sections and placeholders for easy customizationQ: How often should I update the changelog? A: Update for every release, or maintain an "Unreleased" section for ongoing changes.
Q: What if I forgot to document changes in previous releases? A: You can retroactively add changelog entries, but mark them clearly as retrospective updates.
Q: Should I include every small change? A: Focus on user-facing changes. Minor bug fixes and internal refactoring may not need detailed changelog entries.
Q: How do I handle breaking changes? A: Mark them clearly with BREAKING labels and provide migration guidance or links to documentation.