# Slack > Read bounded Slack search and thread evidence, plan an exact reply, and deliver an approved reply through any compatible Slack binding with stable-message readback. - Skill: `runxhq/slack` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds@latest add runxhq/slack` - Raw SKILL.md: https://api.skillmd.com/api/skills/runxhq/slack/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Integrations & APIs - Author: runxhq (https://skillmd.com/u/runxhq) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/runxhq/slack --- # Slack Use Slack as a governed provider boundary without turning Slack—or Runx Cloud—into the owner of the operator's workflow. This skill owns the reusable Slack mechanics that an agent should not have to reconstruct: bounded message search, bounded thread hydration, digest-bound reply planning, explicit approval, idempotent delivery, and exact-message readback. The operator-selected provider binding has one narrow role in this flow: retain credential custody and execute a fixed Slack operation. It may be local, self-hosted, third-party, or Runx-hosted. The skill, its procedure, approval point, retry identity, and completion rule remain in Runx OSS. Any queue, team-specific routing rule, or durable action state belongs in a higher-level operator skill and normally composes `operator-inbox`. ## Composes - `send-as#plan` ## Runners `search` reads one bounded Slack search page. Supply a `query` object with at least one of `author_external_id`, `mentions_connected_subject`, or `keywords`. The exact fields are: - `author_external_id`: one Slack member id string, such as `U123ABC` - `mentions_connected_subject`: a boolean selecting messages that mention the member bound to the selected provider account - `keywords`: one keyword-mode search phrase string, not an array and not raw Slack search syntax - `after` and `before`: ISO-8601 timestamp strings, with `after` earlier than `before` - `channel_types`: a non-empty array drawn from `public_channel`, `private_channel`, `mpim`, and `im` - `limit`: an integer from 1 through 20 - `cursor`: the opaque `next_cursor` from the preceding page The provider rejects embedded Slack modifiers in `keywords`, enforces the maximum page, and returns normalized locators and bounded previews rather than a raw Slack response. Continue only from `next_cursor`; one page is never proof that a workspace scan is complete. `read_thread` reads one bounded thread page from an exact `slack://workspace/channel/timestamp` locator. The limit is capped at 15 because Slack applies a low limit and, for some non-Marketplace installations, a very low request cadence to `conversations.replies`. Hydrate only threads that are actually needed, preserve `next_cursor`, and do not fan out speculative reads. Thread messages include bounded attachment metadata and opaque `slack-file://workspace/file` locators; private Slack download URLs never cross the provider boundary. `read_link` accepts one exact Slack archive permalink and reads the same bounded thread page. Use it when an operator pastes a normal `https://workspace.slack.com/archives/channel/message` link and therefore does not have the workspace id required by a canonical locator. The provider binding validates the permalink, binds it to the authenticated workspace identity, and returns the canonical `slack://workspace/channel/timestamp` locator. A reply permalink's `thread_ts` identifies the root; Slack's redundant `cid` must match the path channel. This runner requires only `thread.read`, never a search grant. `read_file` reads one image attachment from an exact file locator returned by `read_thread`. It requires `file.read`, verifies the file through Slack, restricts downloads to Slack's private file origin, accepts images only, and caps decoded bytes at 5 MiB. The result contains the MIME type, content digest, and base64 bytes so the caller can inspect the image without receiving the Slack credential or private URL. `plan_reply` is safe and does not call Slack. It computes the text digest with Runx's native `data.digest` tool and passes the principal, exact thread audience, and digest-bound content to canonical `send-as`. The emitted `send_plan` is an authorization plan, not evidence of delivery. `deliver_reply` accepts that exact `send_plan`, thread locator, text, and a stable UUID idempotency key. It recomputes the digest and rejects any change to the plan decision, Slack provider, chat channel, thread audience, content digest, or human-approval requirement. After approval it calls the native `provider.mutate` tool for `thread.reply`, then independently calls `provider.read` for `thread.reply.read`. Completion requires the same workspace, channel, thread locator, message locator, content digest, and occurrence time from Slack. Provider acceptance alone is not completion. Use `slack-notify` for a proactive top-level channel post. Use this skill for search, thread context, and replies. Use `operator-inbox` when observations must become durable local work items. A product-owned skill may add team-specific triage and compose these skills, but must not copy their provider transport, approval, idempotency, readback, or queue logic. ## Authority and privacy Reads resolve a compatible Slack binding for `messages.search`, `thread.read`, or `file.read` and do not ask for human approval. Reply delivery requires both `thread.reply` and `thread.reply.read`; the mutation stops at an explicit approval bound to the unchanged plan and content digest. Runx supplies the idempotency key once, and the selected transport verifies the registered operation and its read/mutate class against the bound provider authority. The skill never receives a Slack token, constructs HTTP, or stores a raw provider envelope. Search and thread outputs contain bounded previews because the operator needs context. Reply receipts contain only stable locators, timestamps, and a content digest; they do not echo the delivered message. ## Stop conditions - Refuse a missing, ambiguous, revoked, wrong-provider, or insufficient-scope Slack binding. Never fall back to a token, webhook, browser, or provider-specific script. - Stop when a search has no structural selector, uses an unsupported modifier, or asks for more than one bounded page per turn. - Stop when an attachment is not an image, exceeds 5 MiB, belongs to another workspace, or resolves outside Slack's governed private-file origin. - Stop on malformed permalinks, unsupported permalink query fields, cross-workspace locators, or thread/message channel mismatch. - Stop on reply-plan drift, absent or denied approval, invalid idempotency, or provider readback that does not match the exact delivered message. - Do not infer that a request is resolved from Slack prose. Record resolution, waiting, follow-up, or dismissal explicitly in the owning operator workflow. - Do not claim complete scan coverage while a cursor remains, or successful delivery from a local plan, a provider acknowledgement, or a fixture. ## Worked flow An operator can search for direct mentions or start from a pasted Slack permalink. They hydrate only the actionable thread, preserve its canonical locator, then pass that normalized observation to a team-specific triage skill and `operator-inbox`. If a reply is needed, `plan_reply` binds the proposed text to the exact canonical thread. A changed draft fails before approval. An approved unchanged reply is posted once, then read back from the exact returned message locator before Runx seals the effect.