docs-changelog
Original:🇺🇸 English
Translated
Provides a step-by-step procedure for generating Gemini CLI changelog files based on github release information.
2installs
Sourcegoogle-gemini/gemini-cli
Added on
NPX Install
npx skill4agent add google-gemini/gemini-cli docs-changelogTags
Translated version includes tags in frontmatterSKILL.md Content
View Translation Comparison →Procedure: Updating Changelog for New Releases
The following instructions are run by Gemini CLI when processing new releases.
Objective
To standardize the process of updating the Gemini CLI changelog files for a new
release, ensuring accuracy, consistency, and adherence to project style
guidelines.
Release Types
This skill covers two types of releases:
- Standard Releases: Regular, versioned releases that are announced to all
users. These updates modify and
docs/changelogs/latest.md.docs/changelogs/index.md - Preview Releases: Pre-release versions for testing and feedback. These
updates only modify .
docs/changelogs/preview.md
Ignore all other releases, such as nightly releases.
Expected Inputs
Regardless of the type of release, the following information is expected:
- New version number: The version number for the new release
(e.g., ).
v0.27.0 - Release date: The date of the new release (e.g., ).
2026-02-03 - Raw changelog data: A list of all pull requests and changes
included in the release, in the format .
description by @author in #pr_number - Previous version number: The version number of the last release can be calculated by decreasing the minor version number by one and setting the patch or bug fix version number.
Procedure
Initial Setup
-
Identify the files to be modified:For standard releases, updateand
docs/changelogs/latest.md. For preview releases, updatedocs/changelogs/index.md.docs/changelogs/preview.md -
Activate theskill.
docs-writer
Analyze Raw Changelog Data
-
Review the complete list of changes. If it is a patch or a bug fix with few changes, skip to the "Updateor
docs/changelogs/latest.md" section.docs/changelogs/preview.md -
Group related changes into high-level categories such as important features, "UI/UX Improvements", and "Bug Fixes". Use the existing announcements inas an example.
docs/changelogs/index.md
Create Highlight Summaries
Create two distinct versions of the release highlights.
Important: Carefully inspect highlights for "experimental" or
"preview" features before public announcement, and do not include them.
Version 1: Comprehensive Highlights (for latest.md
or preview.md
)
latest.mdpreview.mdWrite a detailed summary for each category focusing on user-facing
impact.
Version 2: Concise Highlights (for index.md
)
index.mdSkip this step for preview releases.
Write concise summaries including the primary PR and author
(e.g., ).
([#12345](link) by @author)Update docs/changelogs/latest.md
or docs/changelogs/preview.md
docs/changelogs/latest.mddocs/changelogs/preview.md- Read current content and use to replace it with the new version number, and date.
write_file
If it is a patch or bug fix with few changes, simply add these
changes to the "What's Changed" list. Otherwise, replace comprehensive
highlights, and the full "What's Changed" list.
- For each item in the "What's Changed" list, keep usernames in plaintext, and add github links for each issue number. Example:
"- feat: implement /rewind command by @username in
#12345"
-
Skip entries by @gemini-cli-robot.
-
Do not add the "New Contributors" section.
-
Update the "Full changelog:" link with the previous version and the new version, unless it is a patch or a bug fix, in which case simply update the link's new version and keep the previous version the same.
-
Ensure lines are wrapped to 80 characters.
Update docs/changelogs/index.md
docs/changelogs/index.mdSkip this step for patches, bug fixes, or preview releases.
Insert a new "Announcements" section for the new version directly
above the previous version's section. Ensure lines are wrapped to
80 characters.
Finalize
Run to ensure consistency.
npm run format