--- name: mindset-slack-connection description: Use when a Mindset (mindset.ai) agent should post messages or links to Slack channels, through the mindset-admin MCP server. Sets up a Slack bot connection, or reuses one the Org already has. Use whenever the user wants an agent to post to Slack, send a link in Slack, or connect Slack. metadata: title: Let an agent post to Slack blurb: A Slack bot in your own workspace that a Mindset agent posts messages and links through. group: Examples order: 2 docs: connections-and-operations, connect-a-system checked: 28ab3d642 updated: 2026-10-26 --- # Let an agent post to Slack The user wants a Mindset agent to post to Slack. The Slack app lives in their own workspace, so only they can create and install it. Your job is to tell them exactly what to paste and where, then do the Mindset side yourself. This skill is a pointer. The recipe lives on the platform, in `get_information`, and it is current for the platform you're connected to. ## Where you are building: host, org, environment Every Mindset call names three things. Get all three from the person before you write code or call a tool. Never guess or invent them. | Value | What it is | Where the person finds it | |---|---|---| | **Host** | The Mindset deployment their org lives on, for example `https://eu.mindset.ai` | The address bar when they're signed in to the Studio, or an agent's **Embed** tab | | **Org slug** | Their company's account. The org is the isolation boundary: members, model keys, settings and audit sit here, and one org can never see into another | An agent's **Embed** tab, or the address under **Settings → Systems → Connect an AI client** | | **Environment slug** | A named partition inside the org, such as Sandbox, Test or Production | An agent's **Embed** tab, or the same address. The **Environment** switcher in the Studio shows which one is current | How environments behave: - **Agents, scripts, functions, connections, triggers, schedules, conversations, runs and API keys each belong to exactly one environment** and can't see anything in another. - **Every org starts with one environment, Sandbox, whose slug is `original`.** A slug never changes, even when the environment is renamed. Use the slug, never the display name. - **Nothing copies between environments.** To promote a change from Test to Production, make the same change again in Production. - **Don't create an environment to hold your work.** Environments can't be deleted, and they're for stages such as Test and Production, not for projects. Work in the environment the person names. Create one only if the person asks you to. - **Members, model keys and org settings are shared by every environment.** Changing an org setting changes it everywhere. ## Before you start This skill works through the `mindset-admin` MCP server. Check that its tools (for example `get_information`) are available to you. If they aren't, set the server up first, following the `mindset-mcp` skill or https://docs.mindset.ai/docs/work-from-claude-code.md, then come back here. Call `get_information` with no arguments for the platform's own topic index. Its guidance is current for the platform you're connected to. Where it and this skill disagree, follow `get_information`. ## Credentials for building in Mindset: sign in, never a key You build inside Mindset through the **`mindset-admin` MCP server**. The person signs in with their own Mindset account in a browser, and they must be an org admin. There is no key or token, so never ask the person for one. - **The server address names one environment**: `/api/v1/orgs//envs//mcp`. Every call goes to that environment unless the tool call passes `envSlug` to point that one call at another environment. Org-level tools refuse an `envSlug`. - **No tool takes a secret value.** When a connection needs a credential, call `request_capture`. It returns a reference and a capture URL. Give the person the URL to open and paste the value into themselves, then use the reference. Capture links expire after 15 minutes. For a system that signs in with OAuth, `authorize_connection` returns a sign-in link the person opens the same way, and it expires after 10 minutes. If a link has expired, request a new one. Never ask the person to paste a credential into the conversation, even if they offer. - **Errors come back structured.** Read `code` and `context` and act on them. Don't retry blind. ## Read first 1. `get_information` topic `authoring:connection:provider:slack`: the one Slack shape (the `slack_app` adapter), its three values, creating and publishing the connection, the `post_message` operation and why it always carries `blocks`, and the channel invite. 2. `get_information` topic `slack-approvals-setup`: the app manifest to paste (one scope, `chat:write`, and no interactivity block), where each value lives in Slack, and the Signing Secret that is easy to confuse with the Client Secret. Its manifest names the bot "Approvals"; use the name the user chooses. Slack's manifest box has a YAML tab and a JSON tab, and a paste only works in the matching tab: say which one. None of the app's values exists until the app is installed, so request the captures only then, in one go. 3. `get_information` topic `authoring:connection:operations`: `post_message` is a write, which may wait for an admin's approval, and it reaches an agent only after the three acts that topic names, which the platform refuses until the connection is published. For an agent that posts on a schedule, also read `authoring:trigger`. 4. Only if the user wants clickable buttons inside the Slack message: `slack-approvals-authoring`, and the Request URL step in `slack-approvals-setup`. A flow that sends a link needs no interactivity. 5. Only if Slack should start an agent: that is a second, separate app. Read `authoring:connection:provider:slack-events` and `webhook-sources`, and don't widen the posting app. ## Before you build anything 1. Tell the user which Org and Environment you're in (every reply from the server names them), and build only where they asked. 2. Call `list_resources` with `type: "connection"` (it has no adapter filter) and look for `adapter: "slack_app"` in what comes back. If there are any, show them by name and ask whether to reuse one. 3. **Reusing one:** ask for no keys, because they're already bound. List its operations (`list_resources` with `type: "connection_operation"` and `filter: {"connection": ""}`), check `post_message` is there and not waiting for approval, then ask which channel to post to. 4. **A new one:** ask whether they can create apps in their workspace (some workspaces need an admin to approve new apps), and what the bot should be called. 5. **Say what isn't possible:** the bot posts only in channels it has been invited to, and with this manifest it reads no messages at all, direct messages included. If the use case needs reading, say so plainly. ## Working with the user - Give one numbered step at a time for anything they do in Slack, and wait for them to confirm each one. - Never fill a missing value with a placeholder. Say which value you're waiting for, and stop. ## Read more https://docs.mindset.ai/docs/connections-and-operations.md explains connections and operations for people. ## Done means The user has seen a real test message from the bot in the channel they chose, and the agent holds `post_message`. Send the test with `test_resource` in `invoke` mode; it asks for a go-ahead first, as `authoring:connection_operation` describes. "Published" isn't done.