From 09eebf19671cf3980016487ae7644a53b8f45095 Mon Sep 17 00:00:00 2001 From: Sameer Pashikanti Date: Sat, 23 May 2026 16:32:32 +0200 Subject: [PATCH] feat(capability/slack): ACK-first rule on tool-using sessions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add "First reply on a tool-using task" section to src/capabilities/slack.md. Closes the operator-UX gap surfaced today: on the README + image ask, the operator waited ~4 minutes seeing only :eyes: + :hourglass: with no signal of what Sam understood, what approach Sam was taking, or whether to redirect. By the time Sam replied, Sam had spent 11 min going down a misread "ur in gcp" hint into the wrong metadata-server token path — the operator had no window to course-correct. The rule: any session that'll involve real work posts a substantive first reply within ~5s that restates the ask, names the approach, and commits to a follow-up. Then the work proceeds. The end-of-session substantive reply is unchanged. Sits under "Posting to Slack" / before "Live UX" in slack.md so it lands on the Sam-as-coworker behavior in the right narrative spot. Distinct from the existing "Status indicator — always" rule (which only covers the status pill, not a substantive restatement of intent). Validation is deferred to the SAM-26 eval harness — golden-set ambiguous-bucket sessions can score whether Sam ACKed and whether the ACK was substantive. If the rate is consistently low after this lands, SAM-32 has a follow-on (Option C in the ticket — daemon-driven floor). Refs: SAM-32. Related: SAM-31 (mid-flight steering depends on the ACK existing to anchor against), SAM-26 (validation). --- src/capabilities/slack.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/src/capabilities/slack.md b/src/capabilities/slack.md index 62ec65d..f15859f 100644 --- a/src/capabilities/slack.md +++ b/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?"