将 Slack 版本更新转化为面向客户的版本说明草稿

概览

Computer 自动化每小时检查一次 Slack，查找已确认面向客户的版本，审查链接的 GitHub 更改、Linear 问题以及 Notion 中的产品项目，然后检查以前的版本说明是否存在重复项和批准的命名。它无需发布或发送，即可准备一份面向客户的版本说明草稿和团队摘要供审阅。

获取首个结果的时间： 在下一个每小时检查找到符合条件的发布消息后；请求立即运行以获取第一个示例。

难度： 需要设置

您需要准备的工具

• Slack 已连接并具有访问 [release channel] 的权限，以便识别已确认面向客户的版本。
• GitHub 和 Linear 已连接并具有访问链接的 pull request 和问题的权限，以便草稿反映已交付的范围。
• Notion 已连接到 [product Project]，以便经批准的面向客户的名称指导草稿编写。
• 包含先前条目和命名规则的版本说明总账，以便检查重复项和过时的名称。
• 每小时检查计划和审阅负责人，以便符合条件的更新成为用于审批的草稿，而不是已发布的说明。

查询

您将获得的内容

预定报告交付：待审阅草稿

包含虚构产品详情和说明性来源链接的演示输出。已完成草稿的摘录：

命名检查：

“产品项目确认“定时报告交付”为批准的名称。草稿逐字使用它。类别为“新”。”

重复项检查：

“没有 LIN-4955、PR-3389 或“定时报告交付”的先前条目。”

团队摘要：

“建议的版本标签 v2026.09.19-1。”

在源任务中查看完整的演示草稿和总账。

• 来源审阅：演示列出了一个 GitHub pull request、一个 Linear issue 和父级史诗任务，以及一个 Notion 产品项目。
• 命名检查：“定时报告交付”取代了旧的“报告调度程序”标签。
• 重复项检查：将功能名称、问题 ID 和 pull request 与先前的版本说明进行比较。
• 版本说明草稿：供审阅的建议标题、类别、版本标签、收益陈述和功能要点。
• 团队摘要：解释更改、命名决策和重复项检查的草稿 Slack 问题回复。
• 版本说明总账：用于后续审阅的三个说明性先前条目和命名约定。

以 Markdown 草稿和单独的 Markdown 总账形式交付，随时可供审阅和修订；演示未显示已发布的版本说明或已发送的 Slack 回复。

加以改进

• 添加上下文：包含已批准的版本说明和确认的计划可用性，以指导措辞和资格声明。
• 指出具体信息：命名定义版本的 Slack 频道、GitHub 仓库、Linear 团队和 Notion 项目。
• 请求格式：在每个草稿中请求客户收益、可用性声明、功能要点和来源参考。
• 使用技能：将批准的版本说明结构和命名规则保存为可重用的技能。
• 使其周期性运行：指定检查时间和时区，并在没有符合条件的更改出现时保持静默。

尝试变体

审阅 [Slack ship-message link]、其链接的 GitHub 更改、相关的 Linear issues 以及 [product Project in Notion]。检查 [release notes ledger] 是否存在重复项和批准的命名。为审阅起草一个 Markdown 版本说明条目和团队摘要。请勿安排、发布或发送任何内容。

每小时检查一次 [Slack channel]，寻找 [GitHub repository] 中已交付的面向客户的错误修复。审查相关的 Linear issues、[product Project in Notion] 和 [release notes ledger]。在“修复”类别中起草 Markdown 条目以及供审阅的团队摘要。请勿发布或发送任何内容。

在每个 [Friday at time and time zone]，对照链接的 GitHub 更改、Linear issues、[product Project in Notion] 和 [release notes ledger]，审阅 [Slack channel] 中已确认的版本。创建一个包含客户收益、批准名称和重复项检查结果的单页 Markdown 版本摘要。保留待审阅。

相关用例

• Computer 在 Slack 中发送每日产品开发摘要：使产品团队在决策和实施更改成为版本公告之前保持意见一致。
• 自动化帮助中心文章：将产品文档转化为帮助文章，解释如何使用新发布的功能。
• 为您的公司检测过时的落地页：将公开页面与最新版本说明进行比较，以便在发布后标记过时的声明。