用途：把原始工单转化为面向用户的发布说明，减少人工筛选和改写工作。该技能会从指定工单来源中读取在指定时间窗口内标记为 done、shipped、merged 或 closed 的条目。
主要能力：过滤内部工作，包括进行中、纯内部、无可感知 UX 变化的 bug 修复、琐事、重构，以及标记为 internal、infra 或 ops 的条目；按工单标签或项目名进行分组，少于 2 个条目的区域会被合并到最接近的分组；按区域生成标题（2–5 个词，使用现在时和功能名称，避免 added、fixed、shipped）和面向用户的描述（1–3 句，以 what changed 和 why it matters 为主，使用“you can now…”句式，不使用项目符号，不出现工单 ID、冲刺名或工程师姓名）；顶部写日期，按区域分组，保存为 ReleaseNotes_YYYY-MM-DD.docx 到指定输出文件夹，仅供审核，不直接发布。若未找到工单，会说明检查了哪些来源。
使用方式：运行 /schedule，并填写三个占位符：{{TICKET_SOURCES}}（例如 Linear、Jira 或 GitHub Issues）、{{TIME_WINDOW}}（例如 the past 7 days、the past 2 weeks 或 this sprint）、{{OUTPUT_FOLDER}}（例如 /Product/ReleaseNotes）。需要连接 Linear / Jira / GitHub Issues 和 Google Drive 的 MCP。可手动在每次发布前运行，或每周运行。
适用场景：适合需要定期输出用户可见发布说明的产品或工程团队。良好工单习惯会提升输出质量，描述中写明“users can now…”效果最佳。可与 update-knowledge-base 搭配，标记发布后需更新的帮助文章。API 或 webhook 变更可保留独立标签，以便获得不同的技术口吻。
限制：必须配置对应 MCP 和工单来源；输出为 .docx 并需人工审核，不负责发布；依赖工单本身的状态和标签质量，无法保证覆盖所有变更。