feat: support developer sandboxes, free, and paid teams as install targets - #147
Conversation
The Slack CLI logs into any workspace the developer belongs to, but `create-slack-app` treated a developer sandbox as the only option, which put Developer Program signup on the critical path for anyone trying the plugin for the first time. Step 3 is now "Choose Where to Install the App" and presents three ranked targets: a developer sandbox (recommended), a Free Team (second choice), or an existing production workspace (last resort). Each gets its own sub-step with the constraint that actually bites: sandboxes need a Developer Program account, Free Teams cap at 10 apps, and production workspaces are usually gated by admin app approval, which is always on for Enterprise Grid and switchable on elsewhere. `test-slack-app` no longer implies a sandbox is the only safe place to test. The warning it was carrying is right about a workspace with real coworkers in it and wrong about a throwaway Free Team, so it now asks which of the three the developer is pointed at rather than asking them to confirm a sandbox. Two smaller corrections while in here: - `sandbox create` is not interactive when given `--name` and `--password`; the prompts are fallbacks for missing flags. The skill can run it directly instead of handing it to the developer. `sandbox list` needs `--team` for the same reason. - Nothing this skill scaffolds can trip `free_team_not_allowed`, which is scoped to low-code workflow and function apps. Bolt apps install and run on the free plan.
🦋 Changeset detectedLatest commit: 31d217a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Matches the PR title. The changeset summary ships in the CHANGELOG, so it carries the same framing as the title rather than the earlier "ranked install targets" phrasing.
mwbrooks
changed the title
The three targets are Step 3's content, and naming them in the description bought nothing that Step 3 does not already do. Trigger cues are unchanged.
"Throwaway workspace" is not Slack product language, and using it as an umbrella term invented a category that covers a developer sandbox and a Free Team. Name the two directly instead, and keep "safe" as the word for the property being asked about, which Step 1 of test-slack-app already used.
A developer sandbox is an Enterprise Grid org; a Free Team is a standalone workspace. Anything org-level - org-wide installs, org-level app grants, the admin.* methods, multi-workspace behaviour - is therefore untestable on a Free Team, so Step 3 now says so in both the target table and 3b.
An empty `sandbox list` looks identical to having no Developer Program account, so the agent reached the create bullet first, asked the developer for a sandbox password, and only then hit the dead end. The no-account guidance now precedes that bullet. The "wait for confirmation" gate also moves out from under 3c into Step 3's intro, so it reads as gating all three targets rather than only the production-workspace path. Reordering only, no new guidance.
| SLACK_CMD sandbox list --team <team_id> | ||
| ``` | ||
|
|
||
| **If the developer has no Developer Program account**, `sandbox list` returns nothing useful, because sandboxes belong to the developer program account whose email matches the authenticated user rather than to the workspace. Point them at <https://api.slack.com/developer-program/join>, and offer the Free Team path in 3b as a way to start building now rather than waiting on signup. |
There was a problem hiding this comment.
note: There is no guarantee the agent will wait while the developer signs up. I'll tackle this in a follow-up because there are many touch-points in this skill that have the same issue.
WilliamBergamin
left a comment
WilliamBergamin
left a comment
There was a problem hiding this comment.
I like this 💯
left a few comments, my only concern is around consistency in the skill 🤔
| | `slack-messaging` | Compose well-formatted Slack messages using standard markdown. | _"Draft a release announcement message with a bulleted list of changes."_ | | ||
| | `slack-search` | Search Slack effectively to find messages, files, channels, and people. Requires a Slack MCP Server connection. | _"Find the channel where we discuss the platform roadmap."_ | | ||
| | `test-slack-app` | Run an existing Slack app in a [developer sandbox](/tools/developer-sandboxes) and get guided, source-specific steps to confirm it works in Slack. | _"Help me check that my Slack app actually works."_ | | ||
| | `test-slack-app` | Run an existing Slack app in a [developer sandbox](/tools/developer-sandboxes) or a Free Team, and get guided, source-specific steps to confirm it works in Slack. | _"Help me check that my Slack app actually works."_ | |
There was a problem hiding this comment.
What do you think about not specifying the team type at all 🪓
| | `test-slack-app` | Run an existing Slack app in a [developer sandbox](/tools/developer-sandboxes) or a Free Team, and get guided, source-specific steps to confirm it works in Slack. | _"Help me check that my Slack app actually works."_ | | |
| | `test-slack-app` | Run a Slack app and get guided, source-specific steps to confirm it works in Slack. | _"Help me check that my Slack app actually works."_ | |
There was a problem hiding this comment.
Good catch @WilliamBergamin and agreed on the reason to generalize away from enumerating every Slack Team type.
I checked with Claude and Codex - I trimmed it slightly differently than your suggestion, because that row is the only link to /tools/developer-sandboxes on the whole page and I didn't want to drop the "not your real workspace" signal entirely - the safety gating is the opinionated part of this skill:
| `test-slack-app` | Run an existing Slack app somewhere safe, like a [developer sandbox](/tools/developer-sandboxes), and get guided, source-specific steps to confirm it works in Slack. | _"Help me check that my Slack app actually works."_ |
"like a" makes the sandbox an example rather than a closed list, so Free Team and production don't need naming and the row stops being a maintenance point.
Commit d28b2cb implements this tweak.
There was a problem hiding this comment.
Added you as a co-author to this change @WilliamBergamin: commit 31d217a
| --- | ||
| name: create-slack-app | ||
| description: 'Use when a developer wants to create, scaffold, or bootstrap a new Slack app or agent from scratch with the Slack CLI. Covers prerequisites, sandbox setup, authentication, and creating + running a project from a Bolt (JS or Python) template locally. Trigger on "create a Slack app", "new Bolt app", "start a Slack agent".' | ||
| description: 'Use when a developer wants to create, scaffold, or bootstrap a new Slack app or agent from scratch with the Slack CLI. Covers prerequisites, authentication, choosing a workspace to install into, and creating + running a project from a Bolt (JS or Python) template locally. Trigger on "create a Slack app", "new Bolt app", "start a Slack agent".' |
| The approach is simple and safe: | ||
|
|
||
| 1. **Run the app in a developer sandbox:** a free, throwaway Slack org for building and testing, never a workspace with real coworkers in it. | ||
| 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. |
There was a problem hiding this comment.
Do we want to remove?
Never a workspace with real coworkers in it.
There was a problem hiding this comment.
@WilliamBergamin Good idea! I did look at relaxing it - but it cascades further than this PR should go. "Never a workspace with real coworkers in it" isn't only in that summary bullet: it's also in the skill's description frontmatter, Step 1 heading, etc.
So I'd rather leave it for now and do it deliberately in a follow-up.
The wording in d28b2cb came from William's review suggestion. That commit was already pushed, so this carries the co-author trailer rather than amending it. Co-authored-by: William Bergamin <wbergamin@salesforce.com>
|
@WilliamBergamin Thanks for the reviews! Your suggestions are solid, but I found that they cascade across the skills and cause additional changes. We may want to think about a |
2 participants
Summary
This pull request adds developer sandboxes, free, and paid teams as install
targets to get a developer without a Slack Developer Program account to a
running app, instead of treating a developer sandbox as the only option.
create-slack-appStep 3 was "Set Up a Developer Sandbox", written as a hardrequirement. The step is now "Choose Where to Install the App" and ranks
three targets:
starting now when program signup is the thing in the way.
app approval usually gates the install, and that
SLACK_AUTO_REQUEST_AAAis anenvironment variable rather than a CLI flag.
test-slack-appnow accepts a Free Team as a safe place to test andpoints at the new step when there is no safe target yet.
Preview
Creating a new app:
Testing an app:
Testing
Notes
Requirements
make testand the tests pass.