team-update

团队动态

将项目动态发布到团队聊天中，阅读并整理反馈，规划后续步骤。根据可用的沟通和项目工具进行适配。

Playbook 模式

此技能在项目根目录的 .claude/team-update-playbook.md 文件中使用一个 playbook。

• 首次运行：发现可用工具，询问用户偏好，执行操作并保存 playbook
• 后续运行：读取 playbook，跳过发现步骤，直接执行
• 用户编辑 playbook：更改立即生效（频道、风格、整理规则）

playbook 是用户可编辑的纯 Markdown 文件。它记录工具配置、频道偏好、消息风格、整理规则和上次运行的元数据。

---

阶段 0：检查 Playbook

检查项目根目录中是否存在 .claude/team-update-playbook.md。

如果存在：读取它。所有工具配置、频道信息、消息风格和整理规则都在其中。带着已知配置跳转到阶段 1。

如果不存在：先运行阶段 0b（发现）。

---

阶段 0b：发现（仅首次运行）

检查已连接的 MCP 工具和本地工具，检测可用功能。

阅读 references/discovery-patterns.md，了解检测模式。

功能检测

检查以下各类功能：

功能	检测方法	缺失时的回退方式
聊天	查找名称匹配 chat、slack、discord、teams 的 MCP 工具	输出格式化文本，供手动发布
Git	git rev-parse --is-inside-work-tree	跳过提交摘要
问题	查找名称匹配 github、linear、jira 的 MCP 工具	跳过或输出文本列表
任务	查找名称匹配 tasks、todos、asana 的 MCP 工具	跳过或输出文本列表
知识	Basalt Cortex（~/Documents/basalt-cortex/）	搜索相关知识笔记

用户偏好（询问）

发现完成后，请用户确认：

1. 频道：要将动态发布到哪个聊天空间/频道？（列出发现的选项）
2. 身份：以你本人还是机器人身份发布？（例如 Anthro Morphic）
3. 仓库范围：要跟踪哪些仓库？（默认：当前仓库）
4. 消息风格：简短站会汇报、详细更新日志，还是对话式动态？
5. 团队背景：有哪些需要留意的团队成员？（姓名、角色）
6. 整理规则：处理反馈时是否有自定义规则？（或者使用默认规则）

保存 Playbook

发现工具并收集用户偏好后，将 playbook 保存到 .claude/team-update-playbook.md。

阅读 references/playbook-format.md，查看完整模板。根据发现的工具和用户偏好填写所有部分。如果未找到某项功能，在 playbook 中将其标记为“不可用”。

确保 .claude/ 位于 .gitignore 中（playbook 包含不应提交的空间 ID 和偏好设置）。

---

阶段 1：收集上下文

从所有可用来源收集信息。查看 playbook 的“数据来源”部分，了解要调用哪些工具。

1a. 确定时间范围

查看 playbook 的“上次运行”部分，获取上次更新的时间戳。如果没有上次运行记录，请询问用户要回溯多长时间（默认：24 小时）。

1b. 收集数据

从每个可用来源收集信息：

来源	收集内容	工具
Git 提交	git log --oneline --since=<last-update>	Bash
聊天消息	自上次更新以来配置频道中的消息	playbook 中指定的聊天 MCP 工具
未解决的问题/PR	最近更新或新建的条目	playbook 中指定的问题跟踪工具
进行中的任务	正在进行或最近完成的任务	playbook 中指定的任务跟踪工具

1c. 整理草稿素材

按主题归纳提交（不要逐条列出哈希）。记录已关闭的问题、已合并的 PR 或已完成的任务。标记需要回复的团队消息。

---

阶段 2：起草并发布动态

2a. 撰写消息

阅读 references/message-composition.md，了解消息格式。

遵循操作手册中的“消息风格”部分。一般原则：

• 开门见山地说明已交付或已变更的内容，而不是流程
• 将相关提交归纳为主题
• 仅在相关时提及具体人员
• 便于快速浏览（段落简短，使用项目符号）
• 像队友一样写，而不是像 AI 一样——不要堆砌表情符号、含糊其辞，也不要过度解释团队已了解的背景。请参阅 references/message-composition.md 中的“沟通风格”部分。

2b. 预览并征求批准

向用户展示草稿。包括：

• 撰写好的消息
• 将要发布到的频道
• 这是新消息还是线程回复

必须获得批准：未经用户明确批准，绝不向外部频道发布消息。

2c. 发布

使用操作手册中的聊天工具发布已获批准的消息。如果没有可用的聊天工具，则输出格式化后的消息，供用户手动发布。

2d. 更新操作手册

发布后，更新操作手册中的“上次运行”部分，记录：

• 当前时间戳
• 线程键（如适用）
• 已发布内容的简要摘要

---

第 3 阶段：阅读并分类反馈

3a. 阅读回复

阅读更新发布后配置频道中的消息。留意：

• 对更新的直接回复
• 频道中提及该项目的新消息
• 表情回应或确认

3b. 分类反馈

阅读 references/feedback-triage.md，了解分类模式。

遵循操作手册中的“分类规则”部分。默认分类如下：

类型	操作
Bug 报告	创建 issue（标签：bug）
功能请求	创建 issue（标签：enhancement）
问题	撰写回复草稿，供用户批准
阻塞事项	立即标记，并建议解决方案
确认	记录，无需采取行动
无关内容	忽略

3c. 呈现并采取行动

呈现反馈摘要和建议采取的行动：

## Feedback Summary

- Daniel: "Can we add dark mode?" -> Create issue (enhancement)
- Rabin: "Auth is broken on staging" -> Create issue (bug, priority)
- Karen: "Looks good!" -> No action

Proceed with these actions?

必须获得批准：未经用户明确批准，绝不创建 issue、发布回复或采取外部行动。

---

第 4 阶段：规划后续步骤

4a. 确定优先级

根据收集到的所有背景信息（提交、issue、任务、反馈），识别：

1. 阻塞事项：阻碍进展的事项
2. 高优先级：Bug、紧急请求、截止日期
3. 接下来处理：计划中的工作、功能请求
4. 待办事项：锦上添花的内容、低优先级事项

4b. 呈现（不发布）

向用户展示按优先级排列的列表。此列表仅供用户规划使用——请勿将其发布到任何频道。

## Suggested Priorities

1. [BLOCKER] Fix auth on staging (from Rabin's feedback)
2. [HIGH] Complete API endpoint for user profiles (current sprint)
3. [NEXT] Dark mode support (from Daniel's request)
4. [BACKLOG] Refactor database queries

---

自主执行规则

操作	级别
阅读/创建操作手册	直接执行
发现工具（首次运行）	直接执行，并向用户确认偏好
收集背景信息（git、聊天、issue）	直接执行
起草更新消息	直接执行，并展示预览
发布到外部频道	必须获得批准
创建 issue/任务	必须获得批准
向团队发布回复	必须获得批准
更新操作手册中的“上次运行”	直接执行
呈现计划/优先级	直接执行

---

优雅降级

无论工具可用性如何，该技能都能正常工作：

可用工具	使用体验
仅 Git	汇总提交，输出文本供手动发布
Git + Chat	完整的发布/阅读流程，手动创建 issue
Git + Chat + Issues	完整流程，自动创建 issue
Git + Chat + Issues + Tasks + Knowledge	完整流程，并进行持久跟踪

---

运行模式

此技能会响应不同的触发短语：

触发短语	行为
"team update" / "post update"	完整流程：收集、起草、发布、阅读反馈
"check team chat" / "what did the team say"	仅第 3 阶段：阅读并分类处理反馈
"standup" / "sync with team"	第 1 + 2 阶段：收集并发布，跳过反馈
"project update"	第 1 + 2 + 4 阶段：收集、发布、规划（跳过反馈分类处理）
"feedback loop"	第 3 + 4 阶段：阅读反馈并规划

---

参考文件

何时	阅读
首次运行 — 保存操作手册	references/playbook-format.md
首次运行 — 检测工具	references/discovery-patterns.md
撰写更新消息	references/message-composition.md
分类处理团队反馈	references/feedback-triage.md