Slack Messaging

Slack Messaging

Read, send, search, draft, and schedule Slack messages across channels and threads. This skill wraps the Slack MCP tools with clear workflows and -- critically -- enforces context boundaries: thread conversations keep their context within a single session, while each new channel-level conversation gets a fresh session.

Why Context Boundaries Matter

Slack conversations have natural scoping. A thread is one continuous discussion -- if you lose context mid-thread, your replies become disjointed and unhelpful. But two unrelated messages in a channel are separate conversations -- mixing their context causes confusion and information leakage between topics.

This skill enforces these boundaries so your Slack interactions stay coherent:

• Thread = one session. All replies within the same thread share context. You remember what was said earlier in the thread and can reference it.
• New channel message = new session. Each top-level message you respond to in a channel starts fresh. No carryover from previous conversations.

Session Management Rules

When to Keep the Same Session (Thread Continuity)

Stay in the same Claude Code session when:

1. You are replying to a thread and need to send a follow-up reply in that same thread
2. The user asks you to continue a conversation you already started in a thread
3. You are reading and responding to multiple messages within a single thread
4. The user says things like "reply again", "follow up", "add to that thread", "also mention..."

In practice: if you have a thread_ts and you're sending another message with the same thread_ts, you are in the same conversation. Keep your context.

When to Start a New Session (Channel Isolation)

Start a new Claude Code session (fresh context) when:

1. The user asks you to respond to a different top-level message in a channel
2. You move from one channel conversation to an unrelated one
3. The user asks you to "check Slack" or "read messages" in a channel -- each message that needs a response is its own session
4. The user says things like "now respond to that other message", "handle the next one", "what about the message from [someone else]"

How to start a new session: Tell the user explicitly: "This is a separate conversation. To keep context clean, please start a new Claude Code session (claude in terminal) for this response." If running autonomously, use subagents -- each top-level channel message gets its own subagent to maintain isolation.

Available Tools

All tools are accessed via the Slack MCP integration. Here is what each one does and when to use it:

Resolving IDs

Most tools require channel_id rather than channel names. Always resolve names to IDs first:

1. Channel: Use slack_search_channels with the channel name (e.g., query "engineering") to get the channel_id
2. User: Use slack_search_users with the person's name or email to get their user_id (usable as channel_id for DMs)

Cache resolved IDs within your session to avoid redundant lookups.

Core Workflows

1. Read Channel Messages

1. Resolve channel name -> channel_id (slack_search_channels)
2. Read messages (slack_read_channel with channel_id)
3. Present a summary: who said what, timestamps, thread indicators
4. If a message has thread replies, note the reply count

Tip: Use limit to control how many messages to fetch (default 100, max 100). Use oldest/latest timestamps to narrow a time range.

2. Read a Thread

1. Get the channel_id and parent message's timestamp (message_ts)
2. Read thread (slack_read_thread with channel_id + message_ts)
3. Present the full conversation in order

The message_ts is the timestamp of the parent message that started the thread. You get it from slack_read_channel results or from a link the user shares.

3. Send a Channel Message

1. Resolve channel_id
2. Draft the message content
3. Show the draft to the user for approval
4. Send (slack_send_message with channel_id + message)
5. Report the message link back to the user

4. Reply in a Thread

1. Get channel_id and the parent message's thread_ts
2. Read the existing thread for context (slack_read_thread)
3. Draft your reply informed by thread context
4. Show draft to user for approval
5. Send (slack_send_message with channel_id + message + thread_ts)
6. Report the message link

Set reply_broadcast: true if the reply should also appear in the main channel (the user must request this -- don't default to it, as it notifies everyone in the channel).

5. Draft a Message (Without Sending)

1. Resolve channel_id
2. Compose the message
3. Save draft (slack_send_message_draft)
4. Tell the user where to find it: Slack's "Drafts & Sent" section

Only one draft per channel is allowed. If a draft already exists, tell the user to edit or delete it in Slack first.

6. Schedule a Message

1. Resolve channel_id
2. Compose the message
3. Convert the desired time to a Unix timestamp (must be at least 2 minutes in the future, max 120 days)
4. Schedule (slack_schedule_message with channel_id + message + post_at)
5. Confirm the scheduled time to the user

7. Search Messages

1. Choose search scope:
   - Public only: slack_search_public (no consent needed)
   - All channels: slack_search_public_and_private (ask user consent first)
2. Build query with modifiers:
   - in:#channel-name  — filter by channel
   - from:@username    — filter by author
   - before:/after:/on:YYYY-MM-DD — date filters
   - "exact phrase"    — exact match
   - is:thread         — only threaded messages
3. Present results with context

8. Monitor and Respond to Channel (Multi-Message)

This is where session management matters most. When the user asks you to "check Slack and respond to messages":

1. Read the channel (slack_read_channel)
2. Identify messages that need responses
3. For each message that needs a response:
   a. If it's a thread reply -> read the full thread first (same session if it's one thread)
   b. If it's a new top-level message -> TELL THE USER to handle it in a new session
      OR spawn a subagent for isolation
4. Draft each response with appropriate context
5. Get approval before sending anything

The critical rule: never mix context between unrelated channel conversations. If you're handling message A about a deployment issue and message B about a team lunch, those are separate sessions.

Message Formatting

Slack uses its own markdown variant (mrkdwn). Follow these rules:

Do NOT use **double asterisks** or ## headers -- they don't render in Slack.

Approval Before Sending

Never send a message without the user's explicit approval. The workflow is always:

1. Draft the message
2. Present it: show the exact text, the target channel/thread, and who will see it
3. Wait for "send it", "looks good", "approved", or similar confirmation
4. Send only after approval
5. Report the message link

This exists because Slack messages are visible to your team immediately. A poorly worded message, a reply in the wrong thread, or an accidental channel ping can't be unseen. The 10-second approval step prevents real embarrassment.

DMs (Direct Messages)

To send a DM, use the recipient's user_id as the channel_id in slack_send_message. Find their user_id with slack_search_users.

To read DMs, use slack_read_channel with the DM channel ID. You can find DM channels by searching with slack_search_public_and_private using in:@username.

Error Handling

Quick Reference: Tool Selection