From slim-rebranding
Creates and maintains human-readable CHANGELOG.md files for software projects using Keep a Changelog standards. Useful for documenting releases, version history, and changes for users and contributors.
npx claudepluginhub nasa-ammos/slim --plugin slim-rebrandingThis skill uses the workspace's default tool permissions.
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.
Implements structured self-debugging workflow for AI agent failures: capture errors, diagnose patterns like loops or context overflow, apply contained recoveries, and generate introspection reports.
Monitors deployed URLs for regressions in HTTP status, console errors, performance metrics, content, network, and APIs after deploys, merges, or upgrades.
Provides React and Next.js patterns for component composition, compound components, state management, data fetching, performance optimization, forms, routing, and accessible UIs.
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.