Based on GitCode API , pull the repository's commits within the specified range.The script is only responsible for fetching commits and simple filtering；YouBased on the JSON output by the script, summarize, categorize, polish, and generate the final release note, output as Markdown format, so that the release note is clear to read and looks human-written.
When to Use
- The user expresses intents such as “generate release notes”, “version release notes”, “changelog from v1.0 to now”, “commit records from a certain date to now”, etc.
- Mustbe provided in this conversation:
--repo owner/repo(required); optionally provide--branch、--from、--to、--since-date。
Authentication
GITCODE_TOKEN: read in the following priority order.
| Priority | Source |
|---|---|
| 1 | Process environment variable GITCODE_TOKEN |
| 2 | Windows user-level environment variable |
| 3 | Windows system-level environment variable |
- Linux/macOS: recommended in
~/.bashrcor~/.zshrc,export GITCODE_TOKEN="..."。 - When not configured: the script reports a detailed error, prompting to GitCode personal access token create and set the environment variable.
Path Conventions
- Skill root directory（
SKILL_ROOT): the directory where this SKILL.md is located. The script is located via__file__,does not depend on the current working directory。 - Supports Linux / macOS / Windows; when executing, use the script'sabsolute path。
Fixed Process
- Parse parameters: extract from user input or conversation
--repo(required),--branch、--from、--to、--since-date。 - Call script (output JSON)：
python <SKILL_ROOT>/scripts/release_notes.py --repo owner/repo --json [--branch BRANCH] [--from TAG] [--to TAG] [--since-date YYYY-MM-DD]- Must include
--json: the script only performs fetching and simple filtering, and outputs to stdout JSON, without generating the final Markdown. - Choose one of three ranges:
--since-date(from that day 00:00 Shanghai time to now),--from(from a tag to now), or--from+--to(between two tags). --branchWhen not passed: the script tries in order master → develop → main, and if none exist, reports an error and prompts to use--branch。
- Must include
- Read JSON: parse JSON from stdout. If the exit code is non-zero or stderr contains error information, show the user thedetailed errorand end.
- Generate the final release note：
- Based on the
commitsin the JSON, performcategorization(new features / fixes / docs / other),summarization(briefly summarize each item or group; do not paste the original commit text directly),polishing(unify language, merge similar items, remove items with no information), to generate a clean, professional release note suitable for external publication. - According to “Final release note output format” and “Writing Principles” Write Markdown (title, four sections, each item with only a brief description; do not show commit information; do not show valueless information such as merge count/tests/compliance).
- Deliver to the user (can be saved as a file or pasted into a GitCode Release).
- Based on the
- Prohibited: Do not guess or fabricate data before obtaining the script JSON; do not deliver the commit list as-is as the final release note,it must be summarized and polishedbefore delivery. For other prohibitions, see the "Prohibited" section.
Script parameters
| Parameter | Required | Description |
|---|---|---|
--repo |
Yes | Repository, format owner/repo |
--json |
Required (when this skill is invoked) | Script outputs JSON (fetching + simple filtering only), which you summarize and use to generate the final release note |
--branch |
No | Branch; if not passed, automatically try master → develop → main |
--since-date |
No | Commits from that date 00:00 (Asia/Shanghai) to now |
--from |
No | Start tag (to current HEAD or to --to） |
--to |
No | End tag, together with --from represents an interval |
--max-per-category |
No | Only takes effect when --json is not used; maximum number of items to display per category, default 10 |
- Interval convention: use only
--since-date, or only--from, or--from+--to. If multiple are passed at the same time, the script handles them by--since-date>--from/--topriority. - Under this skill flowmust include
--json(to obtain JSON for you to summarize);without--json, the script directly outputs Markdown, without going through this skill's summarization step.
Script --json output and your responsibilities
- Script: only fetches commits and performs simple filtering (excludes empty messages and pure merges), outputs JSON to stdout; does not categorize and does not write summaries.
- You: parse JSON from stdout, according to
commitsandstatscategorize, briefly summarize, and polish; write Markdown according to "Final release note output format" and "Writing principles"; do not list commits as-is.
Final release note output format (must be followed consistently)
When generating Markdownmustfollow the format below; for each item'sbrief descriptionsummarize based on the commits.
- Title：
# owner/repo Release Notes（版本区间）, or use thetitle_linein the JSON as the second-level title (e.g.,## v1.1.0 (YYYY-MM-DD)), the first-level title may be# owner/repo Release Notes。 - Section order and titles(only output those with content; order must not be changed):
### 🚀 新特性### 🐛 修复### 📚 文档### 🔧 其他更改
- Item format：
- 简要说明. The brief description is summarized by you based on that commit;do not show commit hashes or links。 - Other changes: retain only architecture or capability changes perceivable by users/consumers;do not show"Merges and dependency updates (N items total)"; if there is no substantive content, omit this subsection or leave only 1–2 items.
- Number of items per category: new features, fixes, documentation, other changesMaximum 10 items per category; prioritize retaining the items with the highest value and easiest to understand for users; when exceeding the limit, merge similar items or omit secondary ones.
- Language: Section titles and item descriptions should be written in Chinese; proper nouns and repository names may be kept in English.
Writing principles (to ensure output quality)
Enable non-core R&D personnel (QA, product, ops, etc.) to quickly grasp the key points, avoiding information overload and internal jargon.
- Concise granularitymerge similar items by capability/module; a single item should not pile up multiple unrelated features; new features can be grouped by dimensions such as "hardware and topology / scheduling / devices and plugins / high availability / inference and operations"; different issues in fixes should be split into separate items or merged by category, avoiding mixing multiple unrelated bugs in one item.
- Unified terminologyuse consistent wording for the same concept throughout (do not mix different spellings of the same term); professional abbreviations may be briefly explained in parentheses when they first appear; avoid abbreviations used only internally appearing directly in external release notes.
- Do not show worthless informationdo not show "merges and dependency updates (N items total)"; do not include test cases or test case additions; do not include compliance; do not include internal details (such as cleancode, codecheck, DT, or various internal bug fixes).
- Focus on valuekeep only changes meaningful to users/adopters; vague statements (such as merely writing "logic optimization") should be merged into specific capability descriptions or omitted; appropriately shorten long sentences, and keep item line breaks clear.
- Each item short and scannableeach item should be as much as possibleone sentence, one point, avoid using semicolons/commas to pile up multiple features or fixes in one sentence; you may refer to the release note style of mature open source communities (such as Kubernetes, VS Code)—short, easy to scan, so readers can grasp the key points within seconds.
Output example (Markdown)
# owner/repo Release Notes（v1.0.0 → v1.1.0）
### 🚀 新特性
- 新增 XXX 支持，兼容 A 与 B 场景。
- 支持从配置文件加载集群拓扑。
### 🐛 修复
- 修复 namespace 与任务名相同时的匹配错误。
- 修复日志打印重复与级别丢失问题。
- 修复包含 init 容器时的配置生成问题。
### 📚 文档
- 更新依赖源说明。
### 🔧 其他更改
- 设备 ID 体系与资源管理实现与重构。
- 故障码与知识库、路径诊断等能力补充与优化。
Prohibited
- It is prohibited to guess or fabricate data before obtaining the script output (JSON).
- It is prohibited to execute the script when
--repois not configured (you must prompt the user to provide--repo）。 - It is prohibited to deliver the commit list from the script JSON as the final release note as-is (you must summarize, categorize, and polish it before outputting Markdown).
- It is prohibited to directly copy the original commit text; you must re-summarize and rewrite it.
- It is prohibited to include any commit links, commit IDs, or git addresses.
- It is prohibited to list scattered fixes; issues of the same type must be merged into one item.
- Keep only content meaningful to users/adopters; remove irrelevant information such as internal debugging, branch merges, and overly fragmented documentation changes.
- It is prohibited to show "merges and dependency updates (N items total)"; it is prohibited to include internal details such as test cases, going overseas and compliance, cleancode/codecheck/DT/internal bugs.
Example
| User intent | Command (must include --json) |
|---|---|
| From v1.0.0 to current | python <S> --repo owner/repo --json --from v1.0.0 |
| From v1.0.0 to v1.1.0 | python <S> --repo owner/repo --json --from v1.0.0 --to v1.1.0 |
| From 2026-01-08 to present (Shanghai time) | python <S> --repo owner/repo --json --since-date 2026-01-08 |
| Specified branch | python <S> --repo owner/repo --json --since-date 2026-01-08 --branch main |
Where <S> is the absolute path of <SKILL_ROOT>/scripts/release_notes.py . Without --json , the script will directly output Markdown without going through this skill's summarization step.
Historical versions
v1.0.0 (2026-03-11)
- 🎉 Initial version release
- 📖 Support generating Release Notes Markdown by tag/date