用途：当用户需要发布推文、上线推文、X 公告、发布线程、把 changelog 改写成推文，或为已发布版本撰写社媒文案时使用。该技能专注于发布文案，不负责执行发布流程。
写作前的事实依据：先阅读相关的 CHANGELOG.md 段落或 GitHub release notes；核对适用于项目的 tag/release/npm/appcast/制品状态；区分 Unreleased、beta/预发布、稳定版、hotfix 与更正版本。不能仅因功能出现在 changelog 顶部就宣称已发布，应确认 tag/release/包证据。优先突出用户可见的成果：功能、集成、工作流改进、安装/更新可靠性、安全修复；避免以 CI、覆盖率、验证、重构、内部迁移或发布机制开头，除非那正是重点。若证据不完整，应说明未验证之处，并用更谨慎的措辞起草。
上线推文格式：一条不超过 280 字符的标准推文，预留一个 URL 位置。典型结构为产品+版本、空行、3–4 条紧凑的 emoji 引导功能要点、空行、一句简短点睛语、release/changelog URL。默认使用与功能或产品匹配、清晰低噪音的 emoji，除非用户要求纯文本或属于事故类发布。语气高信号、紧凑、自信，最多一个玩笑。发布前统计原始字符数。
Beta、Hotfix 与更正：beta/预发布需明确 beta 状态，避免暗示已晋升稳定版；hotfix/更正应直接负责，说明出了什么问题、已修复什么、新版本号，除非用户要求轻松语气否则不加玩笑。
线程：先就通用上线推文达成一致，再逐条撰写后续回复，用户说 next 时只给下一条。每条后续聚焦一个功能或用户工作流，尽量附对应功能文档/发布 URL，避免重复版本号。后续推文建议 160–220 原始字符，上限 280。
发布与剪贴板：默认只起草，除非用户明确要求否则不发布到 X/Twitter。要求复制时，在 macOS 用 pbcopy 并报告已复制。要求从 Peter 的环境发布时，优先使用可用的本地 bird/xurl 工作流，然后核实已发布 URL。绝不虚构媒体；需要媒体时使用已有发布截图/素材，或另行索取/生成。
质量检查：每条推文字符数低于 280；版本字符串和渠道准确；按需包含发布 URL；无未经验证的说法；上线推文最多 3–4 条 emoji 要点；用 Peter 风格简洁语言，先删冗余再删事实。
限制：该技能不负责切割发布；缺少 tag、release、npm、appcast 或制品证据时无法确认真实发布状态；媒体素材需另行提供或生成；未提供具体发布命令、平台 API 或收费信息。