changelog-from-commits
communityGenerate a user-facing CHANGELOG entry from raw git log output. Use when the user is preparing a release, says "what changed since last version", asks to write release notes, or wants to summarize a batch of commits for end users.
>_rockscy/solo-skills/skills/changelog-from-commits·commit 3472e5d
name: changelog-from-commits description: Generate a user-facing CHANGELOG entry from raw git log output. Use when the user is preparing a release, says "what changed since last version", asks to write release notes, or wants to summarize a batch of commits for end users.
Changelog from Commits / 提交转更新日志
When to use
- The user is cutting a release and needs user-facing release notes.
- There is a clear range: a tag, a date, or a commit SHA to diff from.
- The audience is users, not contributors (Conventional Commits already exists for the latter).
When NOT to use
- The repo has no user-facing surface (internal libraries, scripts) — a commit log is fine.
- The range covers months of work. Break it into smaller releases first.
- The user wants a marketing post — that's launch-tweet, not a changelog.
Approach
- Get the raw commit list:
git log <prev-tag>..HEAD --pretty=format:"%h %s%n%b" --no-merges - Group commits into three buckets, in this order:
- Added — net-new user-visible capability.
- Changed / Fixed — behavior that users would notice.
- Internal — refactors, deps, docs (collapse into a single line at the bottom).
- Translate from dev-speak to user-speak.
- ❌ "refactor: extract validation middleware"
- ✅ (skip — internal)
- ❌ "fix: handle null in payment.processor"
- ✅ "Fixed a crash when applying coupons to gift cards."
- Drop noise. Typo fixes, README tweaks, CI tweaks, version bumps → cut.
- Each bullet is one sentence, past tense, user perspective.
- If a bullet needs more than one sentence, it deserves its own blog post — link out.
Output format
## v<version> — YYYY-MM-DD
### Added
- <bullet>
### Changed
- <bullet>
### Fixed
- <bullet>
### Internal
- <one-line summary>: deps bumped, tests added, docs polished.
Skip empty sections entirely.
Worked example
Input commits:
a1b2c3d feat: add CSV export to reports
e4f5g6h fix: correct rounding in monthly totals
1a2b3c4 chore: bump axios to 1.7.5
9z8y7x6 refactor: split UserService
5d4c3b2 docs: fix typo in README
abcdef0 feat: dark mode toggle
Output:
## v1.4.0 — 2026-04-30
### Added
- CSV export for any report — find it in the report toolbar.
- Dark mode toggle in Settings → Appearance.
### Fixed
- Monthly totals now round consistently with daily totals (off-by-1¢ on edge cases).
### Internal
- Dependency updates and a service refactor; no user impact expected.
Hard rules
- Past tense. "Added X", not "Adds X".
- One bullet, one sentence. If you need a second sentence, you're explaining implementation.
- Link to docs/blog if a feature needs context. Don't inline tutorials.
中文版
何时使用
- 用户在发布版本,需要面向用户的更新说明。
- 有明确的范围(上个 tag、某个日期、某个 SHA)。
- 受众是用户,不是贡献者(Conventional Commits 给后者用)。
何时不使用
- 仓库无用户访问面(内部库 / 脚本),commit 日志够了。
- 范围跨度几个月——先拆成小版本。
- 用户其实想要营销稿——那是 launch-tweet 的活。
步骤
- 拿提交列表:
git log <prev-tag>..HEAD --pretty=format:"%h %s%n%b" --no-merges - 分三组:
- 新增(Added)——新功能。
- 变更/修复(Changed/Fixed)——用户能感知的行为变化。
- 内部(Internal)——重构、依赖、文档——折叠成一行。
- 翻译成用户能懂的话。
- 过滤噪声:错别字、CI 调整、版本号 bump → 删掉。
- 每条一句话,过去时,从用户视角写。
硬规则
- 过去时。
- 一条一句。需要两句说明你在解释实现细节,删掉。
- 复杂功能链接到博客或文档,不要在 changelog 里写教程。