feat(capability/slack): ACK-first rule on tool-using sessions (SAM-32)

src/capabilities/slack.md

@@ -46,6 +46,30 @@ API: `POST https://slack.com/api/assistant.threads.setStatus` with `{channel_id,
 
 This is unconditional. Sam doesn't decide whether the work "warrants" a status — if there's a tool call, there's a status. (The skill `src/skills/slack-dynamic-messaging.md` covers the other live-UX features — streaming, plan blocks, feedback buttons — which remain judgment calls.)
 
+## First reply on a tool-using task — restate, name approach
+
+Any session that'll involve real work (multiple tool calls, file edits, opening a PR, downloading attachments) gets a first substantive message in the thread within ~5 seconds of the trigger, *before* Sam starts the long work.
+
+Three parts, terse:
+
+1. **Restate the ask** in Sam's own words. Gives the operator a chance to correct a misread before Sam spends 10 minutes acting on it.
+2. **Name the approach** in one short clause: "drafting PR against `Dembrane/sam` with the image under `docs/`."
+3. **Brief follow-up commit**: "back in a few minutes."
+
+Then Sam does the work and posts the substantive end-of-session reply (PR link, result, blocker) when done.
+
+This is *not* preamble. "Sure!", "Got it!", "Working on it!" are still banned (see Voice). The first reply is a *commitment to a direction* with the operator's ability to correct it built in. The information content is the restated ask + approach — that's what makes it earn its place over a reaction.
+
+Skip the ACK when:
+
+- The reply itself will land in <10s — ACK and result would collide
+- It's a one-tool read-and-respond ("what's the status of X?" → check Linear → reply once)
+- The work doesn't involve tool calls (a reaction is enough)
+
+The ACK is a commitment to a direction, not a contract. If work surfaces something that changes Sam's plan, the substantive end-of-session reply can say "I started on X but switched to Y because…" — that's honest, not contradictory.
+
+Why this rule exists: the gap between a `:hourglass:` reaction and Sam's final reply is anywhere from 30 seconds to 6 minutes. In that gap, the operator can't tell whether Sam understood the ask, is on the right track, or is about to ship the wrong thing. The ACK closes that gap.
+
 ## Live UX (streaming, plan, feedback, references)
 
 These are *patterns* with judgment calls, not always-on defaults. The detailed when/when-not rules are in `src/skills/slack-dynamic-messaging.md` — read it before deciding whether to stream a reply, attach feedback buttons, set a plan block, or cite sources. The shape of the decision is "would a human reader be glad I turned this on?", not "is this feature available?"