Test Slack App

Test Slack App

Help a developer confirm that a Slack app they already built actually works. This is the last step of the build loop, after the slack:create-slack-app skill scaffolds an app and the slack:slack-cli skill runs it.

The approach is simple and safe:

1. Run the app in a developer sandbox or a Free Team: a sandbox for preference, or a Free Team the developer created for this. Never a workspace with real coworkers in it.
2. Read the app's source to learn what it actually listens for.
3. Hand the developer concrete steps to perform in Slack, then help them confirm the app responds.

This is guided manual checking, not an automated test suite: you drive the setup and tell the developer what to type or click, and they confirm what they see. It works best for apps managed by the Slack CLI; there is a best-effort path for plain Bolt apps in Step 2.

Step 1: Set Up a Safe Place to Test

1a. Detect the 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 here. Refer to the resolved command as SLACK_CMD throughout. If the CLI is not installed, guide the developer through that same step to install it, since running the app needs it.

1b. Make sure there is a safe workspace to test in

Testing belongs in a workspace nobody is working in: a developer sandbox for preference, or a Free Team the developer created for this. Never a workspace with real coworkers in it.

• Explain it from the live docs, not from here. Use the slack:slack-docs skill to fetch and summarize https://docs.slack.dev/tools/developer-sandboxes.md, so the recommendation always reflects the current docs rather than a copy that drifts out of date. Tell the developer that Slack recommends a sandbox for building and testing apps.
• Find the current target. Run SLACK_CMD auth list for the authenticated workspaces and their team IDs, and, from the project directory, SLACK_CMD app list for the apps already installed and their IDs.
• Confirm the target is safe. The CLI cannot tell a sandbox, a Free Team, and a workspace full of real users apart, so ask the developer which one they are pointed at. A sandbox or a Free Team they created for this is fine. A workspace with coworkers in it is not: stop and get them onto one of the other two.
• If there is no safe target yet, set one up with the slack:create-slack-app skill (Step 3: Choose Where to Install the App), which owns the ranked targets, the sandbox list / sandbox create flow, and the Developer Program links. Either path finishes in the browser, so have the developer come back here once the workspace exists and they have logged into it.

1c. Quick health check

Catch obvious setup problems with the CLI's own validation before the slower hands-on checks:

• SLACK_CMD doctor: checks the CLI, language runtime, and authentication.
• SLACK_CMD manifest validate: run from the project directory if the app has a manifest, to confirm the app configuration is well-formed.

Surface anything these flag before moving on.

Step 2: Run the App

Whichever path you use below, first turn the app's log level up to debug so you have the most context while testing. Prefer a way that leaves the developer's code untouched: read the logger setup to see whether it reads a log-level environment variable (some templates wire one such as SLACK_LOG_LEVEL or LOG_LEVEL). If it does, set that variable instead of editing source. For a CLI-managed app, SLACK_CMD env set <LOG_LEVEL_VAR> debug stores it in the project .env that slack run reads; for a plain Bolt app, set it in the environment or .env the app already reads. Only when the logger reads no such variable should you edit the source, finding where the log level is set and switching it to debug for this run.

CLI-managed apps (recommended)

Follow Step 6: Running an App Locally (slack run) in the slack:slack-cli skill to start the local dev server in the background. This also installs the app into the target workspace, which matters for a fresh sandbox or Free Team where nothing is installed yet. Once it is running, file changes auto-reload.

Plain Bolt apps without the CLI (best-effort)

If the app is a plain Bolt app started with node or python rather than the Slack CLI, this skill can still help, but the run path is best-effort and not the primary flow:

• Point the app at the test workspace: set its bot and app-level tokens (from that workspace's app settings) in the environment or the .env file the app reads.
• Prefer socket mode so the app needs no public URL. This works only if the app is coded for socket mode and the app-level token has connections:write; adding tokens to an app scaffolded for HTTP will not deliver events.
• Start the app with its own command (for example npm start or python app.py) and watch its logs.

Say plainly that this path is best-effort, and that the smoothest experience comes from a CLI-managed app.

Step 3: Try It Out in Slack and Confirm It Works

This is the heart of the skill. Do not hand the developer a generic checklist. Ground every step in what this app actually registers.

3a. Read the source to find what the app listens for

Read the app's listener code and list the interactions it registers. Depending on the framework these look like:

• Slash commands: a registered command name such as /ship.
• Shortcuts: global or message shortcuts with a callback ID.
• Events: subscribed events such as app_mention, message, or reaction_added.
• Actions: interactive components (buttons, selects) with an action ID.
• View submissions: modal submit handlers (view_submission).
• App Home: an app_home_opened handler or a published Home tab.
• Assistant / agent: an assistant or assistant_thread_started handler, common in the agent templates.

Name the concrete identifiers you find (the actual command and callback names), not placeholders.

3b. Turn each into a "do this, expect that" step

For every registered interaction, give the developer a concrete step and what a working app should do in response. A few spots are non-obvious, so spell them out:

• Slash command → type the command (for example /ship) in a channel or DM in the test workspace → expect the response the handler sends.
• Global shortcut → open the shortcuts menu (the lightning-bolt or + button in the message composer, depending on your client) and pick it → expect the modal or message it opens.
• Message shortcut → hover a message, open More actions (the ⋯ menu), pick the shortcut → expect its response.
• Event such as app_mention → @-mention the app in a channel it belongs to → expect its reply.
• Button or select → click the component in a message or modal the app posted → expect what the action handler does.
• Modal submit (view_submission) → submit the modal → expect the confirmation or side effect.
• App Home → click the app in the left sidebar to open its Home tab → expect the published view.

3c. Confirm and report

While the developer interacts, help them confirm it is working:

• If the app runs under slack run, watch its logs (ask "show me the output from slack run") to confirm events arrive and to read any errors.
• If a response looks wrong (a malformed message or Block Kit view, or an API error), use the slack:block-kit and slack:slack-api skills to dig into the payload or method.

Close with a short summary: what you and the developer confirmed working, and what they should eyeball themselves. Remember this is manual checking: you are helping the developer watch the app respond, not producing an automated pass or fail.

Notes

• SLACK_CMD is a placeholder: always substitute the actual command name resolved in Step 1a.
• Scope: this skill tests an app that already exists. To create or scaffold one, use the slack:create-slack-app skill; for raw CLI mechanics, use the slack:slack-cli skill; for message or Block Kit formatting, use the slack:slack-messaging and slack:block-kit skills.
• Out of scope for now: automated test frameworks for Bolt, programmatically simulating user interactions, and driving the Slack UI with a browser. Today the developer performs the interactions; this skill makes sure they know exactly what to do and what to expect.