AI Tools
How to Build a Slack Bot With Claude Code
How to build a Slack bot with Claude Code: the Slack app pieces it needs to generate, the One-Trigger Rule for judging a first build, and the Socket Mode shortcut that skips a public server for local testing.
Founder, AI Tools and Training Club · August 30, 2026 · 9 min read
The short version
- You can build a working Slack bot with Claude Code without a developer on staff - it writes the Slack app manifest, the bot logic, and the Socket Mode connection that lets it run and get tested from your own machine with no public server required.
- Every Slack bot needs a Slack app registered at api.slack.com with specific OAuth scopes before it can do anything - naming the exact scopes up front, and reinstalling the app any time you add one, avoids the most common first-build failure.
- Judge a first build against the One-Trigger Rule: it's working the moment the one event you built it for - a slash command, a keyword mention, a button click - fires reliably in your real workspace, not when every channel and command you imagined exists.
The short answer
Yes, you can build a real Slack bot with Claude Code without hiring a developer. You register a Slack app at api.slack.com, tell Claude Code what the bot should listen for and what it should do in response, and it generates the app logic using Slack's own SDK. The fastest path to testing skips a public server entirely - Socket Mode lets the bot run from your own laptop or a small always-on machine and still receive events from your live Slack workspace. Building the bot and hosting it somewhere permanent are two separate steps, and this post covers both.
Why I built one instead of adding another app to the workspace
A member's team kept asking the same question in their project channel every week - which client accounts were still waiting on a signed contract. Someone had to stop, open the tracker, and type the answer back manually, every time, and the answer was always sitting in a spreadsheet the whole team already had access to.
So we asked Claude Code to build the smallest version instead: one slash command, one lookup against that spreadsheet, post the answer back in the channel. Not a full ops bot, a real test of whether removing that one recurring question actually saved anyone time once it existed. How to build an internal tool with Claude Code instead of buying software covers the same instinct applied to a full internal tool - the Slack bot version is the same logic scoped down to one channel.
What a Slack bot actually needs, specifically
A Slack bot is a specific, predictable set of pieces, and Claude Code knows the shape of all of them. The one piece worth doing yourself before you start is registering the app at api.slack.com - Claude Code can write everything after that, but the app has to exist in your workspace first.
| Piece | What it does | Why it matters for a first build |
|---|---|---|
| Slack app manifest | Declares the app's name, the OAuth scopes it needs, and which events or commands it listens for | Slack won't let the bot do anything - read a channel, post a message - without the matching scope declared here first |
| Bot User OAuth Token | Authenticates the bot's own actions inside your workspace, separate from your personal login | This is the credential the code uses to actually post or read - keep it out of anything you'd ever share publicly |
| Socket Mode connection | Lets the bot receive events over a persistent connection instead of a public HTTPS endpoint | Skips standing up a server just to test - the bot can run from your own machine during development |
| Event or command handler | The actual logic - what happens when the trigger fires | This is the one piece that's genuinely different per bot; everything above it is boilerplate Claude Code has seen many times before |
The pieces Claude Code generates
How I built it
- Wrote down the single trigger and the single response, in one sentence, before opening Claude Code - a slash command that returns one specific answer, not a general-purpose assistant.
- Registered a new app at api.slack.com, turned on Socket Mode, and generated an App-Level Token with the connections:write scope - the one scope Socket Mode itself requires regardless of what the bot does.
- Described the bot to Claude Code in plain language and asked for a build, naming the specific event or slash command and the exact OAuth scopes it would need.
- Installed the app to the workspace, which is the step that actually grants the scopes, then ran the bot and tested the real trigger in a private test channel before touching the team's live channel.
- Went back to Claude Code with the specific thing that didn't work - a scope Slack rejected, a message format that looked wrong - and fixed one issue at a time instead of listing every improvement up front.
What broke, and what actually goes into running it long-term
My first version worked fine talking to itself in a test channel and then failed the first time a teammate used it - the bot could read the message but couldn't post a reply, because chat:write was declared in the manifest but the app had never been reinstalled after adding it. Slack's permission model is specific on purpose, and a scope mismatch between the manifest and the actual installed app is the single most common thing that works in one channel and silently fails in another.
Socket Mode is the right choice for building and testing, but a bot you want running for the team every day needs a small always-on host - your laptop going to sleep takes the bot offline with it. That's a separate, later decision: a lightweight server or a small always-on machine, not a rebuild of the bot itself.
The One-Trigger Rule, and when a real integration platform wins
Judge a first Slack bot against the One-Trigger Rule: it's working the moment the one event you built it for fires reliably, in your real workspace, on the actual channel people use - not when every command and edge case you imagined exists. A one-command bot that reliably answers the one question beats a feature-heavy one where half the commands quietly don't respond.
The honest limit is real too. If you need the bot to handle dozens of commands, manage complex permission levels across teams, or integrate with several other systems at once, that's a genuinely bigger build than a first Claude Code pass is meant to cover - and at that point, Slack's own Workflow Builder or a developer who has shipped Slack apps before is worth using. This workflow is for one narrow, well-defined trigger, not a replacement for a real Slack integration once the scope grows past that.
How I coach members through this build
When a member describes a repetitive Slack question or task, I ask whether it's genuinely one trigger and one response, or a bigger workflow wearing a Slack bot's clothes. The ones that fit are narrow: answer this one question, post this one update, log this one action, every time someone types this one command. The ones that don't fit usually turn out to be a full internal tool that happens to live in Slack, which is a different build.
How to connect your apps with automation is worth a read before you build the bot version of a task - if the data already lives in a tool with a scheduled automation option, a scheduled workflow might replace the manual Slack question entirely without a bot in the middle.
Frequently asked questions
Do I need to know how to code to build a Slack bot with Claude Code?
No. You describe the one trigger and the one response in plain language, and Claude Code writes the app logic. The one step you have to do yourself is registering the app at api.slack.com and installing it to your workspace, which takes a few minutes and doesn't require writing code.
Do I need a public server to run a Slack bot?
Not to build and test it. Socket Mode lets the bot connect to Slack over a persistent connection instead of a public HTTPS endpoint, so it can run from your own machine during development. Running it for your whole team every day does eventually need a small always-on host, since your laptop going to sleep takes the bot offline with it.
Why does my bot read messages but not post replies?
This is almost always a scope mismatch. Reading messages and posting messages are separate OAuth scopes (for example channels:history versus chat:write), and Slack requires you to reinstall the app to your workspace every time you add a new scope. If the bot can do one but not the other, check that the missing scope is both declared in the manifest and that you've reinstalled since adding it.
Can one Slack bot handle multiple commands?
Yes, as long as you give it a handler for each one. The practical limit is complexity - a bot juggling many unrelated commands, permission levels, and integrations becomes harder to test and maintain than the one-trigger version this post describes. Start narrow, then add a second command once the first one is genuinely working in your team's real channel.
Should every repetitive Slack question become a bot?
Not always. If the answer changes rarely and the data already lives in a tool with its own scheduled automation option, a scheduled workflow can often replace the manual question without a bot in the middle. Build the bot version specifically when someone has to ask, in the moment, inside Slack.