changelog-generator
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.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- 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.
02 资源文件 1
- 参考文档agents/openai.yaml82 B
03 SKILL.md 正文
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
What This Skill Does
- Scans Git History: Analyzes commits from a specific time period or between versions
- Categorizes Changes: Groups commits into logical categories (features, improvements, bug fixes, breaking changes, security)
- Translates Technical → User-Friendly: Converts developer commits into customer language
- Formats Professionally: Creates clean, structured changelog entries
- Filters Noise: Excludes internal commits (refactoring, tests, etc.)
- Follows Best Practices: Applies changelog guidelines and your brand voice
How to Use
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
04 同仓库更多 Skills
user-run
Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable /home/orca/.tmp/<slug>/run.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: "I'll run it for you", "permission denied on docker.sock", "needs sudo", "sudo: a password is required", "run as tze", "/user-run".
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies