技能介绍

它解决的问题

团队做同步时，最耗时的不是写消息，而是把散落的信息拼起来：翻 git 提交、扫聊天频道、看 issue 和任务、确认哪些反馈需要回复。人工处理容易遗漏最近关闭的 issue、漏掉 @ 到自己的提问，或把消息写成“过程流水账”而不是队友关心的交付结果。更麻烦的是，每次要重新确认发布频道、消息风格、分诊规则，重复劳动且易错。

它如何工作

技能的核心是 playbook 优先：首次运行时探测可用的聊天、Git、issue 工具，询问发布频道、身份、消息风格、分诊规则等偏好，然后保存为 playbook，后续运行直接读取执行。

阶段 0：Playbook 检查：存在 playbook 则直接加载配置，否则先探测工具能力（聊天、Git、issue、任务、知识库），缺失则回退为手动发布。
阶段 1：收集上下文：按 playbook 里的上次运行时间戳确定时间窗（默认 24 小时），从 Git 提交、频道消息、issue/PR、任务中收集信息，按主题聚合提交，记录关闭的 issue、合并的 PR、完成的任务，标记需要回复的团队消息。
阶段 2：起草与发布：按 playbook 的消息风格撰写（先讲交付/变化、按主题分组、@ 具体人），预览草稿后需明确批准才发布，无聊天工具则输出格式化文本。
阶段 3：反馈分诊：读取发布后的频道消息，按 playbook 规则分类为 Bug、功能请求、提问、阻塞、安全 concern 等，呈现摘要后需批准才执行动作。

适用边界与注意点

必须明确批准：发布到频道、建 issue、回复发问等动作，都需用户明确批准后才执行，绝不自动发布。
playbook 的隐私：playbook 含发布频道、身份、分诊规则等敏感信息，必须保存在被 .gitignore 忽略的目录，不应提交到仓库。
安全 concern 的处理：发现安全相关问题时，立即标记呈现给用户，不建公开 issue。
不替代真实沟通：技能产出的是文案和计划，复杂问题仍需人工沟通确认。