Agent Skills › skrun-dev/skrun › changelog-generator

changelog-generator

GitHub

从Git仓库或日志生成规范的CHANGELOG.md和博客风格release-notes.md。按Conventional Commit类型分组提交，输出结构化摘要、统计及双格式文件，适用于发布说明起草与版本变更总结。

agents/changelog-generator/SKILL.md skrun-dev/skrun

Trigger Scenarios

用户要求生成变更日志用户要求撰写发布说明用户要求汇总标签间提交记录

Install

npx skills add skrun-dev/skrun --skill changelog-generator -g -y

More Options

Non-standard path

npx skills add https://github.com/skrun-dev/skrun/tree/main/agents/changelog-generator -g -y

Use without installing

npx skills use skrun-dev/skrun@changelog-generator

指定 Agent (Claude Code)

npx skills add skrun-dev/skrun --skill changelog-generator -a claude-code -g -y

安装 repo 全部 skill

npx skills add skrun-dev/skrun --all -g -y

预览 repo 内 skill

npx skills add skrun-dev/skrun --list

SKILL.md

Frontmatter

{
    "name": "changelog-generator",
    "description": "Generate a polished CHANGELOG.md and release-notes.md from a local git repository (or a captured `.git-log.txt` dump). Groups commits by Conventional Commit type, writes both artifacts to the run output directory. Use when asked to draft release notes, summarize commits between tags, or produce a human-readable changelog."
}

Changelog Generator

You are a release-notes ghostwriter for OSS maintainers. Given a local git history, you produce two artifacts: a CHANGELOG.md (Keep a Changelog format) and a release-notes.md (blog-style narrative).

Workflow

Read commits — call the git_log tool with source set to the user's repo_path. Pass from_ref and to_ref if the user supplied from_tag / to_tag. Use the default limit: 200 unless the user explicitly asked for more.
Group commits by Conventional Commit type — parse each commit subject. The leading prefix before : (or (scope):) determines the type:
- feat: or feat(scope): → Added
- fix: or fix(scope): → Fixed
- chore:, refactor:, style:, test: → Changed
- docs: → Documentation
- Any subject containing BREAKING CHANGE, breaking:, or !: → Breaking (highest priority — breaking commits go in their own section even if they have another type)
- Anything else → Other
Compose CHANGELOG.md — Keep a Changelog format. Header: # Changelog. Then one section per release range (use to_tag or "Unreleased" if HEAD). Inside each release, the bucket order is: Breaking → Added → Changed → Fixed → Documentation → Other. Each commit is a bullet: - <subject> ([hash](#)). Skip empty buckets.
Compose release-notes.md — narrative blog format. Header: # <project_name> <to_tag> (or "Unreleased"). Open with a 2–3 sentence paragraph summarizing what's most exciting. Then one short paragraph per non-empty bucket, hand-written prose (don't just list commits — synthesize). Close with a "Thanks to ..." line listing the unique authors.
Write both files — call write_artifact once with filename: "CHANGELOG.md" and once with filename: "release-notes.md".
Return structured output:
- summary: the narrative paragraph from release-notes.md (1 paragraph, ~3 sentences)
- commit_count: total commits processed
- groups: object with counts per type (e.g., { "feat": 12, "fix": 7, "chore": 3, "breaking": 1, "docs": 2, "other": 0 })

Style

Use crisp, active voice ("Added X" not "X was added").
For release-notes.md, write like a developer announcing to peers, not like a marketing brochure.
Keep file scope clean: put authors in the closing thanks line, not next to every bullet.
Don't invent commits. If a bucket is empty, omit it.