changelog-generator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Changelog Generator

变更日志生成器

Automated changelog generation following semantic versioning (SemVer) and Keep a Changelog standards. This skill guides agents through reviewing staged changes, determining appropriate version bumps, and updating both

@package.json

and

@CHANGELOG.md

files consistently.

遵循语义化版本控制（SemVer）和Keep a Changelog规范的自动变更日志生成工具。该技能可引导Agent完成暂存变更的审查、确定合适的版本升级幅度，并同步更新

@package.json

和

@CHANGELOG.md

文件。

Overview

概述

The Changelog Generator skill automates the process of:

Analyzing staged git changes to determine change types
Calculating appropriate semantic version bumps (MAJOR.MINOR.PATCH)
Updating the version in
```
@package.json
```
Generating properly formatted changelog entries in
```
@CHANGELOG.md
```
Ensuring consistency between version numbers and changelog entries

This skill follows the Semantic Versioning 2.0.0 specification and the Keep a Changelog format standards.

变更日志生成器技能可自动完成以下流程：

分析Git暂存变更以确定变更类型
计算符合语义化版本规范的升级幅度（MAJOR.MINOR.PATCH）
更新
```
@package.json
```
中的版本号
在
```
@CHANGELOG.md
```
中生成格式规范的变更日志条目
确保版本号与变更日志条目保持一致

本技能遵循语义化版本控制2.0.0规范和Keep a Changelog格式标准。

When to Apply

适用场景

Reference this skill when:

User requests to "update changelog" or "generate changelog"
User asks to "bump version" or "create release"
Preparing for a new release
Need to document changes in a standardized format
Ensuring version numbers follow semantic versioning
Maintaining consistent changelog formatting

Preconditions:

Git repository with staged changes
Existing
```
@package.json
```
file with a
```
version
```
field
Existing
```
@CHANGELOG.md
```
file following Keep a Changelog format
Access to git commands (
```
git diff
```
,
```
git status
```
)

在以下场景中使用本技能：

用户请求“更新变更日志”或“生成变更日志”
用户要求“升级版本号”或“创建发布版本”
准备新版本发布时
需要以标准化格式记录变更时
确保版本号遵循语义化版本控制规范时
保持变更日志格式一致性时

前置条件：

包含暂存变更的Git仓库
已存在带有
```
version
```
字段的
```
@package.json
```
文件
已存在遵循Keep a Changelog格式的
```
@CHANGELOG.md
```
文件
可访问Git命令（
```
git diff
```
、
```
git status
```
）

Workflow

工作流程

The changelog generation process follows these 7 steps:

变更日志生成流程分为以下7个步骤：

Step 1: Review All Staged Changes

步骤1：审查所有暂存变更

Objective: Understand what changes have been staged and categorize them.

Actions:

Check git status to see what's staged:
bash
```
git status
```
Review all staged changes:
bash
```
git diff --cached
```
Analyze the changes to identify:
- Breaking changes: API changes, removed features, incompatible changes
- New features: Added functionality, new APIs, new components
- Bug fixes: Fixes to existing functionality
- Documentation: README updates, doc changes (usually don't affect version)
- Refactoring: Code improvements without behavior changes (usually PATCH)
Review commit messages if available:
bash
```
git log --oneline --cached
```

Categorization Guidelines:

Breaking changes → MAJOR version bump
New features → MINOR version bump
Bug fixes → PATCH version bump
Documentation only → Usually no version bump (or PATCH if significant)
Refactoring → Usually PATCH version bump

Output: List of categorized changes ready for changelog entry.

目标： 了解已暂存的变更内容并进行分类。

操作：

查看Git状态以了解暂存内容：
bash
```
git status
```
查看所有暂存变更：
bash
```
git diff --cached
```
分析变更以识别：
- 破坏性变更：API变更、功能移除、不兼容变更
- 新功能：新增功能、新API、新组件
- Bug修复：对现有功能的修复
- 文档更新：README更新、文档变更（通常不影响版本号）
- 代码重构：不改变功能的代码优化（通常对应PATCH版本升级）
（若有）查看提交信息：
bash
```
git log --oneline --cached
```

分类指南：

破坏性变更 → MAJOR版本升级
新功能 → MINOR版本升级
Bug修复 → PATCH版本升级
仅文档更新 → 通常不升级版本号（若变更重大可升级PATCH版本）
代码重构 → 通常升级PATCH版本

输出： 已分类的变更列表，可用于生成变更日志条目。

Step 2: Determine the Appropriate Version Bump

步骤2：确定合适的版本升级幅度

Objective: Calculate the new version number based on semantic versioning rules.

Actions:

Read current version from

@package.json

bash

# Read the version field
cat package.json | grep '"version"'

Apply semantic versioning rules:
- MAJOR (X.0.0): Increment when you make incompatible API changes
  - Breaking API changes
  - Removed features
  - Changed behavior that breaks existing code
  - Example:
```
1.2.3
```
    →
```
2.0.0
```
- MINOR (0.X.0): Increment when you add functionality in a backward-compatible manner
  - New features
  - New APIs (backward compatible)
  - Deprecated features (still functional)
  - Example:
```
1.2.3
```
    →
```
1.3.0
```
- PATCH (0.0.X): Increment when you make backward-compatible bug fixes
  - Bug fixes
  - Security patches
  - Performance improvements
  - Documentation updates (if versioned)
  - Example:
```
1.2.3
```
    →
```
1.2.4
```
Priority order: If multiple change types exist, use the highest:
- MAJOR > MINOR > PATCH
- If any breaking changes exist → MAJOR
- Else if any new features exist → MINOR
- Else → PATCH

Decision Tree:

Are there breaking changes?
├─ Yes → MAJOR version bump (X.0.0)
└─ No → Are there new features?
    ├─ Yes → MINOR version bump (0.X.0)
    └─ No → PATCH version bump (0.0.X)

Output: New version number (e.g.,

1.2.4

目标： 根据语义化版本控制规则计算新版本号。

操作：

从

@package.json

中读取当前版本号：

bash

# 读取version字段
cat package.json | grep '"version"'

应用语义化版本控制规则：
- MAJOR（X.0.0）：当做出不兼容的API变更时升级
  - 破坏性API变更
  - 功能移除
  - 变更行为导致现有代码无法正常运行
  - 示例：
```
1.2.3
```
    →
```
2.0.0
```
- MINOR（0.X.0）：当以向后兼容的方式新增功能时升级
  - 新增功能
  - 新增向后兼容的API
  - 标记为弃用的功能（仍可正常使用）
  - 示例：
```
1.2.3
```
    →
```
1.3.0
```
- PATCH（0.0.X）：当做出向后兼容的Bug修复时升级
  - Bug修复
  - 安全补丁
  - 性能优化
  - 文档更新（若纳入版本控制）
  - 示例：
```
1.2.3
```
    →
```
1.2.4
```
优先级顺序：若存在多种变更类型，按最高优先级执行：
- MAJOR > MINOR > PATCH
- 若存在任何破坏性变更 → 升级MAJOR版本
- 若无破坏性变更但有新功能 → 升级MINOR版本
- 其他情况 → 升级PATCH版本

决策树：

是否存在破坏性变更？
├─ 是 → MAJOR版本升级（X.0.0）
└─ 否 → 是否存在新功能？
    ├─ 是 → MINOR版本升级（0.X.0）
    └─ 否 → PATCH版本升级（0.0.X）

输出： 新版本号（例如：

1.2.4

）。

Step 3: Update @package.json Version Accordingly

步骤3：同步更新@package.json中的版本号

Objective: Update the version field in the root

@package.json

file.

Actions:

Read the current
```
@package.json
```
file
Locate the
```
"version"
```
field (usually near the top)
Update the version number to the new version determined in Step 2
Preserve all formatting:
- Keep the same indentation (spaces or tabs)
- Maintain the same JSON structure
- Don't modify other fields
- Don't reorder fields
- Keep trailing commas if they exist

Example:

json

// Before
{
  "name": "qa-skills",
  "version": "0.4.0",
  "private": true,
  ...
}

// After (PATCH bump)
{
  "name": "qa-skills",
  "version": "0.4.1",
  "private": true,
  ...
}

Important:

Only update the
```
version
```
field
Don't change any other content
Maintain JSON validity
Preserve file formatting and style

Output: Updated

@package.json

with new version number.

目标： 更新根目录下

@package.json

文件中的version字段。

操作：

读取当前
```
@package.json
```
文件
定位
```
"version"
```
字段（通常位于文件顶部）
将版本号更新为步骤2中确定的新版本号
保留所有格式：
- 保持相同的缩进（空格或制表符）
- 维持原有的JSON结构
- 不修改其他字段
- 不调整字段顺序
- 若原文件存在 trailing comma则保留

示例：

json

// 变更前
{
  "name": "qa-skills",
  "version": "0.4.0",
  "private": true,
  ...
}

// 变更后（PATCH版本升级）
{
  "name": "qa-skills",
  "version": "0.4.1",
  "private": true,
  ...
}

注意事项：

仅更新
```
version
```
字段
不修改任何其他内容
确保JSON格式有效
保留文件的原有格式和风格

输出： 已更新版本号的

@package.json

文件。

Step 4: Update @CHANGELOG.md with a New Version Block

步骤4：为@CHANGELOG.md添加新版本块

Objective: Add a new version section to

@CHANGELOG.md

following Keep a Changelog format.

Actions:

Read the current
```
@CHANGELOG.md
```
file
Locate the
```
## [Unreleased]
```
section (should be at the top)
Insert a new version block after
```
## [Unreleased]
```
and before the previous version
Use the format:
```
## [X.Y.Z] - YYYY-MM-DD
```
- ```
X.Y.Z
```
  is the new version number
- ```
YYYY-MM-DD
```
  is the current date (see Step 5)

Example Structure:

markdown

undefined

目标： 遵循Keep a Changelog格式，为

@CHANGELOG.md

添加新版本章节。

操作：

读取当前
```
@CHANGELOG.md
```
文件
定位
```
## [Unreleased]
```
章节（应位于文件顶部）
在
```
## [Unreleased]
```
之后、上一个版本章节之前插入新版本块
使用格式：
```
## [X.Y.Z] - YYYY-MM-DD
```
- ```
X.Y.Z
```
  为新版本号
- ```
YYYY-MM-DD
```
  为当前日期（见步骤5）

示例结构：

markdown

undefined

Changelog

[Unreleased]

[0.4.1] - 2026-01-25

Added

New feature description

新功能描述

[0.4.0] - 2026-01-25

...


**Important:**
- Place new version block between `[Unreleased]` and the previous release
- Use exact format: `## [X.Y.Z] - YYYY-MM-DD`
- Maintain consistent spacing with existing entries
- Don't modify existing version entries

**Output:** `@CHANGELOG.md` with new version header added.

...


**注意事项：**
- 将新版本块置于`[Unreleased]`与上一个发布版本之间
- 严格使用格式：`## [X.Y.Z] - YYYY-MM-DD`
- 与现有条目保持一致的间距
- 不修改现有版本条目

**输出：** 已添加新版本标题的`@CHANGELOG.md`文件。

Step 5: Add the Version and the Date

步骤5：添加版本号与日期

Objective: Ensure the version block has the correct version number and current date.

Actions:

Get the current date in YYYY-MM-DD format
- Use system date/time information
- Never assume or hardcode dates
- Format:
```
YYYY-MM-DD
```
  (e.g.,
```
2026-01-25
```
  )
Verify the version number matches Step 2 and Step 3
- Version in changelog header must match
```
@package.json
```
  version
- Format:
```
[X.Y.Z]
```
  where X, Y, Z are numbers
Update the version block header if needed:
markdown
```
## [0.4.1] - 2026-01-25
```

Date Format Rules:

Always use
```
YYYY-MM-DD
```
format
Use 4-digit year
Use 2-digit month (01-12)
Use 2-digit day (01-31)
Match the format of existing changelog entries

Example:

markdown

undefined

目标： 确保版本块包含正确的版本号和当前日期。

操作：

获取当前日期并格式化为YYYY-MM-DD格式
- 使用系统日期/时间信息
- 绝不假设或硬编码日期
- 格式：
```
YYYY-MM-DD
```
  （例如：
```
2026-01-25
```
  ）
验证版本号与步骤2、步骤3中的版本号一致
- 变更日志标题中的版本号必须与
```
@package.json
```
  中的版本号匹配
- 格式：
```
[X.Y.Z]
```
  ，其中X、Y、Z为数字
（若需）更新版本块标题：
markdown
```
## [0.4.1] - 2026-01-25
```

日期格式规则：

始终使用
```
YYYY-MM-DD
```
格式
年份为4位数字
月份为2位数字（01-12）
日期为2位数字（01-31）
与现有变更日志条目的格式保持一致

示例：

markdown

undefined

[1.2.4] - 2026-01-25


**Output:** Version block with correct version number and date.


**输出：** 包含正确版本号和日期的版本块。

Step 6: Add the Changelog Data

步骤6：添加变更日志内容

Objective: Populate the version block with categorized change entries.

Actions:

Organize changes from Step 1 into appropriate sections
Use the standard Keep a Changelog sections:
- ```
### Added
```
  - New features
- ```
### Changed
```
  - Changes in existing functionality
- ```
### Deprecated
```
  - Soon-to-be removed features
- ```
### Removed
```
  - Removed features
- ```
### Fixed
```
  - Bug fixes
- ```
### Security
```
  - Security vulnerabilities
Format each entry:
- Use bullet points with
```
- 
```
  prefix
- Start with a capital letter
- End without a period (unless it's a full sentence)
- Be concise and descriptive
- Focus on user-facing changes
Section Guidelines:
- Added: New features, new APIs, new components, new capabilities
- Changed: Modified behavior, API changes (non-breaking), improvements
- Deprecated: Features marked for removal in future versions
- Removed: Features that were removed (usually indicates MAJOR bump)
- Fixed: Bug fixes, corrections, patches
- Security: Security-related fixes and improvements
Only include sections that have changes
Order sections: Added, Changed, Deprecated, Removed, Fixed, Security

Example:

markdown

undefined

目标： 为版本块填充已分类的变更条目。

操作：

将步骤1中的变更内容整理至对应章节
使用Keep a Changelog标准章节：
- ```
### Added
```
  - 新功能
- ```
### Changed
```
  - 现有功能的变更
- ```
### Deprecated
```
  - 即将移除的功能
- ```
### Removed
```
  - 已移除的功能
- ```
### Fixed
```
  - Bug修复
- ```
### Security
```
  - 安全漏洞修复
格式化每个条目：
- 使用
```
- 
```
  前缀的项目符号
- 首字母大写
- 结尾不加句号（除非是完整句子）
- 简洁且具有描述性
- 聚焦于用户可见的变更
章节指南：
- Added：新功能、新API、新组件、新能力
- Changed：行为修改、非破坏性API变更、功能改进
- Deprecated：标记为将在未来版本移除的功能
- Removed：已移除的功能（通常对应MAJOR版本升级）
- Fixed：Bug修复、问题修正、补丁
- Security：安全相关的修复与改进
仅保留包含变更内容的章节
章节顺序：Added、Changed、Deprecated、Removed、Fixed、Security

示例：

markdown

undefined

[0.4.1] - 2026-01-25

Added

New changelog generator skill for cursor agents
Support for semantic versioning automation

为Cursor Agent新增变更日志生成器技能
支持语义化版本控制自动化

Fixed

Corrected version bump logic for patch releases
Fixed date formatting in changelog entries

修正补丁版本升级的逻辑
修复变更日志条目中的日期格式问题

Changed

Improved changelog entry categorization


**Writing Guidelines:**
- Write from the user's perspective
- Use present tense ("Adds feature" not "Added feature")
- Be specific but concise
- Group related changes together
- Avoid technical jargon when possible
- Focus on what changed, not how it was implemented

**Output:** Complete version block with all categorized changes.

优化变更日志条目分类逻辑


**撰写指南：**
- 从用户视角撰写
- 使用现在时态（“新增功能”而非“已添加功能”）
- 具体且简洁
- 相关变更分组展示
- 尽可能避免技术术语
- 聚焦于变更内容而非实现细节

**输出：** 包含所有已分类变更内容的完整版本块。

Step 7: One Final Review

步骤7：最终审查

Objective: Verify everything is correct and consistent before completion.

Checklist:

Version Consistency:
- Version in
```
@package.json
```
  matches version in
```
@CHANGELOG.md
```
  header
- Version format is correct (X.Y.Z where X, Y, Z are numbers)
Date Format:
- Date is in YYYY-MM-DD format
- Date matches current date (not future or past)
- Date format matches existing changelog entries
Changelog Content:
- All staged changes are represented in the changelog
- Changes are in the correct sections
- No duplicate entries
- Entries are clear and descriptive
Formatting:
- Markdown formatting is correct
- Version block is in the correct location (after
```
[Unreleased]
```
  )
- Proper spacing between sections
- Consistent with existing changelog style
Semantic Versioning:
- Version bump type matches change types (MAJOR/MINOR/PATCH)
- Breaking changes → MAJOR bump
- New features → MINOR bump
- Bug fixes → PATCH bump
File Integrity:
- ```
@package.json
```
  is valid JSON
- ```
@CHANGELOG.md
```
  is valid markdown
- No syntax errors
- Files are properly formatted

If any issues are found:

Fix them before completing
Re-verify the checklist
Ensure consistency across all files

Output: Verified and consistent changelog and version updates.

目标： 在完成前验证所有内容的正确性与一致性。

检查清单：

版本一致性：
- ```
@package.json
```
  中的版本号与
```
@CHANGELOG.md
```
  标题中的版本号一致
- 版本号格式正确（X.Y.Z，其中X、Y、Z为数字）
日期格式：
- 日期格式为YYYY-MM-DD
- 日期为当前日期（非未来或过去日期）
- 日期格式与现有变更日志条目一致
变更日志内容：
- 所有暂存变更均已在变更日志中体现
- 变更内容位于正确章节
- 无重复条目
- 条目清晰且具有描述性
格式规范：
- Markdown格式正确
- 版本块位于正确位置（
```
[Unreleased]
```
  之后）
- 章节间间距合理
- 与现有变更日志风格一致
语义化版本控制：
- 版本升级类型与变更类型匹配（MAJOR/MINOR/PATCH）
- 破坏性变更 → 升级MAJOR版本
- 新功能 → 升级MINOR版本
- Bug修复 → 升级PATCH版本
文件完整性：
- ```
@package.json
```
  为有效的JSON格式
- ```
@CHANGELOG.md
```
  为有效的Markdown格式
- 无语法错误
- 文件格式规范

若发现任何问题：

在完成前修复问题
重新验证检查清单
确保所有文件内容一致

输出： 已验证且内容一致的变更日志与版本更新。

File References

文件引用

This skill references files using the

syntax convention:

@package.json
: The root
```
package.json
```
file in the repository
- Contains the
```
version
```
  field that needs updating
- Located at the repository root
@CHANGELOG.md
: The changelog file following Keep a Changelog format
- Contains version history and change documentation
- Located at the repository root
- Format: Markdown with version blocks

Usage in skill: When the skill mentions

@package.json

@CHANGELOG.md

, it refers to these specific files at the repository root. Always read these files before making changes and verify their current state.

本技能使用

语法约定引用文件：

@package.json
：仓库根目录下的
```
package.json
```
文件
- 包含需要更新的
```
version
```
  字段
- 位于仓库根目录
@CHANGELOG.md
：遵循Keep a Changelog格式的变更日志文件
- 包含版本历史与变更记录
- 位于仓库根目录
- 格式：带有版本块的Markdown文件

技能中的使用方式： 当技能提及

@package.json

或

@CHANGELOG.md

时，均指仓库根目录下的对应文件。在进行变更前请务必读取这些文件并验证其当前状态。

Semantic Versioning Rules

语义化版本控制规则

Follow Semantic Versioning 2.0.0 specification:

遵循语义化版本控制2.0.0规范：

Version Format: MAJOR.MINOR.PATCH

版本格式：MAJOR.MINOR.PATCH

MAJOR version (X.0.0): Increment when you make incompatible API changes
- Breaking changes to public APIs
- Removed features or functionality
- Changed behavior that breaks existing code
- Example:
```
1.2.3
```
  →
```
2.0.0
```
MINOR version (0.X.0): Increment when you add functionality in a backward-compatible manner
- New features added
- New APIs (backward compatible)
- Deprecated features (still functional)
- Example:
```
1.2.3
```
  →
```
1.3.0
```
PATCH version (0.0.X): Increment when you make backward-compatible bug fixes
- Bug fixes
- Security patches
- Performance improvements
- Documentation updates (if versioned)
- Example:
```
1.2.3
```
  →
```
1.2.4
```

MAJOR版本（X.0.0）：当做出不兼容的API变更时升级
- 公共API的破坏性变更
- 功能或能力移除
- 变更行为导致现有代码无法正常运行
- 示例：
```
1.2.3
```
  →
```
2.0.0
```
MINOR版本（0.X.0）：当以向后兼容的方式新增功能时升级
- 新增功能
- 新增向后兼容的API
- 标记为弃用的功能（仍可正常使用）
- 示例：
```
1.2.3
```
  →
```
1.3.0
```
PATCH版本（0.0.X）：当做出向后兼容的Bug修复时升级
- Bug修复
- 安全补丁
- 性能优化
- 文档更新（若纳入版本控制）
- 示例：
```
1.2.3
```
  →
```
1.2.4
```

Pre-release and Build Metadata

预发布版本与构建元数据

Pre-release versions:
```
1.0.0-alpha.1
```
,
```
1.0.0-beta.2
```
,
```
1.0.0-rc.1
```
Build metadata:
```
1.0.0+20130313144700
```

For standard releases, use the three-part version number (X.Y.Z).

预发布版本：
```
1.0.0-alpha.1
```
、
```
1.0.0-beta.2
```
、
```
1.0.0-rc.1
```
构建元数据：
```
1.0.0+20130313144700
```

对于标准发布版本，使用三段式版本号（X.Y.Z）即可。

Decision Priority

决策优先级

When multiple change types exist:

Any breaking changes → MAJOR bump
Any new features (without breaking changes) → MINOR bump
Only bug fixes → PATCH bump

当存在多种变更类型时：

任何破坏性变更 → 升级MAJOR版本
任何新功能（无破坏性变更）→ 升级MINOR版本
仅Bug修复 → 升级PATCH版本

Keep a Changelog Format

Keep a Changelog格式规范

Follow the Keep a Changelog format standards:

遵循Keep a Changelog格式标准：

Structure

结构

markdown

undefined

markdown

undefined

Changelog

[Unreleased]

[X.Y.Z] - YYYY-MM-DD

Added

New features

新功能

Changed

Changes in existing functionality

现有功能的变更

Deprecated

Soon-to-be removed features

即将移除的功能

Removed

Removed features

已移除的功能

Fixed

Bug fixes

Bug修复

Security

Security vulnerabilities

undefined

安全漏洞修复

undefined

Section Guidelines

章节指南

Added: New features, capabilities, or functionality
Changed: Modifications to existing functionality
Deprecated: Features that will be removed in a future version
Removed: Features that have been removed
Fixed: Bug fixes and corrections
Security: Security-related fixes and improvements

Added：新功能、能力或特性
Changed：对现有功能的修改
Deprecated：将在未来版本移除的功能
Removed：已移除的功能
Fixed：Bug修复与问题修正
Security：安全相关的修复与改进

Formatting Rules

格式规则

Use
```
##
```
for version headers:
```
## [X.Y.Z] - YYYY-MM-DD
```
Use
```
###
```
for change type sections:
```
### Added
```
Use
```
- 
```
for bullet points
Date format:
```
YYYY-MM-DD
```
Only include sections that have changes
Order: Added, Changed, Deprecated, Removed, Fixed, Security

使用
```
##
```
作为版本标题：
```
## [X.Y.Z] - YYYY-MM-DD
```
使用
```
###
```
作为变更类型章节标题：
```
### Added
```
使用
```
- 
```
作为项目符号
日期格式：
```
YYYY-MM-DD
```
仅保留包含变更内容的章节
章节顺序：Added、Changed、Deprecated、Removed、Fixed、Security

Best Practices

最佳实践

Write from the user's perspective
Be clear and concise
Group related changes
Use present tense
Focus on what changed, not implementation details
Keep
```
[Unreleased]
```
section for future changes

从用户视角撰写
清晰且简洁
相关变更分组展示
使用现在时态
聚焦于变更内容而非实现细节
保留
```
[Unreleased]
```
章节用于记录未来变更

Quick Reference

快速参考

Git Commands

Git命令

bash

undefined

bash

undefined

Check staging status

查看暂存状态

git status

Review staged changes

查看暂存变更

git diff --cached

View commit history

查看提交历史

git log --oneline --cached

undefined

git log --oneline --cached

undefined

Version Bump Examples

版本升级示例

bash

undefined

bash

undefined

Current: 1.2.3

当前版本：1.2.3

Breaking change → 2.0.0

破坏性变更 → 2.0.0

New feature → 1.3.0

新功能 → 1.3.0

Bug fix → 1.2.4

Bug修复 → 1.2.4

undefined

undefined

Changelog Entry Template

变更日志条目模板

markdown

undefined

markdown

undefined

[X.Y.Z] - YYYY-MM-DD

Added

Description of new feature

新功能描述

Changed

Description of change

变更内容描述

Fixed

Description of fix

undefined

修复内容描述

undefined

Common Patterns

常见场景

Pattern: Feature Release

场景：功能发布

Changes: New features, no breaking changes
Version: MINOR bump (0.X.0)
Sections:
```
### Added
```
, possibly
```
### Changed
```

变更内容：新增功能，无破坏性变更
版本升级：MINOR版本（0.X.0）
涉及章节：
```
### Added
```
，可能包含
```
### Changed
```

Pattern: Bug Fix Release

场景：Bug修复发布

Changes: Only bug fixes
Version: PATCH bump (0.0.X)
Sections:
```
### Fixed
```

变更内容：仅包含Bug修复
版本升级：PATCH版本（0.0.X）
涉及章节：
```
### Fixed
```

Pattern: Major Release

场景：重大版本发布

Changes: Breaking changes
Version: MAJOR bump (X.0.0)
Sections:
```
### Removed
```
,
```
### Changed
```
, possibly
```
### Added
```

变更内容：包含破坏性变更
版本升级：MAJOR版本（X.0.0）
涉及章节：
```
### Removed
```
、
```
### Changed
```
，可能包含
```
### Added
```

Pattern: Security Release

场景：安全发布

Changes: Security fixes
Version: PATCH bump (usually) or MAJOR (if breaking)
Sections:
```
### Security
```
,
```
### Fixed
```

变更内容：安全修复
版本升级：通常为PATCH版本（若为破坏性变更则升级MAJOR版本）
涉及章节：
```
### Security
```
、
```
### Fixed
```

Troubleshooting

故障排除

Issue: Version mismatch between files

问题：文件间版本号不匹配

Solution: Ensure Step 3 and Step 4 use the same version number. Re-check both files.

解决方案： 确保步骤3和步骤4使用相同的版本号，重新检查两个文件。

Issue: Can't determine version bump type

问题：无法确定版本升级类型

Solution: Review Step 1 changes carefully. Use priority: MAJOR > MINOR > PATCH.

解决方案： 仔细审查步骤1中的变更内容，遵循优先级：MAJOR > MINOR > PATCH。

Issue: Changelog format doesn't match existing

问题：变更日志格式与现有格式不匹配

Solution: Review existing

@CHANGELOG.md

entries and match their style exactly.

解决方案： 查看现有

@CHANGELOG.md

条目，严格匹配其风格。

Issue: Missing changes in changelog

问题：变更日志中遗漏部分变更

Solution: Re-run Step 1 to ensure all staged changes are reviewed and categorized.

解决方案： 重新执行步骤1，确保所有暂存变更均已被审查并分类。