Let an existing Slack agent create new agents that arrive as their own Slack bots — provisioned app, operator DM, and a shared three-way room, hot-started without a host restart.
Install
Use withClaudeCursorCodex
The file stays in the publisher's repository. PlugMCP does not host or rewrite it.
Let an existing Slack agent create new agents that arrive as their own Slack bots — provisioned app, operator DM, and a shared three-way room, hot-started without a host restart.
name: slack-agent-flow
description: Let an existing Slack agent create new agents that arrive as their own Slack bots — provisioned app, operator DM, and a shared three-way room, hot-started without a host restart.
Composes the Slack extension skills into one conversational flow: a user tells
an existing Slack-wired agent "create an agent called Research", and the new
agent doesn't just exist as a send_message destination — it arrives in Slack
as its own bot. The host provisions a Slack app for it (managed broker, or
a workspace manager token), registers it as a slack-<name> instance,
hot-starts the adapter in the running host, opens a DM between the new bot and
the operator, opens a three-way MPIM (operator + originating bot + new bot)
registered as an agent-to-agent room, and wires everything so both agents hear
the room. The flow also adds two agent-facing room actions — create_room
(one shared room with N agents at once, the team primitive) and add_to_room
(grow a room by one agent) — and extends the base create_agent tool with the
flow's purpose / allow_guests / room parameters. Non-Slack sessions are
untouched: create_agent from any other channel behaves exactly as upstream.
Canonical home. This directory on main is the skill's canonical source —
the setup wizard and any direct apply read it from the checkout. The copy on
the channels branch is a compatibility mirror for older checkouts whose
setup fetches companions from there; edits land here, never there. The
payload the Apply steps fetch with stays on the
channels branch, exactly like 's own.
from-branch:channels
/add-slack
Prerequisites
All prose below assumes these are already in place, in this order:
add-slack — the Slack channel install (src/channels/slack.ts and
the shared channel-layer lib src/channels/slack-lib.ts present, with
slack.ts exporting its SLACK_DEFAULTS declaration and the
multi-instance factory slackInstanceBridgeFactory — the adapter owns
SLACK_INSTANCES registration natively, and the flow writes each new
agent's tokens under that env-key scheme).
slack-a2a-rooms — the bot-sender room policy
(src/channels/slack-a2a.ts present), so shared rooms admit the sibling
bots' posts.
A provisioning credential in .env — NANOCLAW_INSTALL_TOKEN (managed
broker) or SLACK_MANAGER_TOKEN (direct workspace-level app creation).
Without one, agent creation still works but the Slack leg reports
no-credentials and points at the finish script.
At least one Slack owner/admin in user_roles — the flow resolves "the
operator" from the approver chain (scoped admins → global admins → owners)
and needs a slack:U… identity there to open the DM and the room.
Apply
1. Check the Slack payloads are installed
The flow imports the skill-installed Slack channel modules; verify they are in
the tree before copying anything. If slack-lib.ts, the SLACK_DEFAULTS
export, or the slackInstanceBridgeFactory export is missing, the installed
Slack channel payload predates this flow — re-apply the two skills above (or
/update-skills) first:
test -f src/channels/slack.ts && test -f src/channels/slack-lib.ts && test -f src/channels/slack-a2a.ts && grep -q "export const SLACK_DEFAULTS" src/channels/slack.ts && grep -q "export function slackInstanceBridgeFactory" src/channels/slack.ts
2. Check the trunk extension seams
Everything this flow plugs into is standard trunk API — the adapter hot-start
entry, the delivery batch preview, the mailbox delivery/session helpers, the
create-agent notify option, the decline-and-notify overrides, the container
tool-extension hook, and the setup wizard's channel registries. This is a
trunk version requirement, not an edit: if the check below fails, the
NanoClaw trunk is too old for this skill — bring the install up to date
(/update-nanoclaw) instead of patching any of these files by hand:
The last term requires an async-capable guard seam: the flow's create_agent
and room-action guards read container config asynchronously, and on a trunk
whose guard() does not await decide a returned Promise would be treated
as an allow — the check turns that silent fail-open into a fail-fast here.
3. Copy the shared feature payload from the channels branch
The agents experience needs more than the base adapter: the room-membership
module (invite-to-room adoption, group-DM fork carry-over, detach on removal,
owner-presence access rule), canvas actions + the container canvas tool +
the canvas-work skill (section-scoped canvas edits/reads via the session's
own bot identity), DM onboarding (get-started prompts, per-thread DM titles),
and their env-file.ts dotenv plumbing. They live on the channels branch;
fetch and copy them into place (overwrite — the branch is canonical):
The welcome addendum rides with the agents feature deliberately: its tour
content describes rooms, canvases, suggested-prompt DMs, and the agents
access model — none of which exist on a base /add-slack install.
Register the three host modules in the modules barrel and the canvas tool in
the container tool barrel (each append is skipped if already present; these
must precede the flow module's own barrel line, which the fence order here
guarantees):
This skill ships its payload alongside this document; copy the files into the
tree at the same relative paths (overwrite; the skill's copies are canonical).
The host module carries the wrapped create_agent handler and the room
actions; the container files carry the room tools, the create_agent
extension, the sibling-agent standing-context skill, and the welcome-tour
addendum. The two mcp-tools/*.instructions.md fragments and the
slack-construct-agents skill's instructions.md are picked up by the
CLAUDE.md compose scan; the welcome addendum is consumed by the host's
channel-matched addenda mechanism (inert on hosts that predate it) — so
copying the files is the whole install:
Append the self-registration import to the module barrel (skipped if the line
is already present). It must evaluate after the agent-to-agent module's own
registration, which appending at the end guarantees — the flow's create_agent
handler re-registers over upstream's:
import './slack-agent-flow/index.js';
6. Register the container room tools
Append the tool-module import to the container MCP-tools barrel (skipped if
already present). The module registers create_room / add_to_room and
extends the base create_agent tool, so it must evaluate after the base
agents module — import order follows document order, and appending at the end
guarantees it:
import './rooms.js';
7. Build
The build guards every typed call the flow makes into trunk (delivery
registration, DB helpers, channel defaults, the shared Slack lib) against
drift:
pnpm run build
8. Validate
The flow's own tests, the shared feature payload's module tests, and the trunk
hot-start seam's test run on the host. The room-tool tests run through the
already-built agent image, so setup does not require Bun on the host; they also
pin the create_agent extension:
pnpm exec vitest run src/modules/slack-agent-flow src/modules/slack-room-membership src/modules/canvas-actions src/modules/slack-onboarding src/env-file.test.ts src/channels/adapter-hot-start.test.ts
source "$PWD/setup/lib/install-slug.sh" && "${CONTAINER_RUNTIME:-docker}" run --rm --entrypoint bun --workdir /app --volume "$PWD/container/agent-runner/src:/app/src:ro" "$(container_image_base):latest" test --preload /app/src/modules/index.ts src/mcp-tools/rooms.test.ts src/mcp-tools/canvas.test.ts
9. Restart the host
The flow module registers at boot, and container mounts are read-only at
runtime — restart so the running host picks everything up (new sessions see
the container-side files; no image rebuild):
bash setup/lib/restart.sh
How it behaves
Guard/approval flow is upstream's. The flow re-registers create_agent
with the same guard action and precheck as the agent-to-agent module; only
the hold question changes when the request originates from a Slack session
(it names the Slack provisioning side effects — new app, operator DM,
shared room). The room actions get the same trust split: global cli_scope
groups act directly, everything else holds for the admin chain, and
approved replays re-enter the wrapped handlers automatically.
Expected boot warning. Because the barrel imports the flow module after
the agent-to-agent module, every boot logs
Delivery action handler overwritten for create_agent. That warning is
the intended signal that the wrapper won the registry — its absence means
the barrel line is missing or ordered wrong.
What a successful run does. Provisions (or reuses) the app — agent-mode
by default; allow_guests: true selects the plain, guest-accessible
variant — writes SLACK_BOT_TOKEN_<NAME> / SLACK_APP_TOKEN_<NAME> and
unions the slug into SLACK_INSTANCES, hot-starts slack-<name>, opens
the operator DM and wires it to the new agent group (agent-mode DMs get
thread-per-conversation sessions straight from the channel declaration),
opens the three-way MPIM with the new bot's token, appends the room's
channel id to SLACK_A2A_ROOMS, creates one room messaging group per
instance (both mention-gated), creates the room's canvas-tab contract, then
posts the DM intro and nudges the originating agent to introduce the new
one in the room. The new bot typically answers within ~10 seconds; if it
stays silent for a minute, an operator can run bash setup/lib/restart.sh
as the fallback.
Workspaces that gate installs. Where an admin must approve every app
install, the workspace refuses the automatic one and the managed service
answers with an install link instead of a bot token. The flow does not fall
back to hand-building an app: it posts one line into the conversation the
create came from — as the ORIGINATING bot, since the origin agent's own
reply cannot be delivered while the handler is still running — naming the
link to approve, then polls the service (5s, up to 5 minutes) for the bot
token the completed install releases. On arrival the rest of the flow runs
exactly as if the install had been automatic. On timeout the app parks:
SLACK_APP_TOKEN_<NAME>, SLACK_APP_ID_<NAME> and
SLACK_INSTALL_URL_<NAME> stay in .env, and asking the same agent for the
same name again resumes THAT app — it never provisions a second one.
SLACK_INSTALL_WAIT_MS=0 skips the inline wait for installs that always go
through a slow approval queue; SLACK_INSTALL_POLL_MS moves the cadence.
Teams get one room.create_agent({ ..., room: 'none' }) skips the
shared room; the multi-agent pattern is N such creates followed by ONE
create_room naming all of them. When a batch of creates arrives together,
their avatar generations are prefetched in parallel, so N waits collapse to
roughly one.
A2A cache staleness. The a2a room allowlist is re-read from .env on a
≤30s cache. The room id is appended before any intro is posted, but the
originating agent's own bridge may still miss ingesting the intro inside
that window — harmless; the intro is for the human, and the originating
session is told the room id and wirings directly in its success message.
Failures are resumable. Any Slack-leg failure leaves the agent group
fully working via send_message, reports the exact step that failed, and
names the retry command. The finish script re-runs the whole leg
idempotently (tokens are reused from .env, rows are get-before-create,
intro posts fire only for newly created rows):
It runs outside the host process, so it cannot hot-start the adapter:
--restart runs bash setup/lib/restart.sh for you, otherwise it prints
the restart instruction.
Setup-wizard leg.bash nanoclaw.sh does the whole install by default:
the managed-provisioning pre-step and the companion list (slack-a2a-rooms,
then this skill) register unconditionally at wizard boot
(setup/channels/slack-auto-register.ts → setup/channels/companions.ts),
so the wizard provisions the first app, applies /add-slack, then applies
both feature skills with one deferred restart. A plain-bot install is the
manual choice inside the flow. That leg ships with trunk, and this skill
does not touch it.
Everything the flow creates at runtime is user data, not skill payload: agent
groups, messaging groups, and wirings stay in the central DB; token lines,
SLACK_INSTANCES entries, and SLACK_A2A_ROOMS entries stay in .env;
provisioned Slack apps stay in the workspace. Removal (see REMOVE.md) never
touches any of it — for per-agent teardown of a provisioned bot, follow the
slack-managed-agents skill's teardown section.
How do I install slack-agent-flow?
Download .claude/skills/slack-agent-flow/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does slack-agent-flow live?
The publisher keeps it at https://github.com/nanocoai/nanoclaw.
Which agents can use slack-agent-flow?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.