菜单
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
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| 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 |
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.
vLLM-Omni release note from merged PRs or a GitHub compare viewWhat's Changed dump into a user-facing summaryv0.12.0rc1 to v0.18.0 structureDo not use this skill for changelog generation in unrelated repos.
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 checksIdentify:
v0.18.0Tag selection rules:
current tag is the tag of the release being written, and previous tag is the previous final release tag.current tag is the tag of the RC being written, and previous tag is the immediately previous final or RC release tag.Examples:
v0.18.0 means current tag = v0.18.0, previous tag = v0.16.0v0.18.0rc1 means current tag = v0.18.0rc1, previous tag = v0.17.0rc1 or v0.17.0, whichever is the most recent prior final/RC tag in the release chainUse 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.
Review each PR or commit and record:
include, merge-into-summary, ignoreIgnore or merge away low-signal items such as:
Write for users, not for the merge log.
Prefer:
Avoid:
The opening should do three things:
Recent vLLM-Omni releases consistently lead with:
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.
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:
If a release includes:
surface them in ### Breaking Changes, ### Note, or a short dedicated paragraph. Do not bury them in a generic feature section.
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 |
(#1234) form after the claimWhat's Changed and New Contributors as GitHub-generated appendices if they already existcurrent tag is the tag of the release being writtenprevious tag follows the release-boundary rule: previous final for finals, previous final or RC for RCs4-release-note-review.mdhttps://api.github.com/repos/vllm-project/vllm-omni/pulls/<number>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.
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** — `scripts/nightly_local_log_report.py` from local `nightly_jobs` (fetch: vllm-omni-nightly-local) plus optional latest Buildkite scheduled nightly when token is set; use `--markdown-report` / `--to-stdout markdown` only when the user asks for Markdown. Use when generating Buildkite release summaries, parsing local nightly_jobs with CI cross-check, or opening https://buildkite.com/vllm/vllm-omni/builds?branch=main for CI documentation.
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."
Generate audio and speech with vLLM-Omni using Qwen3-TTS, Fish Speech S2 Pro, CosyVoice3, MiMo-Audio, and Stable-Audio models. Use when synthesizing speech from text, generating audio effects or music, configuring TTS parameters, cloning voices, adding new TTS models, or working with text-to-speech models.
Contribute to vLLM-Omni by adding new model support, fixing bugs, or improving features. Use when integrating a new model into vllm-omni, setting up a development environment, writing tests, or submitting pull requests to the vllm-omni project.
Scale vLLM-Omni across multiple GPUs and nodes using tensor parallelism, pipeline parallelism, OmniConnector disaggregation, connector backends, and Ray. Use when setting up multi-GPU inference, distributing model execution across machines, deploying disaggregated execution, developing OmniConnector backends, or scaling inference horizontally.