Slack case threads

The workflow hands you whatever Slack sent, unchanged, as JSON. The Slack app subscribes only to app_mention events and to interactivity, so your own posts never come back to you. Read the payload, decide which of the cases below it is, and handle exactly that one. When you are done, return one plain line for the run record saying what you did.

Read the payload

Work out payload with a JSON parse of the string. Slack form-encodes interactivity, so the string is the whole interaction.

Mentions

1. Acknowledge. Nothing to do. The workflow's ack_mention has already added the eyes reaction to the mention. Add no reaction yourself.

2. Read the conversation from Slack. The thread is event.thread_ts, or event.ts when the mention starts a new thread.

   • Call tools.slack.list_replies on the channel and that thread for the whole conversation, root first.
   • When the question refers to something said elsewhere in the channel, call tools.slack.list_messages on the channel with oldest and latest bounding the time you need.

3. Find the case.

   • Call core.table.lookup on slack_work_objects with column message_ts and the thread's ts.
   • Failing that, take the case id from a cases/<uuid> link in the root message.
   • With a case id, call core.cases.get_case for its description, fields and tags.

4. Answer as case-output's "Thread replies" describes:

   • one reply in the thread;
   • one Slack: case comment;
   • at most one direct message, under the rules there.

   For an investigative question, fetch the case's findings with boto3 as guardduty-case-lifecycle stage 1 describes. Test the question in the SIEM with the method in hypothesis-driven-triage.

5. Outside a case thread (no case found): answer helpfully in the thread with the same evidence rules. Add no case comment and change nothing on any case.

6. Mark done. Nothing to do. When your run finishes, the workflow's mark_done adds white_check_mark and clear_eyes then removes eyes, so the reader is left with a single green tick. Add and remove no reaction yourself. When your run fails, the eyes stay.

A mention never changes a case's status, severity, disposition or tags, whatever it asks. A request to contain, disable, revoke, block, close or change the status gets the reply case-output prescribes, and nothing else.

Owner buttons

This path is timed: the person who pressed is watching the ask. Everything the first visible write needs is already in payload, so load no other skill, read no bundled file, and make no call before the first write turn. Do not call get_case, list_replies or a shell or Python tool first. The workflow's ack_owner_click has already replaced the buttons with :hourglass_flowing_sand: <@USER> answered Yes. Socky is recording it. (or No); your first write swaps that for the final status line.

Read everything from payload

Duplicate. The workflow's claim_event is the primary guard: it lets only the first answer per case reach you. As a secondary guard, when message.blocks already holds a context block starting :white_check_mark: or :x:, the answer is recorded. Change nothing, post nothing, and return Duplicate click on <short id>: already recorded.

Slack formatting. Every edit and post here passes text (and blocks where given) in Slack mrkdwn, single asterisks for bold. Never pass markdown_text: Slack rejects a call carrying both (markdown_text_conflict), and markdown_text alone renders *Verdict:* in italics.

Turn 1: all of these in parallel, in one turn

Exact text

The press time is always wrapped in backticks (Slack inline code) in the status line and the Verdict line. Copy these lines character for character, replacing only the angle-bracket placeholders. With block_id gd_confirm:CASE-0001:U0123456789:jane.doe@example.com:Jane Doe and 30 Sep 2026, 01:00 UTC as the press time, the Yes status line and Verdict line are exactly:

:white_check_mark: *Confirmed by* Jane Doe (jane.doe@example.com) at `30 Sep 2026, 01:00 UTC`. The case was set to Benign and a comment was added to CASE-0001.
*Verdict:* Benign. Jane Doe (jane.doe@example.com) confirmed this activity at `30 Sep 2026, 01:00 UTC`.

Slack mentions appear only in the thank-you (and in the brief's step 1, which you leave unchanged).

The templates:

Yes status line:   :white_check_mark: *Confirmed by* <person><not tagged> at `<press time>`. The case was set to Benign and a comment was added to <short id>.
No status line:    :x: *Denied by* <person><not tagged> at `<press time>`. The case was set to Escalate and a comment was added to <short id>.
Yes Verdict line:  *Verdict:* Benign. <person> confirmed this activity at `<press time>`.
No Verdict line:   *Verdict:* Escalate. <person> denied this activity at `<press time>`; treated as a possible credential compromise.

(The labels before the colon and the spaces after them are not part of the text.)

<not tagged> is (not the person tagged above), <on behalf> is on behalf of the person tagged above, and <on behalf of the tagged person> is on behalf of the tagged person, each only when on behalf applies, else nothing.

Turn 2: brief, card and row, in parallel

• Brief. In the list_replies result, the brief is the bot's reply whose text starts *Verdict:*. Replace its first paragraph and keep every paragraph after it unchanged, then save it with tools.slack.update_message, passing the whole brief as text with the blank lines between paragraphs:
  • Yes: the Yes Verdict line from "Exact text".
  • No: the No Verdict line from "Exact text".
• Card. Take the row's entity. Set the verdict custom field to Benign · owner confirmed or Escalate · owner denied, and entity_payload.attributes.metadata_last_modified to the press epoch, an integer (int(action_ts), never the decimal action_ts; it must be greater than the stored value). The row gets the same entity. Call tools.slack_sdk.call_method with sdk_method chat_update and params channel = the row's channel, ts = the row's message_ts, text " " (one space: chat_update rejects a missing or empty text with no_text, and any other text shows above the card), and metadata {"entities": [<entity plus "app_unfurl_url": <entity url>>]}.
• Row. core.table.insert_row with upsert true, table slack_work_objects, and row_data with exactly these five columns: external_ref_id (case id), case_id, channel, message_ts, entity (the updated entity, without app_unfurl_url). Never send updated_at: it fails with "Column 'updated_at' does not exist".

When the thread has no brief or the table has no row, skip that write and say so in the return line. Only then, and only when a later write needs something the payload lacks, call core.cases.get_case on the case id.

Return <short id> confirmed by <name>: Benign, low. or <short id> denied by <name>: Escalate, critical.