Slack with DevFlow: setup, scope and limits

DevFlow's Slack bridge lets a teammate mention a bot in an allowlisted channel, ask about the repository and turn the thread into a task. Plan approval, answers to the planner and mark-done all happen as thread replies. Setup is 3 steps in Workspace Settings → Integrations.

Kind

Chat bridge

Where to set it up

Workspace Settings → Integrations

Plan

All plans

Agent roles

planning, summarizer

Verified

1 Oct 2026

Setup steps

1. Connect the workspace. As a workspace owner, open the Integrations tab of Workspace Settings and click "Connect Slack". After the OAuth install the panel reads "Connected", followed by the bot and team IDs.
2. Save the signing secret and channels. Paste the signing secret of that Slack app, obtained from its operator, into "Signing secret" and list the channel IDs the bot may serve in "Channel IDs", comma-separated, then click "Save". A channel already claimed by another DevFlow workspace is refused.
3. Test the connection. Click "Test connection": "Test OK" means the stored bot token passed Slack's auth check. Then mention the bot in a listed channel with a question about the code.

What it does

A first mention opens a conversation. The planning role explores the default branch of the workspace's first repository read-only, with Read, Grep and Glob and a 3-minute limit, and posts its answer in the thread; it refuses questions about other workspaces or about DevFlow itself.

A reply of go creates the task, gives it a short title written by the summarizer and starts planning, announced with "On it — planning now…". Each conversation holds one active task at a time.

From then on the thread mirrors the task. The planner's questions arrive as a numbered batch, the plan arrives with a link, and later posts report review, failure or completion, the last one with the pull request links.

Replies are routed by what the task is waiting for. At plan review, a reply starting with approve, lgtm, ship it, 👍 or 🚀 approves the plan, and any other text goes back to the planner as feedback; numbered replies answer the questions.

When the workspace parks tasks before implementation, a reply of start or go begins the work, and done marks the task done, which squashes, pushes and opens the pull request. Outside those waiting points, a reply that is neither a control word nor a mention of the bot counts as talk between people and gets no answer.

DevFlow acknowledges every delivery at once and runs the agent work in the background. Retried deliveries are recognized by their message ID, edits and deletions are ignored, and the bot never reacts to its own posts.

Every outbound post is defanged first: broadcast tokens such as <!channel>, <!here> and <!everyone> in agent-written text get a zero-width space, so a plan or a title can never notify a whole channel.

If an exploration fails, or the workspace is over its monthly budget, the thread gets a short apology pointing to DevFlow instead of an answer. A second message that arrives while an exploration is still running does not start another one.

Installing the app again keeps the saved signing secret and channel list and refreshes only the bot token, bot user and team. The OAuth round trip carries the DevFlow workspace in a state value that expires and can be used once.

Requirements

• Slack OAuth is configured on the DevFlow server by its operator: a Slack app with the redirect URL <base>/api/auth/slack/callback, the bot scopes app_mentions:read, chat:write, channels:history, groups:history, users:read and users:read.email, Event Subscriptions pointed at <base>/api/slack/events, and its client ID and secret in SLACK_CLIENT_ID and SLACK_CLIENT_SECRET. Until both are set, the connect button answers that OAuth is not configured.
• The owner role in the DevFlow workspace to connect, configure, test or disconnect; members only see whether a connection exists.
• Every person who writes to the bot needs an account email that DevFlow accepts for login and that belongs to a workspace member or an instance admin.

Limits

• Only channels in the saved list are served, and each channel belongs to one DevFlow workspace at a time; events from any other channel get an empty success reply, so nothing leaks about which channels are configured.
• Each person can send 15 messages per minute per workspace; extra messages are dropped without a reply.
• Event requests must carry a valid signature made with the saved signing secret and be no more than 5 minutes old. The signature is an HMAC-SHA256 of v0:<timestamp>:<body>, compared in constant time before any work starts; a bad one gets HTTP 401, and bodies above 1 MB are rejected.

Sources

Every fact above comes from these files in the DevFlow repository.

• internal/slack/oauth.go
• internal/slack/signing.go
• internal/slack/events.go
• internal/slack/provider.go
• internal/api/handlers_slack.go
• internal/api/helpers.go
• internal/api/server.go
• internal/api/chat_pipeline.go
• internal/chatbridge/bridge.go
• internal/chatbridge/intent.go
• internal/chatbridge/outbox.go
• internal/api/handlers_auth.go
• internal/agent/planning.go
• internal/db/chat.go
• internal/secrets/secrets.go
• internal/notify/dispatcher.go
• internal/api/handlers_notification.go
• web/src/lib/components/SlackConnect.svelte
• web/src/lib/components/WorkspaceSettings.svelte