技能介绍

要解决什么问题

你在做 Slack 类实时协作、Bot 或企业集成时，容易卡在几件事：WebSocket 与 Events API 选型不当导致轮询打满限流；大频道 fanout 放大延迟；OAuth scope 过大、Modal 三秒内未 ack、消息缺 fallback 文本等集成细节；以及「看起来像工作」的会议与状态同步占用工程时间。本技能把 Slack 公开工程实践与岗位视角整理成可执行的上下文与清单，而不是泛泛讲「怎么用聊天工具」。

技能如何工作

核心能力覆盖五条主线：

实时消息架构 — Channel / Gateway / Presence 等服务的职责划分，以及消息从客户端到 Channel Server 的路径
Vitess MySQL 分片 — 以 channel-id 为分片键的水平扩展思路，与 consistent hashing、CHARM 类 failover 概念
Bolt SDK — Node.js / Python 下 API-first 的 Bot 开发入口
Block Kit — 交互式消息与 UI 组件的设计参考
API 集成 — 目录规模与自定义 App 生态下的 scope 最小化、token 轮换、40KB payload、重试与幂等

文档还嵌入 Slack 工程文化（如「不卖马鞍」的产品定位、Work Hard and Go Home、Default to Open）和 Hyper-Realistic Work-Like Activity 框架，用于在方案阶段区分真有价值的工作与应淘汰的伪忙碌。

执行侧可按内置 Workflow 走：Assessment → Planning → Execution → Review；技术决策可用加权准则（Quality / Efficiency / Accuracy / Safety）与 §8 风险表（Polling vs WebSocket、Unbounded Fanout、Token Leakage、Modal Timeout 等）做对照。

适用边界与注意点

内容偏 Slack 官方架构叙事与工程博客 的归纳，不替代你方生产环境的容量规划与压测数据
SKILL.md 中部分章节（如 §7.2 Regional Failover、§8.2 Scaling Risks）在资料里未展开完整条目，落地时需自行补全验证清单
哲学与文化段落用于对齐产品/协作决策，不能当作具体 SLA 或合规承诺；消息投递 SLA 仍以你接入的 API 版本与区域为准

截图预览

使用场景

企业内网 Bot 需用 Events API 订阅频道消息，避免轮询触发 rate limit，要对照技能里的集成审查清单做 scope 与重试设计
上线带 Block Kit 按钮与 Modal 的 Slack App，需在 3 秒内 ack 并异步处理，同时保证通知带 fallback 文本
自建或改造类 Slack 消息后端，需理解 Channel Server 分片与 consistent hashing，评估 channel-id 作分片键的方案
大频道广播或 fanout 场景出现延迟放大，要按风险表排查 tiered delivery 与 WebSocket 路径而非继续加轮询

适合人员

负责企业 Slack App 上架与 OAuth 审批的后端，需要最小化 scope、实现 token 轮换与幂等调用
用 Node.js 或 Python Bolt 开发运维/审批 Bot，要正确接 Webhook、Modal 与 Block Kit 模板的集成工程师
做 IM 或协作产品中台的技术负责人，想借鉴 Slack 公开的分层服务与 Vitess 分片叙事做架构评审
在方案评审里要砍掉「会前会、无人读的状态同步」类伪忙碌，希望用 Hyper-Realistic Work-Like Activity 框架对齐排期的 Tech Lead