feat(slack): add reply_in_thread config option

gateway/platforms/slack.py

@@ -323,7 +323,18 @@ def _resolve_thread_ts(
 
         Prefers metadata thread_id (the thread parent's ts, set by the
         gateway) over reply_to (which may be a child message's ts).
+
+        When ``reply_in_thread`` is ``false`` in the platform extra config,
+        top-level channel messages receive direct channel replies instead of
+        thread replies.  Messages that originate inside an existing thread are
+        always replied to in-thread to preserve conversation context.
         """
+        # When reply_in_thread is disabled (default: True for backward compat),
+        # only thread messages that are already part of an existing thread.
+        if not self.config.extra.get("reply_in_thread", True):
+            existing_thread = (metadata or {}).get("thread_id") or (metadata or {}).get("thread_ts")
+            return existing_thread or None
+
         if metadata:
             if metadata.get("thread_id"):
                 return metadata["thread_id"]

website/docs/user-guide/messaging/slack.md

@@ -217,6 +217,23 @@ In channels, always @mention the bot. Simply typing a message without mentioning
 This is intentional — it prevents the bot from responding to every message in busy channels.
 :::
 
+### Reply Threading
+
+By default, Hermes replies in a **thread** attached to the original message in channels. If your team prefers replies to go **directly to the channel** instead, you can disable threading:
+
+```yaml
+platforms:
+  slack:
+    extra:
+      reply_in_thread: false
+```
+
+When `reply_in_thread` is `false`:
+- **Channel messages** — Hermes replies directly in the channel (no thread created)
+- **Thread messages** — Hermes still replies inside the existing thread to preserve conversation context
+
+The default is `true` (threaded replies), which matches the original behavior.
+
 ---