OneOS1.2/.cursor/skills/AutoVUL/SKILL.md

name, description

name	description
AutoVUL	Generates OneOS PC version update logs from a Yunxiao (云效) iteration name by loading all linked requirements, or from a pasted changelog list. Use when testers or PMs say AutoVUL, 版本更新日志, 按迭代生成更新日志, 发版公告, or give a 迭代名称.

AutoVUL（OneOS PC 版本更新日志）

面向测试人员发版：输入云效迭代名称 → 拉取该迭代关联需求 → 自动生成对外版本更新日志。

也可手动粘贴变更清单（兜底）。预计维护时长由人工单独通知，不写进日志。

何时使用

• 测试说：按 $AutoVUL / 生成版本更新日志 / 按迭代 xxx 出更新日志
• 输入含云效「迭代名称」
• 发版前需要统一文案口径

主流程（测试 · 按迭代，默认）

完整取数步骤见 references/yunxiao-sprint.md。

1. 确认云效项目（缺省：统一运营管理平台PC端；可改）
2. 向用户索取「迭代名称」（若口令里已带则直接用）
3. 在云效查找该迭代 → 立即反馈成功或失败（见下）
4. 成功：列出迭代内关联「需求」清单（编号 + 标题 + 状态）供用户快速核对
5. 从每条需求提取变更素材（优先级见「素材优先级」）
6. 按本文格式分类、合并、润色 → 输出成稿正文

迭代读取 · 成功 / 失败反馈（强制）

查找迭代后必须先反馈，再继续或停止：

结果	反馈文案（可微调，语义不变）	下一步
精确命中 1 个迭代	✅ 已找到迭代「{名称}」（状态：{状态}），关联需求 {N} 条。	继续拉需求并生成
0 个匹配	❌ 未找到迭代「{输入}」。请核对后重新输入迭代名称（可复制云效迭代标题）。	停止生成；等待用户重输
多个模糊匹配	⚠️ 找到多个相似迭代：1)… 2)… 请回复序号或完整精确名称。	等用户选定后再继续
登录/权限失败	❌ 无法访问云效（未登录或无权限）。请在浏览器登录云效后重试，或改用手动清单。	停止；提示登录或兜底
迭代存在但 0 条需求	⚠️ 迭代「{名称}」已找到，但暂无关联需求。请确认规划后再试，或改用手动清单。	停止生成对外正文

失败后：用户只需再发一次迭代名称（或纠正项目名），从步骤 2 重跑；不要要求用户重装 Skill。

素材优先级（每条需求）

顺序	来源	用法
1	需求描述中的「更新内容」段（非「更新内容·历史」）	首选，直接改写成日志条目
2	AutoPRD「功能变更记录」中可对外部分	次选
3	需求标题 + 简短描述摘要	仅当前两者皆空时；价值句可合理补全
—	纯技术债、内部监控、未对用户开放	不写入对外日志

Bug 类需求（类型/标签含缺陷修复、或更新内容写「修复」）归入【Bug修复】；其余归【新功能】。边界不清优先 Bug修复。

版本号与更新时间

字段	规则
版本号	优先从迭代名解析（如含 V1.1.5 / 1.1.5）；解析不到再问用户
更新时间	用户提供则用；未提供可写迭代计划开始日的 MM月DD日HH:MM，或先问
产品线	默认 OneOS PC版

兜底流程（手动清单）

无云效权限、或迭代为空时：用 input-template.md 粘贴清单，跳过迭代步骤，直接分类润色。

固定输出格式

OneOS PC版V{主.次.修订}更新日志：
更新时间：{MM}月{DD}日{HH}:{MM}
----------------------------------------------------
【新功能】
1「{模块名}」{做了什么}，{责任部门}可{用户价值 / 解决的问题}
2「{模块名}」{…}

【Bug修复】
3「{模块名}」{修复了什么}，{责任部门}可{恢复的能力 / 避免的影响}

版式硬约束

项	规则
标题	OneOS PC版V + 版本号 + 更新日志：（如 V1.1.5，无空格）
更新时间	仅开始时刻；MM月DD日HH:MM；禁止「预计x分钟内完成」
分隔线	----------------------------------------------------
分区	仅 【新功能】 / 【Bug修复】；空类整段省略
序号	全篇连续，从 1 起
模块名	「」；与产品菜单正式名一致
对外正文	不写需求号、缺陷号、迭代 ID（核对清单可另附）
结尾	无签名、无「感谢使用」、无技术附录

分类 / 合并 / 文案（成稿规则）

归入【新功能】	归入【Bug修复】	不写进对外日志
新增能力、新入口、新字段/流程、可感知体验优化	原有能力异常、报错、数据错、交互失效	技术债、无感性能、未开放灰度、仅内部监控

• 同分区同模块合并为一条，分点用 ；
• 跨分区同模块分栏各写一条
• 每条含：做什么 + 用户价值 + 责任部门自然嵌入（{部门}人员可…）
• 禁止「供…条线…使用」；部门对照 module-role-mapping.md
• 禁止编造迭代内不存在的能力；存疑跳过或标待确认（不进正式成稿）
• 单条建议 ≤100 字

排序：先新功能后修复；同分区全员影响优先；资金/合规修复置修复区最前。

输出纪律

1. 先输出迭代读取反馈（✅/❌/⚠️）
2. 成功时：可先给「本迭代需求清单」短表（含编号，便于测试核对）
3. 再输出纯文本成稿正文（默认不要 Markdown 大标题包裹成稿）
4. 用户明确要求时，可在正文后附「分类依据 / 跳过项」

发布前自检

• 已反馈迭代查找结果；失败时未强行编造成稿
• 成稿条目均可追溯到本迭代关联需求素材
• 标题、时间行、分隔线正确；无预计时长
• 同模块合并正确；每条含价值 + 部门自然嵌入
• 对外正文无需求号/缺陷号/技术黑话；序号连续

给测试同事的口令

按 $AutoVUL 生成版本更新日志。
项目：统一运营管理平台PC端
迭代名称：V1.1.5发版迭代
更新时间：07月16日16:00

迭代名写错时，按提示改完再发一次即可。

手动兜底见 input-template.md；成稿范例见 examples.md。