release-tweets

发布推文

当用户要求撰写发布推文、上线推文、X 公告、发布串文、将更新日志改写成推文，或为已发布版本撰写社交媒体文案时使用此技能。此技能用于撰写发布文案，而非执行发布。

以事实为依据撰写文案

• 撰写确定的文案前，先核实发布目标：
  • 阅读相关的 CHANGELOG.md 部分或 GitHub 发布说明
  • 检查适用于该项目的标签、发布、npm、appcast 或构建产物状态
  • 区分 Unreleased、beta／预发布版、稳定版、热修复版和更正版本
• 不能仅因为某项功能出现在更新日志顶部区块，就声称它已发布。可获取相关证据时，先确认标签、发布或软件包状态。
• 优先突出用户可见的成果：功能、集成、工作流改进、安装／更新可靠性、安全修复。
• 除非这才是重点，否则不要以 CI、覆盖率、验证、重构、内部迁移或发布机制作为开头。
• 如果证据不完整，请说明哪些内容尚未核实，并采用更审慎的措辞起草。

上线推文格式

• 标准推文不超过 280 个字符，并预留一个 URL 的空间。
• 常见格式：
  • 产品 + 版本
  • 空行
  • 3-4 条简短的 emoji 功能要点
  • 空行
  • 一句简短的点睛语
  • 发布／更新日志 URL
• 上线推文默认使用 emoji 项目符号。选择清晰、简洁且符合功能或产品的 emoji；只有用户要求纯文本或发布属于事故处理时才省略。
• 语气：信息密度高、简洁、自信；有依据时可以略带冷幽默。避免企业腔。
• 最多一个笑点。让功能要点承担主要表达。
• 将发布／更新日志 URL 放在末尾。
• 将最终原始字符数控制在限制以内后，再标注为可直接发布。

Beta、热修复、更正

• Beta／预发布版：
  • 明确说明 beta 状态
  • 避免让人误以为已升级为稳定版
  • 根据情况使用“beta N”、VERSION-beta.N 或“预览版”等表述
• 热修复／更正版本：
  • 直接说明并承担责任
  • 说明遗漏了什么、修复了什么，以及新版本号
  • 除非用户要求轻松一点的语气，否则不讲笑话

串文

• 先就通用上线推文达成一致。
• 然后逐条撰写后续推文。用户说 next 时，只提供下一条回复。
• 每条后续推文应聚焦一项功能或一种用户工作流。
• 如有对应的特定功能文档／发布 URL，请附上。
• 如果串文上下文中已经提到版本，不要在每条回复中重复版本号。
• 后续推文的理想长度：160-220 个原始字符。硬性上限：280 个字符。

发布与剪贴板

• 默认只起草文案。除非用户明确要求，否则不要发布到 X/Twitter。
• 如果用户要求复制，在 macOS 上使用 pbcopy，并告知已复制。
• 如果用户要求通过 Peter 的配置发布，优先使用可用的本地 bird／xurl 工作流，然后核实已发布的 URL。
• 绝不虚构媒体素材。用户需要媒体时，使用现有的发布截图／素材，或另外询问是否需要生成。

质量检查

完成前：

• 每条推文均少于 280 个字符。
• 版本字符串和发布渠道准确无误。
• 按需或按惯例附上发布 URL。
• 不包含未经核实的说法。
• 上线推文中的 emoji 要点不超过 3-4 条。
• 使用 Peter 风格的简练表达；删减赘词时优先保留事实。

示例

OpenClaw 2026.4.20 beta 1

🐳 Docker install/update smoke
🖥️ Parallels upgrade checks
🔧 Package verification tightened

Beta first. Stable after the gauntlet.
<release link>

RepoBar 0.5.0 is live

📋 GitHub refs from your clipboard
🔎 Issue, PR, and commit previews
🟢 Open/closed/merged at a glance
🔒 No Accessibility permission needed

Tiny bar, much less mystery.
<release link>

Packaging issue in 2026.4.20-beta.1.

2026.4.20-beta.2 fixes install/update verification. No tag rewrites; beta moves forward.

Upgrade with the beta channel.
<release link>