test-slack-app

用途

Test Slack App 用于帮助开发者确认一个已经构建好的 Slack 应用是否真正可用。它是构建循环的最后一步：在 slack:create-slack-app 技能搭建应用、slack:slack-cli 技能运行应用之后，由本技能完成验证。

整体思路简单且安全：

• 在开发者沙盒或 Free Team 中运行应用（优先沙盒，或开发者为此创建的 Free Team），绝不在有真实同事的工作区中运行。
• 阅读应用源码，了解它实际监听什么。
• 给开发者具体的 Slack 操作步骤，然后帮助确认应用是否响应。

这是引导式手动检查，不是自动化测试套件：由你驱动设置并告诉开发者输入或点击什么，由开发者确认看到的结果。它最适合由 Slack CLI 管理的应用；对普通 Bolt 应用在步骤 2 中提供尽力而为的路径。

主要能力

步骤 1：搭建安全的测试环境

1a. 检测 Slack CLI

使用 slack:slack-cli 技能（步骤 1：检测 Slack CLI）检查公共 Slack CLI 是否已安装并解析其命令名。指纹检查、别名回退和安装说明都在那里，此处不重复。后文将解析出的命令统一称为 SLACK_CMD。如果 CLI 未安装，引导开发者按同一步骤安装，因为运行应用需要它。

1b. 确保有安全的工作区可用于测试

测试应放在无人使用的工作区：优先开发者沙盒，或开发者为此创建的 Free Team。绝不在有真实同事的工作区中测试。

从实时文档而非此处解释。使用 slack:slack-docs 技能获取并总结 https://docs.slack.dev/tools/developer-sandboxes.md，使建议始终反映当前文档而非可能过时的副本。告诉开发者 Slack 推荐使用沙盒来构建和测试应用。

查找当前目标。运行 SLACK_CMD auth list 查看已认证的工作区及其 team ID，并在项目目录中运行 SLACK_CMD app list 查看已安装的应用及其 ID。

确认目标安全。CLI 无法区分沙盒、Free Team 和满是真实用户的工作区，因此要询问开发者当前指向哪一个。沙盒或为此创建的 Free Team 可以；有同事的工作区不行：停止并让他们切换到前两者之一。

如果还没有安全目标，使用 slack:create-slack-app 技能（步骤 3：选择安装应用的位置）来设置，该技能负责排序目标、沙盒列表/沙盒创建流程以及 Developer Program 链接。两条路径都在浏览器中完成，因此让开发者创建工作区并登录后回到这里。

1c. 快速健康检查

在较慢的手动检查之前，用 CLI 自带的验证捕获明显的设置问题：

• SLACK_CMD doctor：检查 CLI、语言运行时和认证。
• SLACK_CMD manifest validate：如果应用有 manifest，在项目目录中运行，确认应用配置格式正确。

在继续之前，先处理这些检查标记出的任何问题。

步骤 2：运行应用

无论使用下面哪条路径，首先把应用的日志级别调到 debug，以便测试时获得最多上下文。优先选择不改动开发者代码的方式：阅读日志器设置，看它是否读取日志级别环境变量（有些模板会接入 SLACK_LOG_LEVEL 或 LOG_LEVEL 之类的变量）。如果读取，就设置该变量而不是编辑源码。对于 CLI 管理的应用，SLACK_CMD env set <LOG_LEVEL_VAR> debug 会将其存入项目 .env，供 slack run 读取；对于普通 Bolt 应用，在应用已读取的环境或 .env 中设置。只有当日志器不读取此类变量时，才编辑源码，找到设置日志级别的位置并在本次运行中切换为 debug。

CLI 管理的应用（推荐）

按照 slack:slack-cli 技能中的步骤 6：本地运行应用（slack run），在后台启动本地开发服务器。这还会把应用安装到目标工作区，对于全新的沙盒或 Free Team（尚未安装任何内容）很重要。运行后，文件更改会自动重载。

不使用 CLI 的普通 Bolt 应用（尽力而为）

如果应用是用 node 或 python 启动的普通 Bolt 应用而非 Slack CLI，本技能仍可提供帮助，但运行路径是尽力而为，不是主要流程：

• 将应用指向测试工作区：在该工作区的应用设置中获取 bot 和 app-level token，设置到应用读取的环境或 .env 文件中。
• 优先使用 socket mode，这样应用不需要公共 URL。仅当应用按 socket mode 编写且 app-level token 具有 connections:write 时才有效；为 HTTP 搭建的应用添加 token 不会传递事件。
• 用应用自己的命令启动（例如 npm start 或 python app.py）并观察日志。

明确说明这条路径是尽力而为，最顺畅的体验来自 CLI 管理的应用。

步骤 3：在 Slack 中试用并确认可用

这是本技能的核心。不要给开发者通用清单，每一步都要基于该应用实际注册的内容。

3a. 阅读源码，找出应用监听什么

阅读应用的监听器代码，列出它注册的交互。根据框架不同，它们可能表现为：

• 斜杠命令：注册的命令名，例如 /ship。
• 快捷方式：带 callback ID 的全局或消息快捷方式。
• 事件：订阅的事件，例如 app_mention、message 或 reaction_added。
• 操作：带 action ID 的交互组件（按钮、选择器）。
• 视图提交：模态提交处理器（view_submission）。
• App Home：app_home_opened 处理器或已发布的 Home 标签页。
• Assistant / agent：assistant 或 assistant_thread_started 处理器，常见于 agent 模板。

说出你找到的具体标识符（实际的命令和 callback 名称），而不是占位符。

3b. 把每个交互变成“做什么、预期什么”的步骤

对每个注册的交互，给开发者一个具体步骤以及正常应用应有的响应。有几处不太直观，需要明确说明：

• 斜杠命令 → 在测试工作区的频道或私信中输入命令（例如 /ship）→ 预期处理器发送的响应。
• 全局快捷方式 → 打开快捷方式菜单（消息输入框中的闪电或 + 按钮，视客户端而定）并选择它 → 预期它打开的模态或消息。
• 消息快捷方式 → 悬停一条消息，打开“更多操作”（⋯ 菜单），选择快捷方式 → 预期其响应。
• 事件如 app_mention → 在应用所属频道中 @ 提及应用 → 预期其回复。
• 按钮或选择器 → 点击应用发布的消息或模态中的组件 → 预期操作处理器的行为。
• 模态提交（view_submission）→ 提交模态 → 预期确认或副作用。
• App Home → 点击左侧边栏中的应用打开其 Home 标签页 → 预期已发布的视图。

3c. 确认并报告

在开发者交互时，帮助他们确认是否正常工作：

• 如果应用在 slack run 下运行，观察其日志（要求“给我看 slack run 的输出”）以确认事件到达并读取任何错误。
• 如果响应看起来不对（消息或 Block Kit 视图格式错误，或 API 错误），使用 slack:block-kit 和 slack:slack-api 技能深入查看 payload 或方法。

最后给出简短总结：你和开发者确认了哪些功能正常，以及他们自己还应检查什么。记住这是手动检查：你是在帮助开发者观察应用响应，而不是产生自动化的通过或失败结果。

使用方式

本技能通过引导式对话使用：先检测并解析 Slack CLI 命令（SLACK_CMD），确认安全测试工作区，运行健康检查，然后启动应用（CLI 管理应用用 slack run，普通 Bolt 应用尽力而为），最后根据源码中注册的交互逐条给出操作步骤并协助确认。

适用场景

• 开发者想测试、试用、冒烟测试、验证或确认用 Slack CLI（或普通 Bolt）构建的 Slack 应用是否真正可用。
• 应用已存在，需要最后一步验证。

限制

• SLACK_CMD 是占位符：始终替换为步骤 1a 中解析出的实际命令名。
• 范围：本技能测试已存在的应用。要创建或搭建应用，使用 slack:create-slack-app 技能；原始 CLI 机制使用 slack:slack-cli 技能；消息或 Block Kit 格式使用 slack:slack-messaging 和 slack:block-kit 技能。
• 目前不在范围内：Bolt 的自动化测试框架、以编程方式模拟用户交互、用浏览器驱动 Slack UI。当前由开发者执行交互；本技能确保他们确切知道该做什么以及预期什么。