changelog-generator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Changelog Generator

变更日志生成工具

Tier: POWERFUL
Category: Engineering
Domain: Release Management / Documentation

层级: POWERFUL
分类: 工程
领域: 发布管理 / 文档

Overview

概述

Use this skill to produce consistent, auditable release notes from Conventional Commits. It separates commit parsing, semantic bump logic, and changelog rendering so teams can automate releases without losing editorial control.

使用此工具从Conventional Commits生成一致、可审计的发布说明。它将提交解析、语义版本升级逻辑和变更日志渲染分离，让团队可以在不失去编辑控制权的情况下自动化发布流程。

Core Capabilities

核心功能

Parse commit messages using Conventional Commit rules
Detect semantic bump (
```
major
```
,
```
minor
```
,
```
patch
```
) from commit stream
Render Keep a Changelog sections (
```
Added
```
,
```
Changed
```
,
```
Fixed
```
, etc.)
Generate release entries from git ranges or provided commit input
Enforce commit format with a dedicated linter script
Support CI integration via machine-readable JSON output

遵循Conventional Commit规则解析提交消息
从提交流中检测语义版本升级（
```
major
```
、
```
minor
```
、
```
patch
```
）
渲染符合Keep a Changelog规范的章节（
```
Added
```
、
```
Changed
```
、
```
Fixed
```
等）
从Git范围或提供的提交输入生成发布条目
通过专用的linter脚本强制提交格式规范
通过机器可读的JSON输出支持CI集成

When to Use

使用场景

Before publishing a release tag
During CI to generate release notes automatically
During PR checks to block invalid commit message formats
In monorepos where package changelogs require scoped filtering
When converting raw git history into user-facing notes

发布版本标签之前
在CI流程中自动生成发布说明
在PR检查中阻止无效的提交消息格式
在单体仓库（monorepos）中，需要按范围过滤包的变更日志时
将原始Git历史转换为面向用户的说明时

Key Workflows

关键工作流程

1. Generate Changelog Entry From Git

1. 从Git生成变更日志条目

bash

python3 scripts/generate_changelog.py \
  --from-tag v1.3.0 \
  --to-tag v1.4.0 \
  --next-version v1.4.0 \
  --format markdown

bash

python3 scripts/generate_changelog.py \
  --from-tag v1.3.0 \
  --to-tag v1.4.0 \
  --next-version v1.4.0 \
  --format markdown

2. Generate Entry From stdin/File Input

2. 从标准输入/文件输入生成条目

bash

git log v1.3.0..v1.4.0 --pretty=format:'%s' | \
  python3 scripts/generate_changelog.py --next-version v1.4.0 --format markdown

python3 scripts/generate_changelog.py --input commits.txt --next-version v1.4.0 --format json

bash

git log v1.3.0..v1.4.0 --pretty=format:'%s' | \
  python3 scripts/generate_changelog.py --next-version v1.4.0 --format markdown

python3 scripts/generate_changelog.py --input commits.txt --next-version v1.4.0 --format json

3. Update

CHANGELOG.md

3. 更新

CHANGELOG.md

bash

python3 scripts/generate_changelog.py \
  --from-tag v1.3.0 \
  --to-tag HEAD \
  --next-version v1.4.0 \
  --write CHANGELOG.md

bash

python3 scripts/generate_changelog.py \
  --from-tag v1.3.0 \
  --to-tag HEAD \
  --next-version v1.4.0 \
  --write CHANGELOG.md

4. Lint Commits Before Merge

4. 合并前检查提交格式

bash

python3 scripts/commit_linter.py --from-ref origin/main --to-ref HEAD --strict --format text

Or file/stdin:

bash

python3 scripts/commit_linter.py --input commits.txt --strict
cat commits.txt | python3 scripts/commit_linter.py --format json

bash

python3 scripts/commit_linter.py --from-ref origin/main --to-ref HEAD --strict --format text

或通过文件/标准输入：

bash

python3 scripts/commit_linter.py --input commits.txt --strict
cat commits.txt | python3 scripts/commit_linter.py --format json

Conventional Commit Rules

Conventional Commit规则

Supported types:

```
feat
```
,
```
fix
```
,
```
perf
```
,
```
refactor
```
,
```
docs
```
,
```
test
```
,
```
build
```
,
```
ci
```
,
```
chore
```
```
security
```
,
```
deprecated
```
,
```
remove
```

Breaking changes:

```
type(scope)!: summary
```
Footer/body includes
```
BREAKING CHANGE:
```

SemVer mapping:

breaking ->
```
major
```
non-breaking
```
feat
```
->
```
minor
```
all others ->
```
patch
```

支持的类型：

```
feat
```
,
```
fix
```
,
```
perf
```
,
```
refactor
```
,
```
docs
```
,
```
test
```
,
```
build
```
,
```
ci
```
,
```
chore
```
```
security
```
,
```
deprecated
```
,
```
remove
```

破坏性变更：

```
type(scope)!: summary
```
页脚/正文包含
```
BREAKING CHANGE:
```

SemVer映射：

破坏性变更 ->
```
major
```
非破坏性
```
feat
```
->
```
minor
```
所有其他类型 ->
```
patch
```

Script Interfaces

脚本接口

```
python3 scripts/generate_changelog.py --help
```
- Reads commits from git or stdin/
```
--input
```
- Renders markdown or JSON
- Optional in-place changelog prepend
```
python3 scripts/commit_linter.py --help
```
- Validates commit format
- Returns non-zero in
```
--strict
```
  mode on violations

```
python3 scripts/generate_changelog.py --help
```
- 从Git或标准输入/
```
--input
```
  读取提交记录
- 渲染markdown或JSON格式
- 可选地在变更日志开头追加内容
```
python3 scripts/commit_linter.py --help
```
- 验证提交格式
- 在
```
--strict
```
  模式下，若存在违规则返回非零状态码

Common Pitfalls

常见陷阱

Mixing merge commit messages with release commit parsing
Using vague commit summaries that cannot become release notes
Failing to include migration guidance for breaking changes
Treating docs/chore changes as user-facing features
Overwriting historical changelog sections instead of prepending

将合并提交消息与发布提交解析混合处理
使用模糊的提交摘要，无法直接作为发布说明
未为破坏性变更提供迁移指南
将文档/杂项变更视为面向用户的功能
覆盖历史变更日志章节而非在开头追加

Best Practices

最佳实践

Keep commits small and intent-driven.
Scope commit messages (
```
feat(api): ...
```
) in multi-package repos.
Enforce linter checks in PR pipelines.
Review generated markdown before publishing.
Tag releases only after changelog generation succeeds.
Keep an
```
[Unreleased]
```
section for manual curation when needed.

保持提交粒度小且目标明确。
在多包仓库中，为提交消息添加范围（
```
feat(api): ...
```
）。
在PR流水线中强制执行linter检查。
发布前审核生成的markdown内容。
仅在变更日志生成成功后再标记版本。
保留
```
[Unreleased]
```
章节，以便在需要时手动整理内容。

References

参考资料

references/ci-integration.md
references/changelog-formatting-guide.md
references/monorepo-strategy.md
README.md

references/ci-integration.md
references/changelog-formatting-guide.md
references/monorepo-strategy.md
README.md

Release Governance

发布管理流程

Use this release flow for predictability:

Lint commit history for target release range.
Generate changelog draft from commits.
Manually adjust wording for customer clarity.
Validate semver bump recommendation.
Tag release only after changelog is approved.

使用以下发布流程确保可预测性：

检查目标发布范围内的提交历史格式。
从提交记录生成变更日志草稿。
手动调整措辞以确保客户清晰理解。
验证语义版本升级建议。
仅在变更日志获批后再标记版本。

Output Quality Checks

输出质量检查

Each bullet is user-meaningful, not implementation noise.
Breaking changes include migration action.
Security fixes are isolated in
```
Security
```
section.
Sections with no entries are omitted.
Duplicate bullets across sections are removed.

每个项目符号都对用户有意义，而非实现细节。
破坏性变更包含迁移操作说明。
安全修复单独放在
```
Security
```
章节。
无内容的章节会被省略。
移除跨章节的重复项目符号。

CI Policy

CI策略

Run
```
commit_linter.py --strict
```
on all PRs.
Block merge on invalid conventional commits.
Auto-generate draft release notes on tag push.
Require human approval before writing into
```
CHANGELOG.md
```
on main branch.

在所有PR上运行
```
commit_linter.py --strict
```
。
若存在无效的Conventional Commits则阻止合并。
推送标签时自动生成发布说明草稿。
在主分支写入
```
CHANGELOG.md
```
前需要人工审批。

Monorepo Guidance

单体仓库指南

Prefer commit scopes aligned to package names.
Filter commit stream by scope for package-specific releases.
Keep infra-wide changes in root changelog.
Store package changelogs near package roots for ownership clarity.

优先使用与包名对齐的提交范围。
按范围过滤提交流以生成包专属的发布说明。
将基础设施层面的变更放在根目录变更日志中。
将包的变更日志存储在包根目录附近，以便明确归属。

Failure Handling

故障处理

If no valid conventional commits found: fail early, do not generate misleading empty notes.
If git range invalid: surface explicit range in error output.
If write target missing: create safe changelog header scaffolding.

若未找到有效的Conventional Commits：提前终止，不生成误导性的空说明。
若Git范围无效：在错误输出中明确显示范围。
若写入目标不存在：创建安全的变更日志头部框架。

changelog-generator

Original

Translation

Changelog Generator

变更日志生成工具

Overview

概述

Core Capabilities

核心功能

When to Use

使用场景

Key Workflows

关键工作流程

1. Generate Changelog Entry From Git

1. 从Git生成变更日志条目

2. Generate Entry From stdin/File Input

2. 从标准输入/文件输入生成条目

3. Update CHANGELOG.md

3. 更新CHANGELOG.md

4. Lint Commits Before Merge

4. 合并前检查提交格式

Conventional Commit Rules

Conventional Commit规则

Script Interfaces

脚本接口

Common Pitfalls

常见陷阱

Best Practices

最佳实践

References

参考资料

Release Governance

发布管理流程

Output Quality Checks

输出质量检查

CI Policy

CI策略

Monorepo Guidance

单体仓库指南

Failure Handling

故障处理

3. Update
`CHANGELOG.md`

3. 更新
`CHANGELOG.md`