vLLM Ascend Releasing Note Writer Skill
Overview
You should use the ref-past-release-notes-highlight.md as style and cateogry reference. Always read these first.
When to use this skill
When a new version of vLLM Ascend is released, you should use this skill to write the release notes.
How to use it
all ouput files should be saved under vllm-ascend-releasing-note/output/$version folder
Use the fetch_commits-optimize.py script to fetch the commits between the previous and current version.
uv run python fetch_commits-optimize.py --base-tag $LAST_TAG --head-tag $NEW_TAG --output 0-current-raw-commits.md
0-current-raw-commits.md is your raw data input.
Use the commit-analysis-draft.csv tool to analyze the commits and put them into the correct section.
1-commit-analysis-draft.csv is your workspace for commit by commit analysis for which commit goes into which section, whether can be ignored, and why. You can create auxilariy files in tmp folder.
- You should check each commit. They are put into rows in the CSV file.
- The CSV should have headers
title, pr number, user facing impact/summary, catgory, decision, reason. Please brainstorm other fields as you see fit.
Draft the highlights note, and save it to 2-highlights-note-draft.md.
Edit the draft highlights note in 2-highlights-note-draft.md, and save it to 3-highlights-note-edit.md. You should double and triple check with the raw commits + analysis. You can leave any uncertainty and doubts in the file, and we will discuss them together.
Use the format This is the $NUMBER release candidate of $VERSION for vLLM Ascend. Please follow the [official doc](https://docs.vllm.ai/projects/ascend/en/latest) to get started..
Writing style
- To keep simple, you should only save one level of headings, starting with ###, which may include the following categories follow below order:
Highlights
Features
Hardware and Operator Support
Performance
Dependencies
Deprecation & Breaking Changes
Documentation
Others
- Additional Inclusion Criteria
- User experience improvements (CLI enhancements, better error messages, configuration flexibility)
- Core feature (PD Disaggregation, KVCaceh, Graph mode, CP/SP, quantization)
- Breaking changes and deprecations (always include with clear impact description)
- Significant infrastructure changes (elastic scaling, distributed serving, hardware support)
- Major dependency updates (CANN/torch_npu/triton-ascend/MoonCake/Ray/transformers versions, critical library updates)
- Binary/deployment improvements (size reductions, Docker enhancements)
- Default behavior changes (default models, configuration changes that affect all users)
- Hardware compatibility expansions (310P, A2, A3, A5 support)
In the end we don't want to miss any important changes. But also don't want to spam the notes with unnecessary details.
- Section Organization Guidelines
- Model Support first: Most immediately visible to users, should lead the highlights
- Group by user impact: Hardware/performance should focus on what users experience, not internal optimizations
- Provide usage context: Include relevant flags, configuration options, and practical usage information
- Technical detail level: Explain what features enable rather than just listing technical changes
- Writing Tips
- Look up the PR if you are not sure about the details. The PR number at the end (#12345) can be looked up via vllm-project/vllm#12345. To get the description, you just need to call https://api.github.com/repos/vllm-project/vllm/pulls/12345 and look at the body field.
- When writing the highlights, don't be too verbose. Focus exclusively on what users should know.
1---2name: vllm-ascend-releasing-note-writer3description: You are a releasing note writer for vLLM Ascend project (vllm-project/vllm-ascend). You are responsible for writing release notes for vLLM Ascend.4---56# vLLM Ascend Releasing Note Writer Skill78## Overview9You should use the `ref-past-release-notes-highlight.md` as style and cateogry reference. Always read these first.1011## When to use this skill12When a new version of vLLM Ascend is released, you should use this skill to write the release notes.1314## How to use it150. all ouput files should be saved under `vllm-ascend-releasing-note/output/$version` folder16171. Use the `fetch_commits-optimize.py` script to fetch the commits between the previous and current version.1819```20uv run python fetch_commits-optimize.py --base-tag $LAST_TAG --head-tag $NEW_TAG --output 0-current-raw-commits.md21```22`0-current-raw-commits.md` is your raw data input.23242. Use the `commit-analysis-draft.csv` tool to analyze the commits and put them into the correct section.25`1-commit-analysis-draft.csv` is your workspace for commit by commit analysis for which commit goes into which section, whether can be ignored, and why. You can create auxilariy files in `tmp` folder. 26 * You should check each commit. They are put into rows in the CSV file. 27 * The CSV should have headers `title`, `pr number`, `user facing impact/summary`, `catgory`, `decision`, `reason`. Please brainstorm other fields as you see fit.28293. Draft the highlights note, and save it to `2-highlights-note-draft.md`.304. Edit the draft highlights note in `2-highlights-note-draft.md`, and save it to `3-highlights-note-edit.md`. You should double and triple check with the raw commits + analysis. You can leave any uncertainty and doubts in the file, and we will discuss them together. 315. Use the format `This is the $NUMBER release candidate of $VERSION for vLLM Ascend. Please follow the [official doc](https://docs.vllm.ai/projects/ascend/en/latest) to get started.`.3233## Writing style341. To keep simple, you should only save one level of headings, starting with ###, which may include the following categories follow below order: 35### Highlights36### Features37### Hardware and Operator Support38### Performance39### Dependencies40### Deprecation & Breaking Changes41### Documentation42### Others43442. Additional Inclusion Criteria45* User experience improvements (CLI enhancements, better error messages, configuration flexibility)46* Core feature (PD Disaggregation, KVCaceh, Graph mode, CP/SP, quantization)47* Breaking changes and deprecations (always include with clear impact description)48* Significant infrastructure changes (elastic scaling, distributed serving, hardware support)49* Major dependency updates (CANN/torch_npu/triton-ascend/MoonCake/Ray/transformers versions, critical library updates)50* Binary/deployment improvements (size reductions, Docker enhancements)51* Default behavior changes (default models, configuration changes that affect all users)52* Hardware compatibility expansions (310P, A2, A3, A5 support)53In the end we don't want to miss any important changes. But also don't want to spam the notes with unnecessary details.54553. Section Organization Guidelines56* **Model Support first**: Most immediately visible to users, should lead the highlights57* **Group by user impact**: Hardware/performance should focus on what users experience, not internal optimizations58* **Provide usage context**: Include relevant flags, configuration options, and practical usage information59* **Technical detail level**: Explain what features enable rather than just listing technical changes60614. Writing Tips 62* Look up the PR if you are not sure about the details. The PR number at the end (#12345) can be looked up via vllm-project/vllm#12345. To get the description, you just need to call https://api.github.com/repos/vllm-project/vllm/pulls/12345 and look at the body field.63* When writing the highlights, don't be too verbose. Focus exclusively on what users should know.
opensourceways