技能介绍

解决什么问题

在 Slack 里做自动化时，很多团队卡在同一个位置：用 curl 手动发消息、用 https://hooks.slack.com 的 incoming webhook 拼回复，一旦要加按钮、输入框或下拉菜单就无从下手。原生的 Webhook 只负责投递，不负责接收回传的事件；而事件订阅的签名校验、令牌管理、重试与交互回包的路由，每一项都足够分散注意力，让真正重要的流程逻辑被淹没在胶水代码里。

这个技能面向的正是这个场景：把 Slack 的事件与交互层交给 Bolt.js 处理，让你的代码只关心业务。

它如何工作

核心能力围绕三类入口，对应三种监听器：

Slash 命令：通过 app.command() 注册 /your-command，用户在频道或 DM 里输入时触发，适合做快捷查询、触发流水线、登记状态等。
Modal 弹窗：用 views.open() 打开一个模态框，把表单收集、二次确认这类操作从主频道里移出去，用户填完直接回传数据，避免在对话流里来回拉扯。
消息快捷操作：给已有消息挂上 action listener，按钮点击后处理 action_id 对应的逻辑，例如一键审批、一键指派。

界面部分统一走 Block Kit：消息里嵌入按钮、输入框、下拉选择、静态文本块等组件。这类组件由 Slack 客户端渲染，不需要你写任何前端样式或 CSS，交互结果通过回调直接回到你的服务端。

落地时的典型顺序是：先在 Slack API 后台建好 app，拿到 Bot Token 并订阅需要的事件与交互权限，再把 Request URL 指向你的服务，路径必须是 /slack/events，最后用 Bolt.js 的 app 实例把上述三类 listener 接上。由于每个 listener 的 payload 结构不同，事件订阅和按钮点击拿到的字段并不一致，按 listener 类型分别解析是合理做法。

适用边界与注意点

这个技能负责的是服务端接入与交互编排，不涉及前端页面。如果你的流程需要复杂的自定义网页，应该用 Block Kit 能承载的组件，或在消息里放链接跳转到独立页面。
上游文档里提到 Request URL 的路径要严格对应 /slack/events，配置不匹配会导致事件投递失败，排查时要优先确认这一点。
Slack 对 modal 有尺寸和层级的限制，嵌套过深的视图会被客户端截断，交互设计上建议保持单层弹窗。
生产环境还需要考虑签名校验、令牌轮换、请求超时和并发投递这几个运维问题，技能本身不替你解决这些。
适合的场景是内部工具型机器人：团队内的查询、登记、审批流。面向大量外部用户的公开 bot 还需要额外关注速率限制和租户隔离。