用途
该技能用于把一个已经在本地正常运行的 Slack 应用部署到托管服务商，使其在开发者本机关闭后仍能持续运行。部署后会生成一个独立的 Slack 应用，拥有自己的 app ID，与本地开发应用并存且互不影响。这是 slack:test-slack-app 技能确认应用可响应之后的下一步。
主要能力
- 通过 Slack CLI 的 deploy hook 机制，在项目的 .slack/hooks.json 中添加 deploy 键，用自定义脚本替换 Slack 自带的托管部署。
- 支持两个服务商，均以常驻 worker 进程方式运行：
- Railway：Service 类型，无需绑定端口，从工作目录部署，密钥通过 stdin 传递，定价见 https://railway.com/pricing。
- Heroku：worker dyno，通过 git push 已提交代码部署，密钥作为参数传递，定价见 https://www.heroku.com/pricing。
- 部署脚本在 CLI 创建并安装部署应用之后运行，此时应用的 bot token 和 app-level token 已在脚本环境中，无需提示或存储密钥。
使用方式
流程分为以下步骤：
- 检查前置条件：检测 Slack CLI（使用 slack:slack-cli 技能，命令记为 SLACK_CMD）；读取 manifest.json 确认 settings.socket_mode_enabled 为启用（若 manifest 来源为 remote，则用 SLACK_CMD manifest info 读取）；确认运行时为 macOS 或 Linux（Windows 需 PowerShell 等价脚本，暂未提供，可用 WSL）。
- 选择服务商与团队：询问开发者选择服务商（Railway 为默认推荐，因其通过 stdin 接收密钥、从工作目录部署、无需 Procfile；Heroku 适合已有账户或团队标准指向它的场景）；运行 SLACK_CMD auth list 选择团队，不要自行猜测。
- 先确认本地可用：使用 slack:test-slack-app 技能运行应用并测试至少一个真实交互面。
- 配置部署钩子：准备服务商（安装并认证 CLI、确定名称与归属、满足项目要求）；将对应部署脚本复制到 .slack/ 目录并赋予可执行权限（Railway 用 references/deploy-railway.sh，Heroku 用 references/deploy-heroku.sh）；在 .slack/hooks.json 的 hooks 对象中添加 deploy 键指向脚本。
- 部署：运行 SLACK_CMD deploy，非交互终端需加四个标志：--skip-update、--team <team ID>、--app deployed、--org-workspace-grant all。服务商变量放在命令前。首次部署后提交 .slack/apps.json。
- 验证部署：检查服务是否运行（查看状态与日志）、在本地无进程运行时应用能否在 Slack 中响应、两个应用是否不同。
- 重新部署：使用相同的 SLACK_CMD deploy 命令与标志。Railway 每次上传工作目录并重建，无需提交；Heroku 从 git push 构建，需先提交代码变更。
- 拆除部署：先删除服务商副本，再用 SLACK_CMD app delete --team <team ID> --app deployed --force 删除部署的 Slack 应用，保留开发应用、hooks.json 和部署脚本。
适用场景
- 开发者希望 Slack 应用在本地进程停止后仍持续运行。
- 使用 Socket Mode 的 Bolt 应用（JavaScript 或 Python）。
- 需要将本地开发应用与部署应用分离管理的场景。
限制
- 不支持使用 Request URL 的应用，仅支持 Socket Mode 应用。
- 不支持 Windows 原生环境（需 WSL 或等待 PowerShell 等价脚本）。
- 不支持无服务器平台（如 Vercel、AWS Lambda），因其无常驻进程类型，无法承载 Socket Mode 的 websocket。
- 令牌传递机制并非文档化契约，依赖 CLI 进程环境继承。
- 两个应用在同一工作区声明相同的斜杠命令，本地运行时可能产生歧义，检查部署应用时应停止本地进程。
- 常驻托管最终为付费服务，试用期结束后会产生费用。