hsliuustc0106/vllm-omni-release-note-writer
skills/vllm-omni-release-note-writer/SKILL.md
Use when drafting or editing release notes for vllm-project/vllm-omni, especially when summarizing changes between tags, organizing highlights, and matching the style of recent vLLM-Omni releases
$ install --global
skillsauthnpx skillsauth add hsliuustc0106/vllm-omni-skills vllm-omni-release-note-writerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 3, 2026, 2:56 AM193.3s3 files scanned
SKILL.md
- name:
- vllm-omni-release-note-writer
- description:
- Use when drafting or editing release notes for vllm-project/vllm-omni, especially when summarizing changes between tags, organizing highlights, and matching the style of recent vLLM-Omni releases
vLLM-Omni Release Note Writer
Overview
This skill writes release notes for vllm-project/vllm-omni by following the editorial style that emerged in the project's historical releases.
Always read references/past-release-note-patterns.md first, then use references/release-note-template.md as the drafting template.
When to Use
- Drafting a new
vLLM-Omnirelease note from merged PRs or a GitHub compare view - Rewriting an auto-generated
What's Changeddump into a user-facing summary - Editing an RC or final release note so it matches recent
v0.12.0rc1tov0.18.0structure - Cross-checking whether a change belongs in Highlights, a themed section, or should be omitted
Do not use this skill for changelog generation in unrelated repos.
Output Workspace
Save working files under vllm-omni-release-note/output/$VERSION/.
Recommended files:
0-raw-input.md: compare output, PR list, and rough notes1-commit-triage.csv: per-PR inclusion and category decisions2-highlights-draft.md: short editorial summary3-release-note-draft.md: full release note draft4-release-note-review.md: questions, uncertainties, and follow-up checks
Core Workflow
1. Gather the release boundary
Identify:
- current tag, for example
v0.18.0 - previous tag
- whether the target is an RC or final release
Tag selection rules:
- For a final release,
current tagis the tag of the release being written, andprevious tagis the previous final release tag. - For an RC release,
current tagis the tag of the RC being written, andprevious tagis the immediately previous final or RC release tag.
Examples:
- Final release: writing
v0.18.0meanscurrent tag = v0.18.0,previous tag = v0.16.0 - RC release: writing
v0.18.0rc1meanscurrent tag = v0.18.0rc1,previous tag = v0.17.0rc1orv0.17.0, whichever is the most recent prior final/RC tag in the release chain
Use one or more of:
https://github.com/vllm-project/vllm-omni/releaseshttps://api.github.com/repos/vllm-project/vllm-omni/releaseshttps://api.github.com/repos/vllm-project/vllm-omni/compare/<base>...<head>
If the release body already exists, treat it as one source, not ground truth. Re-check important claims against PRs when wording matters.
2. Build a triage sheet
Review each PR or commit and record:
- title
- PR number
- area or model family
- user-facing summary
- category
- decision:
include,merge-into-summary,ignore - reason
Ignore or merge away low-signal items such as:
- typo-only docs
- trivial CI maintenance with no release impact
- internal cleanup with no user-visible outcome
- duplicate fixes already covered by a stronger umbrella PR
3. Convert engineering changes into release language
Write for users, not for the merge log.
Prefer:
- "Added support for FLUX.2-dev and FLUX.1-Kontext-dev"
- "Improved Qwen3-TTS latency and streaming stability"
- "Expanded TP/SP/HSDP support for diffusion serving"
Avoid:
- PR-title fragments
- implementation-only detail with no user impact
- one bullet per PR when several PRs clearly belong to one theme
4. Write the Highlights block first
The opening should do three things:
- state release scale or context when useful
- summarize the main story of the release in 1 paragraph
- list 4-8 key improvements that a user should scan first
Recent vLLM-Omni releases consistently lead with:
- upstream rebase or alignment
- major model support expansion
- serving/runtime architecture changes
- performance or production-readiness gains
- quantization / distributed / platform coverage
RC releases should also use the same final-release narrative template. Keep the rc version identifier in the title and opening copy, but do not switch to a separate RC-only structure.
5. Expand into themed sections
Choose section headings from the historical section bank in references/past-release-note-patterns.md. Do not invent a brand-new taxonomy unless the release genuinely needs it.
Rules:
- keep section order stable
- group related PRs into one paragraph or bullet cluster
- mention representative PR numbers, not every PR
- preserve important caveats, flags, and compatibility notes
6. Add notes and breaking changes explicitly
If a release includes:
- upgrade caveats
- manual dependency bumps
- hardware/backend limitations
- experimental support
- incompatible default changes
surface them in ### Breaking Changes, ### Note, or a short dedicated paragraph. Do not bury them in a generic feature section.
Section Selection Rules
Use this mapping as the default:
| Change type | Preferred section |
|-------------|-------------------|
| New model family, new checkpoints, new modality coverage | Expanded Model Support or Model Support |
| Throughput, latency, startup, cache, memory, scheduler gains | Performance Improvements or the relevant domain section |
| Refactors that change serving/runtime capability | Core Architecture & Runtime or Inference Infrastructure & Parallelism |
| Qwen3-TTS, MiMo-Audio, Fish Speech, omni speech serving | Text-to-Speech Improvements or Audio, Speech & Omni... |
| Diffusion runtime, image/video serving, TeaCache, DiT execution | Diffusion, Image & Video Generation |
| INT8, FP8, GGUF, unified quantization, CPU offload compatibility | Quantization & Memory Efficiency |
| Frontend, OpenAI API behavior, Helm, integrations, RL pipelines | Serving & Integrations or Frontend & Serving |
| ROCm, NPU, XPU, CI coverage, distributed platform support | Platforms... or Hardware Support |
| Docs refresh, benchmark infra, release pipeline, nightly coverage | CI, Benchmarks & Documentation |
Writing Rules
- Prefer one paragraph plus grouped bullets over a long flat bullet list
- Mention PR numbers in
(#1234)form after the claim - Keep claims specific and user-facing
- If several fixes land for one model, merge them into one sentence
- Do not overstate internal refactors; explain what they unlock
- Keep
What's ChangedandNew Contributorsas GitHub-generated appendices if they already exist
Validation Checklist
- [ ] RC and final releases both use the Final Release Template structure
- [ ]
current tagis the tag of the release being written - [ ]
previous tagfollows the release-boundary rule: previous final for finals, previous final or RC for RCs - [ ] Opening paragraph states the release story clearly
- [ ] Highlights contain only the most important user-facing items
- [ ] Section headings match historical vLLM-Omni patterns
- [ ] Pure maintenance noise is omitted or merged away
- [ ] Important caveats, flags, and breakages are explicit
- [ ] PR numbers and model names are accurate
- [ ] Any uncertain claim is marked in
4-release-note-review.md
Research Tips
- For ambiguous PRs, inspect the PR body via
https://api.github.com/repos/vllm-project/vllm-omni/pulls/<number> - Use the compare API to avoid missing merged work between tags
- If a release reuses content from an RC, make the delta versus the prior RC explicit
- When a refactor is large, summarize the user-visible consequence instead of enumerating files
References
- past-release-note-patterns.md - Historical release-note structure, style evolution, and section bank
- release-note-template.md - Copyable Final Release Template used for both RC and final releases
Related Skills
hsliuustc0106/vllm-omni-pre-check
development
VerifiedTrustedCommunity
Use before submitting a PR to vllm-project/vllm-omni — self-check the branch against project conventions, catch dead code, verify accuracy/performance claims, and confirm merge readiness. Use when the user says "pre-check", "self review", "pre-submit check", or "check my PR before I open it."
69SKILL.mdUpdated May 29, 2026
hsliuustc0106/skills/vllm-omni-test-report
development
VerifiedTrustedCommunity
--- name: vllm-omni-test-report description: Two report kinds; **default output is always HTML** unless the user explicitly asks for Markdown (.md). **Release** — `scripts/compose_full_report.py` (**测试结论**, Buildkite metrics, **Test Result** = Common stack + optional `--log-dir-h*` nightly-style summaries + H100/CI block, **Issue tracking** = GitHub `ci-failure` + *local test* in:title, Open bugs); use `--format markdown` only when the user wants .md or `patch_report_*.py`. **Nightly** — `script
69SKILL.mdUpdated May 3, 2026
hsliuustc0106/vllm-omni-review
testing
VerifiedTrustedCommunity
Review PRs on vllm-project/vllm-omni by routing to the right domain skills, checking critical evidence, and focusing comments on blocking issues. Use when reviewing pull requests or local branches, triaging review depth, running detailed or default review, or checking tests, benchmarks, and breaking changes in vllm-omni.
69SKILL.mdUpdated May 3, 2026
hsliuustc0106/vllm-omni-video-gen
data-ai
VerifiedTrustedCommunity
Generate videos with vLLM-Omni using Wan2.2 and other video generation models. Use when generating videos from text, creating videos from images, configuring video generation parameters, or working with text-to-video or image-to-video models.
67SKILL.mdUpdated May 3, 2026