菜单
Drive Slack from iii — expose the Slack Web API as slack::* functions (post messages, manage channels, reactions, files, users, views, search, assistant threads), configurable from the console. Anything the Slack API can do, this worker can do.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | slack |
| description | Drive Slack from iii — expose the Slack Web API as slack::* functions (post messages, manage channels, reactions, files, users, views, search, assistant threads), configurable from the console. Anything the Slack API can do, this worker can do. |
The slack worker exposes the Slack Web API as slack::* iii functions, callable
by an agent or from the console. It owns no opinion about what you do with Slack:
it is a faithful, typed surface over the API plus a generic slack::call escape
hatch for any method without a typed wrapper.
Reach for it to let an agent (or an operator) post messages, read history, react, upload files, look up users, open modals, publish App Home, or search — using a single configured bot token.
slack::chat::*).slack::conversations::*).slack::call { method, params }.app_mention/DM → harness::send, streamed replies,
approvals) activates only when signing_secret + public_base_url are set and
the harness stack is connected. Without them the worker is API-surface-only.auth.test, never
configured. Models/providers come from router::models::list — no vendor names
are baked in.slack::search::messages needs a user_token (xoxp-); bot tokens cannot
search.Set bot_token (required) — and user_token for search — in the console
Configuration → Workers → slack, or seed from env (${SLACK_BOT_TOKEN}).
Run slack::config-status to validate the token and see the resolved identity.
All fields hot-reload.
Each typed function names the common Slack parameters and passes any extra
parameters through; the full Slack response payload is returned. See the
README for the full list. Use slack::call for anything not yet
typed.
Run Unix commands and structured filesystem ops from the iii engine: exec, background jobs, and a structured fs (ls/stat/mkdir/rm/chmod/mv/grep/sed/ read/write, jailed only if fs.host_roots is configured), all forwardable into a sandbox microVM.
Shared, adapter-backed key/value store addressed by scope and key, with a reactive `state` trigger so other functions can run on every create, update, or delete without polling.
Durable topic queues for iii: subscribe functions to topics, publish work asynchronously, retry failed deliveries with backoff, and inspect/redrive dead-lettered messages.
Mint isolated git worktrees for parallel agent work, track ownership in a cross-agent registry, and land finished branches back onto a target with a queued rebase, test gate, and atomic fast-forward merge.
Connect this engine to another iii engine over a long-lived WebSocket so functions call across the boundary. Wire stable ids with `forward:`/`expose:`; `bridge.invoke` is the ad-hoc escape hatch.
Drive Devin over the iii bus. Run the local Devin CLI agent (SWE-1.6) with the iii runtime context so it discovers and operates your mesh, or start and steer autonomous Devin cloud sessions through the REST API, with a passthrough to any Devin v1/v3 endpoint.