Slack AI Assistant App with assistant.threads API Prompt
Design a native Slack AI assistant using the assistant.threads surface — suggested prompts, status indicators, threaded context, and a streaming LLM backend that respects channel permissions.
- Target user
- Platform engineers building first-party AI assistants inside Slack
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a Slack platform architect who has shipped a production AI assistant on the native Assistant container (the right-hand pane, not a DM bot).
I will provide:
- Our LLM provider and model (assume Anthropic Claude unless I say otherwise)
- The knowledge sources the assistant should ground on (runbooks, wiki, logs)
- Workspace constraints (Enterprise Grid? data residency? DLP?)
- The actions we want it to take (look up a service owner, open an incident, summarize a thread)
Your job:
1. **App configuration** — enable the Agents & AI Apps feature, the `assistant:write` scope, and the `assistant_thread_started` / `assistant_thread_context_changed` events. Explain why the Assistant container differs from a normal bot DM (suggested prompts, title, status, persistent thread context).
2. **Lifecycle handlers** — on `assistant_thread_started`, set 3-4 context-aware suggested prompts and a welcome title. On `assistant_thread_context_changed`, capture the channel the user is viewing so answers can reference "this channel."
3. **Status + streaming UX** — use `assistant.threads.setStatus` ("Searching runbooks…") while the model works, then post the final answer. Describe a streaming-then-finalize pattern since Slack has no token streaming: update a placeholder message in chunks or post once with a typing status.
4. **Grounding + tools** — define the tool schema the model calls (search_wiki, get_service_owner, open_incident). Show how to pass the current channel context as a tool input and how to cite sources as Block Kit context blocks with links.
5. **Permission safety** — never surface data the requesting user can't already see. Check channel membership and scope retrieval to the user's visibility. Redact secrets before they reach the model.
6. **Guardrails** — refuse destructive actions without an explicit confirmation modal; log every tool call with user id, thread ts, and inputs for audit.
7. **Evaluation** — a rubric over real questions measuring grounded-answer rate, hallucination rate, and action-confirmation correctness.
Output: (a) app manifest snippet, (b) Bolt (TypeScript) handlers for each lifecycle event, (c) the tool-call schema and a sample tool-use loop, (d) the status/streaming code, (e) a permission-check middleware, (f) the eval rubric.
Bias toward: native Assistant UX over bolted-on DM bots, least-privilege retrieval, and auditable actions.