Skill

Build Slack Apps with Bolt Framework

Slack Bot Builder is a skill for building Bolt-framework Slack apps: commands, Block Kit UI, OAuth, Socket Mode, and Workflow steps.

Works with slack

71
Spark score
out of 100
Updated 3 days ago
Version 15.5.1

Add to Favorites

Why it matters

Develop robust Slack applications using the Bolt framework, enabling rich user interfaces, interactive components, and seamless integration with Slack's features.

Outcomes

What it gets done

01

Generate Python, JavaScript, or Java code for Slack apps.

02

Implement interactive UI elements using Block Kit.

03

Handle events, slash commands, and modal submissions.

04

Integrate with Slack's OAuth and Workflow Builder.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-slack-bot-builder | bash

Overview

Slack Bot Builder

Slack Bot Builder is a skill for building Bolt-framework Slack apps: event/command/modal handlers, Block Kit UI, OAuth installation, Socket Mode, and Workflow Builder steps, plus named production sharp edges. Use it for Bolt-based Slack apps and bots. Delegates AI conversation, SMS/voice escalation, cross-platform bots, enterprise auth, storage, and scaling to sibling skills.

What it does

Slack Bot Builder is a skill for building production Slack apps with the Bolt framework across Python, JavaScript, and Java. It covers five core patterns - the Bolt app foundation (event, command, modal, button, and Home-tab handlers, with Socket Mode for dev vs. HTTP for production), Block Kit rich UI (blocks, buttons, select menus, overflow menus, confirmation dialogs), OAuth installation (scopes, workspace-specific tokens, persistent installation storage), Socket Mode itself (WebSocket-based, no public URL, for dev or firewalled environments), and Workflow Builder custom steps (an edit/save/execute lifecycle with typed inputs and outputs) - plus a named set of production sharp edges and automated validation checks for each.

When to use - and when NOT to

Use it for any Bolt-based Slack app or bot: slash commands, interactive Block Kit messages, OAuth app distribution, Socket Mode development, or custom Workflow Builder steps. It explicitly delegates outside its own scope: an AI-powered conversational bot routes to llm-architect; escalating Slack alerts to SMS or voice goes to twilio-communications; using Slack as a trigger or action inside n8n or Temporal workflows goes to workflow-automation; a cross-platform bot that also needs Discord goes to discord-bot-architect; a full enterprise SSO/auth system goes to auth-specialist; persisting installations or message history goes to postgres-wizard; and scaling webhooks or monitoring goes to devops. Socket Mode itself is explicitly flagged as unsuitable for high-volume production - a single WebSocket connection with no horizontal scaling - so production traffic should use HTTP endpoints instead.

Inputs and outputs

Input: the kind of Slack app being built (foundation, Block Kit UI, OAuth, Socket Mode, or workflow step) and its language. Output: working Bolt code plus checks against seven named sharp edges - a missing 3-second acknowledgment on slash commands, buttons, or modals (CRITICAL, fixed via ack-then-background-processing or Bolt's lazy listeners), an unvalidated OAuth state parameter (CRITICAL CSRF risk, fixed via a state store's issue/consume pattern), exposed bot/user/app tokens (CRITICAL - xoxb-, xoxp-, and xapp- prefixed tokens each carry full scope access; fixed via env vars, no logging, at-rest encryption, and rotation), unnecessary OAuth scopes (HIGH, guided by a scope-by-use-case table such as chat:write alone for a notification bot), exceeded Block Kit limits (MEDIUM - 50 blocks per message, 3000 characters per text block, 10 elements per actions block, 24KB per modal), Socket Mode used in production (HIGH, needs reconnect-with-backoff if unavoidable), and unverified request signatures (CRITICAL - Bolt verifies automatically via signing_secret; otherwise manual HMAC verification is required).

def verify_slack_signature(request):
    timestamp = request.headers.get("X-Slack-Request-Timestamp", "")
    signature = request.headers.get("X-Slack-Signature", "")

    # Reject old timestamps (replay attack prevention)
    if abs(time.time() - int(timestamp)) > 60 * 5:
        return False

    # Compute expected signature
    sig_basestring = f"v0:{timestamp}:{request.get_data(as_text=True)}"
    expected_sig = "v0=" + hmac.new(
        SIGNING_SECRET.encode(),
        sig_basestring.encode(),
        hashlib.sha256
    ).hexdigest()

    # Constant-time comparison
    return hmac.compare_digest(expected_sig, signature)

A further nine automated validation checks flag hardcoded tokens or signing secrets, missing signature verification, client-side token exposure, missing or premature ack() calls, unvalidated OAuth state, unencrypted token storage, and over-broad (especially admin) scopes.

Integrations

Composes with llm-architect (LLM-powered bots), twilio-communications (SMS/voice escalation), workflow-automation (n8n/Temporal triggers), discord-bot-architect (cross-platform bots), auth-specialist (enterprise SSO), postgres-wizard (persisting installations and history), and devops (scaling and monitoring webhooks) - each triggered by a specific need named in the skill's own delegation rules.

Who it's for

Developers building Slack apps with Bolt who want validated patterns for commands, Block Kit UIs, OAuth distribution, Socket Mode, and Workflow Builder steps, plus a checklist of the specific security and reliability failures - ack timeouts, CSRF, token exposure, over-broad scopes, Block Kit limit violations, Socket Mode misuse, unverified signatures - that repeatedly break Slack bots in production.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.