用途：按 docs/releasing.md 执行生产发布流程，该文档为流程的权威说明，本技能是交互式操作手册。调用本技能即视为允许创建并推送发布标签，但推送前须与用户确认版本号。
主要步骤：
- 预检：确认处于 main 分支、工作区干净、本地 main 与 origin/main 一致，否则中止并报告。
- 确定版本（YYYY.M.N）：用 git tag --sort=-creatordate | head -5 查看；若最新标签为当月则末位加一，否则当月从 .1 开始。
- 打标签前确认该提交 CI 为绿。发布工作流同样依赖 frontend-tests（Lint、单元测试、e2e）。先用 gh run list --workflow "Dev - Docker Images" --branch main --limit 5 --json headSha,status,conclusion,databaseId 检查；绿则继续，红则用 gh run view <id> 诊断并先在 main 修复，然后从第 1 步重来；仍在运行或缺失时可先跑本地快速检查：根目录 pnpm format:check、受影响包的单元测试（如 cd frontend/apps/desktop && pnpm exec vitest run；cd agents && bun test），跳过 e2e、后端和构建等慢速套件。
- 与用户确认版本号和待打标签的提交。
- 打标签并推送：git tag <version> && git push origin <version>。
- 等待发布工作流（Release - Desktop App、Release - Docker Images）变绿：gh run list --workflow release-desktop.yml，再用 gh run watch <run-id>；构建耗时较长，需持续等待，失败则停止并报告。
- 为 <prev-tag>..<version> 起草发布说明，遵循 releasenotes 技能的语气、分组与排除规则，并匹配最近几次已发布版本的格式（gh release view <prev-tag>）：功能条目尽量简短，常把多个提交合并为一行；不记录上一标签后引入又修复的回归；结尾附 Full Changelog 对比链接。向用户展示草稿并按修改意见调整后发布：gh release edit <version> --notes-file <tmpfile> --prerelease=false --latest。
- 发布 latest.json 供桌面端自动更新：gh workflow run "Generate latest.json (prod)" 并确认运行成功。
- 报告：版本、发布 URL 及各步骤状态。
限制：具体流程细节以 docs/releasing.md 为准；未提供收费、价格等信息。