Turn a list of changes, commits, or PRs into clean release notes / a changelog entry. Use when asked to write release notes, a changelog, or a version announ...
文档
Changelog Generator
试用Convert a git log, commit list, or release notes into a polished, user-facing changelog. Use when writing release notes, generating a CHANGELOG.md entry, or...
它能做什么
Convert a git log, commit list, or release notes into a polished, user-facing changelog. Use when writing release notes, generating a CHANGELOG.md entry, or documenting what changed in a version. Produces a structured changelog section with version header, categorised changes, and migration notes. For an already-curated change list use changelog-writer instead.
技能文档
Changelog Generator Skill
Converts raw git commits, a diff summary, or developer release notes into a polished changelog entry — categorised, user-facing, and following Keep a Changelog conventions.
Required Inputs
Ask for these if not provided:
- Commits or release notes (paste
git log --oneline, raw commit messages, or a description of what changed) - Version number (e.g. 2.4.0, v1.0.0-beta.2)
- Release date (or "today")
- Audience (developers using an API / end users of a product / internal team — affects language)
- Any breaking changes (flag these explicitly if known)
- Previous version behaviour (optional — paste the previous changelog entry or describe what is changing; needed for accurate "Changed" entries)
- Scope (whole product / specific package or module — e.g. "payments SDK only", "iOS app", "all services")
Output Format
Follow Keep a Changelog format:
[X.Y.Z] — YYYY-MM-DD
Breaking Changes ⚠️
[Only include if there are breaking changes]
- [Breaking change]: [What changed and what it breaks]
- Migration required: [Specific action the user must take]
Added
- [New feature or capability, written from the user's perspective]
- [Another addition]
Changed
- [Changed behaviour — what it did before vs. what it does now]
- [Performance improvement with measurable impact if known]
Fixed
- [Bug fixed — describe what was broken, not the fix implementation]
- [Another fix]
Deprecated
- [Deprecated thing] — use [replacement] instead. Will be removed in [version].
Removed
- [Removed thing] — was deprecated in [version]
Security
- [Security fix — describe the vulnerability class, not exploit details]
Skill guidance — do not include the following section in the delivered changelog:
Formatting Rules Applied
Language: Write for the reader, not the committer. "Add dark mode support" not "implement ThemeProvider with dark palette variant".
Breaking changes: Always call these out first with ⚠️. Include a migration path.
Bug fixes: Describe what was broken, not what was changed. "Fix crash when user has no profile picture" not "null-check avatar URL before rendering".
Granularity: Group related commits into one line. Don't list every micro-commit separately.
Tone: Active voice, imperative mood. "Add", "Fix", "Remove" — not "Added", "Fixed", "Removed".
Empty sections: Omit any section with no entries. Don't include empty ### Fixed blocks.
Scoring Rubric (0–40)
Score any output of this skill before handing it over; 32+ is ship-quality.
| Dimension | 0 | 5 | 10 |
|---|---|---|---|
| Reader-facing translation | Entries restate commit messages, with internal identifiers and implementation details | Mostly user-facing, but a few entries leak internals or describe the patch rather than what was broken | Every entry describes the change from the reader's perspective — what changed for them, never how the code was refactored |
| Breaking-change handling | Breaking changes buried mid-list or missing a migration path | Flagged at the top, but migration guidance is vague ("update your code") | At the top with ⚠️, each with a specific migration action the user can execute |
| Curation & grouping | Every micro-commit listed; internal-only commits included | Some grouping, but related commits still appear as separate entries or noise slips through | Related commits grouped into single entries; internal-only commits excluded; nothing a user can't observe |
| Format discipline | Wrong or missing version/date header; past-tense verbs; empty sections left in | Header correct but tense or empty-section slips remain | Keep a Changelog conventions throughout — correct header, imperative mood, only populated sections |
Quality Checks
- Breaking changes are at the top with migration instructions
- All entries are user-facing language (no internal variable names or implementation details)
- Related commits are grouped into single entries (not listed individually)
- Version and date header is correct
- Empty sections are omitted
- No entries start with past-tense verbs (no "Added", "Fixed", "Removed" — use "Add", "Fix", "Remove")
- Every breaking change entry includes a specific migration action (not just "update your code")
Anti-Patterns
- Do not include implementation details in changelog entries — users need to know what changed for them, not how the code was refactored internally
- Do not list every micro-commit as a separate entry — related commits should be grouped into one user-facing change
- Do not omit the migration path for breaking changes — a breaking change entry without a specific migration action forces users to read the source code
- Do not include empty sections — a "### Fixed" section with no entries signals the template was filled in carelessly
- Do not write breaking changes in the same casual tone as minor additions — breaking changes must be visually prominent and call out migration requirements explicitly
Usage Examples
- "Write a changelog for version [X]" + [paste commits]
- "Generate release notes from these commits"
- "Turn this git log into a CHANGELOG entry"
- "Write the CHANGELOG.md update for this release"
- "What changed in this release?" + [paste commit list]
相关技能
Generate polished changelogs and release notes from git history, PRs, and issues — auto-categorize features, fixes, and breaking changes
4 次安装
Generate and update table-of-contents (TOC) sections for Markdown files. Use when working with long Markdown documents, READMEs, or technical docs that need a navigable TOC, or when asked to add/update a table of contents in a .md file.
1 次安装
Generate structured summaries of recent git commit activity. Use when the user asks for a commit summary, changelog draft, standup notes from git, or to understand what changed in a repo over a time range. Supports filtering by author, date range, and output format.
1 次安装
Generate a compact weekly changelog from a git repository, grouped by author and day, without any dependencies. Use when you need a one-page summary of the last 7 days (or custom window) of commits for a report, standup, or release notes.
Maintain CHANGELOG.md in Keep a Changelog 1.1.0 format. Use when the user asks to create a changelog, record recent changes or draft release notes, cut or tag a release, or audit an existing changelog — and before editing any CHANGELOG.md for another reason.