Back to Details

deploy-slack-app

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Deploy Slack App

部署 Slack 应用

Take a Slack app that already works locally and deploy it to a hosting provider as a separate Slack app, with its own app ID, that keeps running without the developer's machine. The local development app is unchanged, and Step 5: Deploy explains how the two coexist. This is the step after the 
slack:test-slack-app
skill confirms the app responds.
The mechanism is the Slack CLI's 
deploy
hook. Adding a 
deploy
key to the project's 
.slack/hooks.json
replaces Slack's own hosted deployment with a script of your choosing, and the CLI runs that script after it has created and installed the deployed app. That ordering is the whole reason this approach is worth using: the app's bot and app-level tokens are already in the script's environment by the time it runs, so nothing here has to prompt for a secret or store one.
Two supported providers, both running the app as a long-lived worker process:
ProviderProcess typeDeploys fromSecretsCurrent pricing
RailwayService, no port binding requiredThe working directoryPassed on stdinhttps://railway.com/pricing
Heroku
worker
dyno		A git push of committed codePassed as argumentshttps://www.heroku.com/pricing
Railway is the better default, and the reasons are in Step 2a: Choose a Provider.
将一个已经在本地正常工作的 Slack 应用部署到托管服务商，作为独立的 Slack 应用运行，拥有自己的 app ID，并且无需依赖开发者的机器即可持续运行。本地开发应用保持不变，步骤 5：部署说明了二者如何共存。本步骤应在 
slack:test-slack-app
skill 确认应用能够响应之后执行。
其机制是 Slack CLI 的 
deploy
hook。向项目的 
.slack/hooks.json
中添加 
deploy
键，会用你选择的脚本取代 Slack 自带的托管部署；CLI 会在创建并安装已部署应用之后运行该脚本。这个执行顺序正是该方案值得使用的原因：脚本运行之时，应用 bot token 和 app-level token 已经位于脚本的环境变量中，因此这里无需提示输入 secret，也无需存储 secret。
有两个受支持的服务商，二者都会将应用作为长期运行的 worker 进程运行：
服务商进程类型部署来源Secrets 传递方式当前定价
RailwayService，无需绑定端口工作目录通过 stdin 传入https://railway.com/pricing
Heroku
worker
dyno		提交代码后的 git push作为参数传入https://www.heroku.com/pricing
Railway 是更好的默认选项，原因见步骤 2a：选择服务商。

Step 1: Check Prerequisites

步骤 1：检查先决条件

1a. Detect the Slack CLI

1a. 检测 Slack CLI

Use the 
slack:slack-cli
skill (Step 1: Detect the Slack CLI) to check whether the public Slack CLI is installed and resolve its command name. The fingerprint check, alias fallback, and install instructions all live there; do not duplicate them. Refer to the resolved command as 
SLACK_CMD
throughout.
This matters more than it looks. Some machines have an unrelated internal tool named 
slack
on the path, and running that instead produces confusing failures well into the deploy.
使用 
slack:slack-cli
skill（步骤 1：检测 Slack CLI）检查公共 Slack CLI 是否已安装，并解析其命令名称。指纹检查、alias 回退和安装说明均位于该 skill 中；不要在此重复。下文统一将解析出的命令称为 
SLACK_CMD
。
其重要性比表面看起来更高。有些机器的 path 上有一个无关的内部工具也叫 
slack
，如果运行的是它，部署进入较深阶段后才会出现令人困惑的失败。

1b. Confirm the App Uses Socket Mode

1b. 确认应用使用 Socket Mode

Read the app's manifest rather than asking. The project already declares which mode it uses, so a question here is redundant. Check 
manifest.json
for 
settings.socket_mode_enabled
. If 
.slack/config.json
sets the manifest source to 
remote
, there is no local file, so read it with 
SLACK_CMD manifest info
instead.
  • Socket Mode enabled: continue. The app opens an outbound websocket to Slack, needs no public URL, and binds no HTTP port.
  • Socket Mode disabled, or the app uses a Request URL: stop here. This skill does not cover Request URL apps yet, because a hosted Request URL app also needs a public address captured after the deploy and written back into the app manifest. Tell the developer plainly that this is the gap, and that converting the app to Socket Mode is the supported path today. Support may have shipped in a newer version of the Slack Skills Plugin, so ask the developer to update the plugin and try again. If they are already on the latest version, point them to https://github.com/slackapi/slack-skills-plugin/issues/172 to add a reaction or comment.
If the manifest is ambiguous, read the app's entrypoint. A Bolt for JavaScript app constructed with 
socketMode: true
and an 
appToken
, or a Bolt for Python app started through 
SocketModeHandler
, is a Socket Mode app.
读取应用的 manifest，而不是询问。 项目已经声明了所使用的模式，因此在这里提问是多余的。检查 
manifest.json
中的 
settings.socket_mode_enabled
。如果 
.slack/config.json
将 manifest source 设为 
remote
，则本地没有文件，应改用 
SLACK_CMD manifest info
读取。
  • 已启用 Socket Mode： 继续。该应用会向 Slack 建立出站 websocket，无需公共 URL，也不绑定 HTTP 端口。
  • 未启用 Socket Mode，或应用使用 Request URL： 在此停止。 本 skill 尚未涵盖 Request URL 应用，因为托管的 Request URL 应用还需要在部署后获取公共地址，并将其写回应用 manifest。请直接告诉开发者这是目前的缺口，并将应用转换为 Socket Mode 是当前受支持的方式。更新版本的 Slack Skills Plugin 可能已经提供支持，因此请开发者更新插件后重试。如果他们已在使用最新版本，请引导他们前往 https://github.com/slackapi/slack-skills-plugin/issues/172 添加 reaction 或 comment。
如果 manifest 信息不明确，读取应用入口。对于使用 
socketMode: true
和 
appToken
创建的 Bolt for JavaScript 应用，或通过 
SocketModeHandler
启动的 Bolt for Python 应用，即为 Socket Mode 应用。

1c. Confirm the Runtime Is Supported

1c. 确认运行时受支持

This flow is verified on macOS and Linux. The deploy hook is a shell script, so a Windows developer needs a PowerShell equivalent that does not exist yet. On Windows, say so rather than letting the deploy fail partway through. WSL is a workable path in the meantime. Support may have shipped in a newer version of the Slack Skills Plugin, so ask the developer to update the plugin and try again. If they are already on the latest version, point them to https://github.com/slackapi/slack-skills-plugin/issues/171 to add a reaction or comment.
此流程已在 macOS 和 Linux 上验证。
deploy
hook 是 shell 脚本，因此 Windows 开发者需要目前尚不存在的 PowerShell 等效脚本。在 Windows 上，应明确说明这一点，而不是让部署在中途失败。期间 WSL 是可行方案。更新版本的 Slack Skills Plugin 可能已经提供支持，因此请开发者更新插件后重试。如果他们已在使用最新版本，请引导他们前往 https://github.com/slackapi/slack-skills-plugin/issues/171 添加 reaction 或 comment。

Step 2: Choose a Provider and a Team

步骤 2：选择服务商和 Team

Ask the developer two things the project cannot tell you: which provider to deploy to, and which Slack team to deploy into.
询问开发者两个项目本身无法提供的信息：部署到哪个服务商，以及部署到哪个 Slack team。

2a. Choose a Provider

2a. 选择服务商

Ask which provider, because cost is the thing the developer cannot infer from the project. Give the developer both pricing links from the table above so they can check current terms. Do not fetch the pages or quote prices, plan names, or trial terms. Providers change them often, and this skill can be installed long after it was written.
What does not change with the price list, and is worth saying:
  • Railway is the default recommendation. It accepts secrets on stdin, so the tokens never appear in process arguments. It deploys the working directory, so a re-deploy needs no commit, and it needs no 
    Procfile
    .
  • Heroku fits when the developer already has an account, or a team standard that points there. It builds from git, so only committed code is deployed. Some accounts, including enterprise-managed ones, cannot own a personal app and must create it on a Heroku team. Personal apps and team apps can have different plans and billing, so ask which team to use rather than picking one: a shared team has a shared budget.
Say plainly that both providers keep the app running continuously, which is what a Socket Mode app requires. Always-on hosting is a paid service in the end, so expect it to cost something once any trial runs out.
Once the developer picks one, read that provider's reference file and follow it: 
references/railway.md
or 
references/heroku.md
. Each holds the install and authentication commands, the provider's own requirements for the project, and the environment variables its deploy script reads. Step 4: Wire Up the Deploy Hook works through them.
询问使用哪个服务商，因为费用是开发者无法从项目中推断的信息。向开发者提供上表中的两个定价链接，以便其查看当前条款。不要抓取这些页面，也不要引用价格、套餐名称或试用条款。 服务商会经常变更这些信息，而本 skill 可能早在编写完成很久以后才被安装。
以下内容不会随价格表变化，值得说明：
  • Railway 是默认推荐项。它通过 stdin 接收 secrets，因此 tokens 永远不会出现在进程参数中。它会部署工作目录，因此重新部署无需 commit，也不需要 
    Procfile
    。
  • Heroku 适合开发者已有账户，或团队标准指定使用 Heroku 的情况。它从 git 构建，因此只会部署已提交的代码。某些账户，包括企业托管账户，无法拥有 personal app，必须在 Heroku team 中创建。Personal app 和 team app 可能采用不同的套餐和计费方式，因此应询问使用哪个 team，而不要自行选择：共享 team 意味着共享预算。
明确说明，两个服务商都会让应用持续运行，这正是 Socket Mode 应用的要求。Always-on 托管最终属于付费服务，因此任何试用期结束后都应预计会产生费用。
开发者选定后，读取相应服务商的参考文件并遵循其中的说明：
references/railway.md
或 
references/heroku.md
。每个文件都包含安装和身份验证命令、该服务商对项目的要求，以及部署脚本读取的环境变量。步骤 4：配置 Deploy Hook会通过这些文件完成设置。

2b. Choose a Team

2b. 选择 Team

Run 
SLACK_CMD auth list
. If it lists one team, use it. If it lists more than one, show the developer each team's name and ID and ask which one to deploy into.
Never pick the team yourself. Do not assume the standalone workspace or the Enterprise org, and do not reuse the team from 
.slack/apps.dev.json
, which is often a developer sandbox. A wrong guess installs the app into a team the developer did not intend, and a later deploy to the right team creates a second Slack app.
运行 
SLACK_CMD auth list
。如果只列出一个 team，则使用该 team。如果列出多个，则向开发者显示每个 team 的名称和 ID，并询问要部署到哪个 team。
绝不自行选择 team。 不要假定是 standalone workspace 或 Enterprise org，也不要复用 
.slack/apps.dev.json
中的 team，该文件通常对应开发者 sandbox。选错会把应用安装到开发者未预期的 team，而之后部署到正确 team 时会创建第二个 Slack 应用。

Step 3: Confirm It Works Locally First

步骤 3：先确认应用能够在本地正常工作

Do not deploy an app that has not been seen working. A broken deploy and a broken app look identical in a provider's logs, and separating them afterwards costs far more than checking first.
Use the 
slack:test-slack-app
skill to run the app with 
SLACK_CMD run
and exercise at least one real surface, so there is a known-good behaviour to re-check after the deploy. Note which surface was used: the same one is the check in Step 6: Verify the Deployment.
不要部署一个尚未确认可以正常工作的应用。 在服务商日志中，部署失败和应用故障看起来完全一样；事后区分二者的成本远高于事先检查。
使用 
slack:test-slack-app
skill，通过 
SLACK_CMD run
运行应用，并至少测试一个真实交互界面，从而建立已知正常的行为，以便部署后重新检查。记下所使用的界面：步骤 6：验证部署将使用同一界面进行检查。

Step 4: Wire Up the Deploy Hook

步骤 4：配置 Deploy Hook

Three things to set up. Check whether each already exists before writing it, because re-deploying an app is the common case and clobbering a developer's edited script is not recoverable.
需要完成三项设置。写入任何内容前，先检查各项是否已经存在，因为重新部署应用是常见操作，而覆盖开发者修改过的脚本无法恢复。

4a. Prepare the Provider

4a. 准备服务商环境

Work through the chosen provider's reference file before writing anything, because the deploy script only checks these and stops. It cannot fix them.
  • Install and authenticate the provider's CLI. Run its 
    whoami
    check. Logging in opens a browser, so if the check fails, ask the developer to run the login command in their own terminal rather than running it yourself.
  • Settle the names and ownership with the developer. For Heroku: a distinctive app name, and whether the app belongs to a team (
    heroku teams
    ). For Railway: the workspace, if the account has more than one. These become environment variables on the deploy command in Step 5: Deploy.
  • Meet the provider's project requirements. For Heroku, write the 
    Procfile
    and commit it. For Railway, confirm the start command it will detect.
编写任何内容前，先完成所选服务商参考文件中的步骤，因为部署脚本只会检查这些条件并停止，无法替你修复。
  • 安装并验证服务商的 CLI。 运行其 
    whoami
    检查。登录会打开浏览器，因此如果检查失败，请开发者在自己的终端中运行登录命令，而不是由你执行。
  • 与开发者确定名称和归属。 对于 Heroku：确定一个有辨识度的 app name，以及 app 是否属于某个 team（
    heroku teams
    ）。对于 Railway：如果账户有多个 workspace，则确定使用哪个 workspace。这些值会成为步骤 5：部署中 deploy 命令的环境变量。
  • 满足服务商的项目要求。 对于 Heroku，编写 
    Procfile
    并提交。对于 Railway，确认它将检测到的 start command。

4b. Write the Deploy Script

4b. 编写部署脚本

Copy the provider's deploy script into the project's 
.slack/
directory under the same name, then make it executable:
  • Railway: 
    references/deploy-railway.sh
    to 
    .slack/deploy-railway.sh
  • Heroku: 
    references/deploy-heroku.sh
    to 
    .slack/deploy-heroku.sh
For example, 
chmod +x .slack/deploy-railway.sh
.
Each script is self-contained. It validates that both tokens arrived, reads the deployed app ID from 
.slack/apps.json
for its log line, and then runs the provider's preflight, provision, configure, and deploy steps in order. There is nothing else to copy. The CLI runs the hook from the project root, so the script's relative paths resolve there even though the file lives in 
.slack/
.
If the script already exists, show the developer that it is there and ask before overwriting. A developer may have adjusted it.
将服务商的部署脚本复制到项目的 
.slack/
目录下，并保持相同文件名，然后赋予其可执行权限：
  • Railway：将 
    references/deploy-railway.sh
    复制为 
    .slack/deploy-railway.sh
  • Heroku：将 
    references/deploy-heroku.sh
    复制为 
    .slack/deploy-heroku.sh
例如：
sh
chmod +x .slack/deploy-railway.sh
每个脚本都是自包含的。它会验证两个 token 均已传入，从 
.slack/apps.json
读取已部署应用的 ID 以写入日志行，然后依次执行服务商的 preflight、provision、configure 和 deploy 步骤。无需复制其他内容。CLI 从项目根目录运行 hook，因此即使文件位于 
.slack/
，脚本中的相对路径仍会相对于项目根目录解析。
如果脚本已经存在，向开发者说明其存在，并在覆盖前征求同意。开发者可能已对脚本进行调整。

4c. Register the Hook

4c. 注册 Hook

Add a 
deploy
key inside the existing 
hooks
object in 
.slack/hooks.json
, pointing at the provider's script. For Railway:
json
"deploy": "./.slack/deploy-railway.sh"
For Heroku, the value is 
./.slack/deploy-heroku.sh
. Leave the 
get-hooks
entry exactly as it is. Its value differs between Bolt for JavaScript and Bolt for Python projects, so do not copy one from elsewhere.
If a 
deploy
key is already present, do not add a second one. A duplicate key produces invalid JSON, and the CLI will reject the project rather than deploy it. If the existing key already points at the chosen provider's script, leave it. If it points somewhere else, such as the other provider's script, show the developer and ask before changing it.
在 
.slack/hooks.json
已有的 
hooks
对象中添加 
deploy
键，并指向服务商的脚本。对于 Railway：
json
"deploy": "./.slack/deploy-railway.sh"
对于 Heroku，其值为 
./.slack/deploy-heroku.sh
。保持 
get-hooks
条目原样不变。 它的值因 Bolt for JavaScript 和 Bolt for Python 项目而异，因此不要从其他地方复制。
如果已经存在 
deploy
键，不要再添加第二个。 重复键会产生无效 JSON，CLI 将拒绝该项目，而不会执行部署。如果现有键已经指向所选服务商的脚本，则保持不变。如果它指向其他位置，例如另一个服务商的脚本，应向开发者说明，并在更改前征求同意。

Step 5: Deploy

步骤 5：部署

Run 
SLACK_CMD deploy
from the project root and watch the output. The CLI creates the deployed app, installs it, and then runs the hook script, so the first part of the output is app installation and the second is the provider's build.
Four flags matter when running this outside an interactive terminal, which includes most agent sessions. The CLI asks four questions, and each one is fatal unanswered: a non-interactive shell gets 
The input device is not a TTY or does not support interactivity
and nothing is deployed.
  • --skip-update
    stops the CLI pausing to offer an upgrade.
  • --team <team ID>
    picks the workspace or organization. Use the team the developer chose in Step 2b: Choose a Team.
  • --app deployed
    selects the deployed app environment, and creates that app on a first deploy. Without it the CLI asks the developer to choose between an existing app and a new one. This is the flag most easily missed, because the prompt it answers only appears on a project that has never been deployed.
  • --org-workspace-grant all
    answers the workspace-grant prompt for an org-installed app.
So the full command is 
SLACK_CMD deploy --skip-update --team <team ID> --app deployed --org-workspace-grant all
.
Put any provider variables settled in Step 4a: Prepare the Provider in front of it. The hook inherits the CLI's environment, so this is how they reach the script:
sh
HEROKU_TEAM=<team> HEROKU_APP_NAME=<name> SLACK_CMD deploy --skip-update --team <team ID> --app deployed --org-workspace-grant all
The deployed app is a different app from the one 
SLACK_CMD run
uses. The CLI writes the deployed app to 
.slack/apps.json
and the local development app to 
.slack/apps.dev.json
, keyed by team. Both keep working independently, which is the intended design, not a mistake to correct.
Commit 
.slack/apps.json
after the first deploy. It holds app and team IDs, not secrets, and the project's 
.slack/.gitignore
leaves it tracked on purpose. Committing it keeps every later deploy pointed at the same app. On Heroku it also stops the deploy script warning about uncommitted changes on each re-deploy.
One consequence to warn the developer about: the two apps declare the same slash commands in the same workspace. Running 
SLACK_CMD run
while the deployed app is live makes it ambiguous which one answers a slash command. Stop the local process when checking the deployed app, which Step 6: Verify the Deployment does anyway.
从项目根目录运行 
SLACK_CMD deploy
并观察输出。CLI 会创建已部署应用、安装应用，然后运行 hook 脚本，因此输出的前半部分是应用安装，后半部分是服务商构建。
在非交互式终端中运行时，包括大多数 agent session，有四个 flag 很重要。CLI 会询问四个问题，任何一个未回答都会导致失败：非交互式 shell 会收到 
The input device is not a TTY or does not support interactivity
，并且不会部署任何内容。
  • --skip-update
    阻止 CLI 暂停并提示升级。
  • --team <team ID>
    选择 workspace 或 organization。使用开发者在步骤 2b：选择 Team中选定的 team。
  • --app deployed
    选择 deployed app 环境，并在首次部署时创建该 app。如果不提供此参数，CLI 会让开发者在现有 app 和新 app 之间进行选择。这个 flag 最容易被忽略，因为它所回答的提示只会出现在从未部署过的项目上。
  • --org-workspace-grant all
    回答 org 安装型应用的 workspace 授权提示。
因此，完整命令为 
SLACK_CMD deploy --skip-update --team <team ID> --app deployed --org-workspace-grant all
。
将步骤 4a：准备服务商环境中确定的所有服务商变量放在命令前面。hook 会继承 CLI 的环境，因此变量会通过这种方式传递给脚本：
sh
HEROKU_TEAM=<team> HEROKU_APP_NAME=<name> SLACK_CMD deploy --skip-update --team <team ID> --app deployed --org-workspace-grant all
已部署应用与 
SLACK_CMD run
使用的应用不同。 CLI 将 deployed app 写入 
.slack/apps.json
，将本地开发应用写入 
.slack/apps.dev.json
，并以 team 为键。两者会独立运行，这是预期设计，而不是需要修正的错误。
首次部署后提交 
.slack/apps.json
。 它保存 app ID 和 team ID，而不是 secrets；项目的 
.slack/.gitignore
有意让该文件继续受版本控制。提交该文件可确保后续每次部署都指向同一个 app。在 Heroku 上，这也能避免部署脚本在每次重新部署时警告存在未提交的更改。
需要向开发者警告一个后果：两个 app 会在同一个 workspace 中声明相同的 slash commands。在 deployed app 运行时执行 
SLACK_CMD run
，会导致哪个 app 响应 slash command 变得不明确。检查 deployed app 时应停止本地进程，步骤 6：验证部署本来也会这样做。

Step 6: Verify the Deployment

步骤 6：验证部署

Check all three of these. The first two can pass while the app is silent in Slack.
检查以下全部三项。前两项即使通过，应用也可能在 Slack 中毫无响应。

6a. The Service Is Running

6a. 服务正在运行

Use the status and log commands from the provider's reference file. Look for the app's own startup logging and the Socket Mode websocket connecting. A build that succeeded and a process that then exited look very different here, so read the logs rather than trusting the build result.
使用服务商参考文件中的 status 和 log 命令。查找应用自身的启动日志以及 Socket Mode websocket 的连接记录。构建成功后进程随即退出的情况在这里表现得很不同，因此应读取日志，而不是仅信任构建结果。

6b. The App Answers in Slack, With Nothing Running Locally

6b. 在本地没有运行任何进程时，应用能够在 Slack 中响应

Stop the local process first. This is the only check that proves the deployed app is doing the work rather than the developer's laptop. Exercise the surface noted in Step 3: Confirm It Works Locally First, and confirm the response appears in Slack and the corresponding request appears in the provider's logs.
先停止本地进程。 这是唯一能够证明 deployed app 正在处理工作，而不是开发者笔记本在处理工作的检查。测试步骤 3：先确认应用能够在本地正常工作中记录的界面，并确认响应出现在 Slack 中，同时相应请求出现在服务商日志中。

6c. Both Apps Are Distinct

6c. 两个应用彼此独立

Show the developer the app ID in 
.slack/apps.json
and the one in 
.slack/apps.dev.json
and confirm they differ. Then confirm 
SLACK_CMD run
still drives the development app.
向开发者显示 
.slack/apps.json
中的 app ID 和 
.slack/apps.dev.json
中的 app ID，并确认二者不同。然后确认 
SLACK_CMD run
仍会驱动开发应用。

Step 7: Re-deploy

步骤 7：重新部署

Shipping a change is the same 
SLACK_CMD deploy
command, with the same flags as Step 5: Deploy. Everything in Step 4: Wire Up the Deploy Hook is already in place, so skip it and go straight to the deploy, and expect the same app rather than a second one.
Two provider differences to know about, both handled by the deploy scripts:
  • Railway uploads the working directory and rebuilds every time, so no commit is needed.
  • Heroku builds from a git push, so uncommitted changes are not deployed. A push with no new commit builds nothing, so the script restarts the dynos instead, which picks up any changed tokens. Commit code changes before re-deploying.
If a re-deploy creates a second Slack app, the deployed app entry in 
.slack/apps.json
was lost. Before deploying again, confirm 
.slack/apps.json
has an entry for the 
--team
ID, rather than deleting apps afterwards.
发布变更仍使用与步骤 5：部署相同的 
SLACK_CMD deploy
命令和 flags。步骤 4：配置 Deploy Hook中的所有内容都已就绪，因此跳过该步骤，直接部署，并应继续使用同一个 app，而不是创建第二个 app。
需要了解两个服务商之间的差异，部署脚本会处理这些差异：
  • Railway 会上传工作目录并每次重新构建，因此无需 commit。
  • Heroku 从 git push 构建，因此未提交的更改不会被部署。如果没有新 commit 的 push，就不会构建任何内容，脚本会改为重启 dynos，从而获取发生变化的 tokens。重新部署前应提交代码更改。
如果重新部署创建了第二个 Slack app，说明 
.slack/apps.json
中的 deployed app 条目已经丢失。再次部署前，应确认 
.slack/apps.json
中存在与 
--team
ID 对应的条目，而不是事后删除应用。

Step 8: Tear Down a Deployment

步骤 8：拆除部署

Use this when the developer is done with the deployed app, for example after trying the skill out. It deletes the host's copy and the deployed Slack app, and leaves the development app alone.
Name every resource and ask once before deleting anything. These deletes are permanent. Say which provider project or app goes, and which Slack app ID from 
.slack/apps.json
, then wait for a yes.
  1. Delete the provider's copy first, so nothing is left holding a connection to Slack with tokens that are about to stop working. The commands are in the provider's reference file, under "Tearing down".
  2. Delete the deployed Slack app with 
    SLACK_CMD app delete --team <team ID> --app deployed --force
    . Read the team ID from 
    .slack/apps.json
    . 
    --force
    skips the confirmation prompt, which would otherwise fail in a non-interactive shell. When it was the only deployed app, the CLI removes 
    .slack/apps.json
    as well, so commit that deletion.
  3. Leave the development app unless the developer asks for it too. It is the app 
    SLACK_CMD run
    uses, and they will usually keep working on it. If they ask, the same command with 
    --app local
    deletes it.
Leave 
.slack/hooks.json
and the deploy script in place, so a later 
SLACK_CMD deploy
sets everything up again from the start.
当开发者不再需要已部署应用时使用此步骤，例如试用完本 skill 后。它会删除托管端的副本和 deployed Slack app，并保留开发应用。
删除任何内容前，列出每个资源并只询问一次。 这些删除是永久性的。说明将删除哪个服务商项目或 app，以及来自 
.slack/apps.json
的哪个 Slack app ID，然后等待用户答复 yes。
  1. 先删除服务商端的副本，避免仍有连接持有即将失效的 tokens。相关命令位于服务商参考文件的 "Tearing down" 部分。
  2. 使用 
    SLACK_CMD app delete --team <team ID> --app deployed --force
    删除 deployed Slack app。从 
    .slack/apps.json
    读取 team ID。
    --force
    会跳过确认提示，否则在非交互式 shell 中会失败。当它是唯一的 deployed app 时，CLI 还会删除 
    .slack/apps.json
    ，因此应提交这项删除。
  3. 保留开发应用，除非开发者也要求删除。它是 
    SLACK_CMD run
    使用的应用，开发者通常会继续使用它。如果他们要求删除，使用同一命令并加上 
    --app local
    。
保留 
.slack/hooks.json
和部署脚本，以便之后再次执行 
SLACK_CMD deploy
时从头完成所有设置。

Notes

注意事项

Serverless providers cannot host a Socket Mode app. A Socket Mode app is a process that stays resident and holds an outbound websocket open. Vercel, AWS Lambda, and similar platforms run per-request functions with a maximum duration and no always-on process type, so there is nothing for the websocket to live in. When a developer asks for one of these, explain the constraint rather than attempting it. Hosting a Slack app on a serverless platform means a Request URL app, which this skill does not cover yet.
Other providers. When a developer asks about a provider this skill does not cover, the two things to check are whether it offers an always-on background worker process type and how that process is billed.
The token handoff is not a documented contract. The Slack CLI does not pass the tokens to the deploy hook explicitly. It sets them on its own process during app installation, and the hook script inherits them because it runs later in that same process. It works, and it only works for apps with no Slack-hosted function runtime, which covers every Bolt app. That is why each deploy script checks for both tokens and stops with a readable message instead of assuming they are present.
Not 
slack deploy
without a hook. With no 
deploy
key in 
.slack/hooks.json
, 
SLACK_CMD deploy
targets Slack's own hosted infrastructure, which is a different product for a different kind of app. The 
slack:slack-cli
skill covers the CLI's commands generally.
Building the app comes first. If there is no app yet, start with the 
slack:create-slack-app
skill and come back here once it runs locally.
Serverless 服务商无法托管 Socket Mode 应用。 Socket Mode 应用是一个常驻进程，会保持出站 websocket 连接。Vercel、AWS Lambda 等平台运行的是按请求触发的函数，具有最长执行时长，且没有 always-on 进程类型，因此 websocket 无处驻留。当开发者要求使用这些平台时，应解释这一限制，而不是尝试部署。在 serverless 平台托管 Slack 应用意味着使用 Request URL 应用，而本 skill 尚未涵盖。
其他服务商。 当开发者询问本 skill 未涵盖的服务商时，需要检查两点：是否提供 always-on 后台 worker 进程类型，以及该进程如何计费。
Token handoff 不是有文档保证的 contract。 Slack CLI 并未显式将 tokens 传给 deploy hook。它在应用安装期间在自己的进程中设置 tokens；由于 hook 稍后在同一进程中运行，因此会继承这些 tokens。该方案有效，但仅适用于没有 Slack 托管 function runtime 的应用，这涵盖所有 Bolt 应用。这就是每个部署脚本都会检查两个 token，并在缺失时以可读消息停止，而不是假定它们存在。
没有 hook 时，不是 
slack deploy
。 如果 
.slack/hooks.json
中没有 
deploy
键，
SLACK_CMD deploy
的目标是 Slack 自带的托管基础设施，而这是面向另一类应用的另一项产品。
slack:slack-cli
skill 总体上涵盖了 CLI 的命令。
先构建应用。 如果还没有应用，请先使用 
slack:create-slack-app
skill，并在其能够在本地运行后返回这里。