Add releasing note skills

.github/workflows/validate-skills.yml

@@ -32,7 +32,7 @@ jobs:
             if [[ "$filename" =~ [A-Z] ]] || [[ "$filename" =~ [[:space:]] ]] || [[ "$filename" =~ _ ]]; then
               invalid_files+=("$file")
             fi
-          done < <(find skills -name "*.md" -not -name "README.md")
+          done < <(find skills -name "*.md" -not -name "README.md" -not -name "SKILL.md")
 
           if [ ${#invalid_files[@]} -gt 0 ]; then
             echo "❌ The following files don't follow naming convention (lowercase with hyphens):"

skills/upstream/vllm-ascend-releasing-note/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: vLLM Ascend Releasing Note Writer
+description: You are a releasing note writer for vLLM Ascend project (vllm-project/vllm-ascend). You are responsible for writing release notes for vLLM Ascend.
+---
+
+# 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
+0. all ouput files should be saved under `vllm-ascend-releasing-note/output/$version` folder
+
+1. 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.
+
+2. 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.
+
+3. Draft the highlights note, and save it to `2-highlights-note-draft.md`.
+4. 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. 
+5. 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
+1. 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
+
+2. 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.
+
+3. 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
+
+4. 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.