feat(slack): thread-aware reply routing and App Home DM fix

[rvanmelle]

Summary

Three improvements to the Slack channel skill, discovered during real-world setup on a Raspberry Pi 5 (ARM64, Docker runtime).

1. Missing App Home DM setup step (docs fix)

Slack silently blocks DMs to the bot unless "Allow users to send Slash commands and messages from the messages tab" is enabled in App Home settings. This setting is completely separate from event subscriptions and OAuth scopes — no API error is surfaced when it's missing, making it very difficult to diagnose.

• Added as Step 5 in SLACK_SETUP.md (renumbered subsequent steps)
• Added as item 5 in SKILL.md quick summary
• Added "Bot not responding to DMs" troubleshooting entry
• Added note that the reinstall yellow banner doesn't always appear after scope/event changes

2. Thread-aware reply routing

Default behaviour (no config change needed):

• Message in a thread → bot replies in that same thread
• Message in the channel root → bot replies in the channel

SLACK_ALWAYS_REPLY_IN_THREAD=true:

• Message in a channel thread → bot replies in that thread
• Message in a channel root → bot starts a new thread anchored to that message
• DM → bot always replies directly, regardless of this setting (see below)

Implementation: Self-contained in SlackChannel with a pendingThreadTs: Map<string, string> that carries thread context from the incoming message event to the outgoing sendMessage call. No changes to the Channel interface, DB schema, or other channels.

Also fixes a TypeScript error: resolveUserName() called with msg.user ?? '' to handle the undefined case on BotMessageEvent.

3. Fix: DM replies broken when SLACK_ALWAYS_REPLY_IN_THREAD=true

When SLACK_ALWAYS_REPLY_IN_THREAD was enabled, DM replies were silently sent with a thread_ts, causing Slack to route them into a thread panel rather than the main DM conversation — invisible to the user, with no error surfaced. This is the same class of silent failure as the App Home issue. The fix skips always-in-thread mode for DM channels (channel_type === 'im').

Design trade-off / future direction

This implementation deliberately keeps thread context in-memory and local to SlackChannel to avoid pipeline-wide changes. The consequence is that thread_ts is never persisted: the DB stores the message content, sender, timestamp, and JID, but not which Slack thread the message belonged to. Threaded replies and root channel messages are indistinguishable in stored history, and if the process restarts between receiving a message and sending the reply, the thread context is lost.

A "proper" pipeline-wide solution would store thread_ts (or a generic thread_id) as an optional field on every message and propagate it through the NewMessage type, Channel.sendMessage, and the router. This would give the agent awareness of thread structure and make history queryable by thread.

Slack is unlikely to be the only channel where this matters — Telegram supports threaded replies, Discord has forum channels, and future channels may too. If the maintainer would prefer to land a consistent thread_id field across the pipeline first, this PR could be held or rebased on top of that work. The in-memory approach is offered as a pragmatic first step that is fully correct within its constraints and easy to replace later.

Tests

8 new unit tests added to slack.test.ts covering:

• Threaded reply → postMessage includes thread_ts
• Root channel message → no thread_ts in postMessage
• thread_ts === ts (thread parent/root) → treated as root, no thread_ts
• Thread context cleared after first sendMessage
• Queued messages preserve thread context through disconnect/reconnect
• SLACK_ALWAYS_REPLY_IN_THREAD=true: root channel messages reply in new thread
• SLACK_ALWAYS_REPLY_IN_THREAD=true: threaded replies use existing thread_ts
• SLACK_ALWAYS_REPLY_IN_THREAD=true: DM root messages reply directly (no thread_ts)

All 54 Slack unit tests pass.

Manual testing

Tested on Pi5 (ARM64, Docker runtime) with a real Slack workspace:

• ✅ DMs to the bot work after enabling the App Home checkbox
• ✅ Message in channel root → bot replies in channel (default)
• ✅ Reply in a thread → bot replies in the same thread
• ✅ SLACK_ALWAYS_REPLY_IN_THREAD=true → root channel message starts a new thread
• ✅ SLACK_ALWAYS_REPLY_IN_THREAD=true → threaded reply continues in the same thread
• ✅ SLACK_ALWAYS_REPLY_IN_THREAD=true → DM replies directly (not threaded)

🤖 Generated with Claude Code

[TomGranot]

Thread-aware reply routing for Slack is a nice addition. @gavrielc this touches the routing layer so would appreciate a sanity check.

[blozano-tt]

I would appreciate this as well. Its way too noisy in a slack channel, when the bot just replies in channel instead of thread.

I have burned a lot of Opus tokens, trying to adapt the default architecture to support reply in thread. Maybe its working now.

The main challenge was dealing with concurrent messages from two different threads.