slack-agent-flow

Slack agent flow (create_agent → provisioned Slack bot)

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 from-branch:channels stays on the

channels branch, exactly like /add-slack's own.

Prerequisites

All prose below assumes these are already in place, in this order:

1. 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).

1. slack-a2a-rooms — the bot-sender room policy

(src/channels/slack-a2a.ts present), so shared rooms admit the sibling

bots' posts.

1. 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.

1. 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:

grep -q "export async function startChannelAdapter" src/channels/channel-registry.ts && grep -q "export function registerDeliveryBatchPreview" src/delivery.ts && grep -q "session: Session) => Promise<void>" src/delivery.ts && grep -q "trigger?: boolean" src/session-manager.ts && grep -q "findCliResponse" container/agent-runner/src/db/messages-in.ts && grep -q "Promise<number>" container/agent-runner/src/db/messages-out.ts && grep -q "suppressCreatedNotify" src/modules/agent-to-agent/create-agent.ts && grep -q "dedupeKey?: string" src/modules/permissions/sender-approval.ts && grep -q "declineText?: string" src/modules/permissions/sender-approval.ts && grep -q "fyiText?: string" src/modules/permissions/sender-approval.ts && grep -q "export function extendTool" container/agent-runner/src/mcp-tools/server.ts && grep -q "export function registerChannelPreStep" setup/channels/companions.ts && grep -q "instructions.md" src/project-doc-compose.ts && grep -q "await action.decide" src/guard/guard.ts

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):

src/env-file.ts
src/env-file.test.ts
src/modules/slack-room-membership/index.ts
src/modules/slack-room-membership/membership.ts
src/modules/slack-room-membership/membership.test.ts
src/modules/slack-room-membership/env-file.ts
src/modules/slack-room-membership/env-file.test.ts
src/modules/canvas-actions/index.ts
src/modules/canvas-actions/handlers.ts
src/modules/canvas-actions/canvas-api.ts
src/modules/canvas-actions/canvas-actions.test.ts
src/modules/slack-onboarding/index.ts
src/modules/slack-onboarding/onboarding.test.ts
src/modules/slack-onboarding/thread-title.test.ts
container/agent-runner/src/mcp-tools/canvas.ts
container/agent-runner/src/mcp-tools/canvas.instructions.md
container/agent-runner/src/mcp-tools/canvas.test.ts
container/skills/slack-construct/SKILL.md
container/skills/slack-construct/instructions.md
container/skills/canvas-work/SKILL.md
container/skills/welcome/addenda/slack.md

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):

import './slack-room-membership/index.js';
import './canvas-actions/index.js';
import './slack-onboarding/index.js';

import './canvas.js';

4. Copy the flow payload

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:

src/modules/slack-agent-flow/types.ts
src/modules/slack-agent-flow/env-file.ts
src/modules/slack-agent-flow/provision.ts
src/modules/slack-agent-flow/slack-deps.ts
src/modules/slack-agent-flow/orchestrate.ts
src/modules/slack-agent-flow/guard.ts
src/modules/slack-agent-flow/room-actions.ts
src/modules/slack-agent-flow/room-canvas.ts
src/modules/slack-agent-flow/index.ts
src/modules/slack-agent-flow/env-file.test.ts
src/modules/slack-agent-flow/provision.congruence.test.ts
src/modules/slack-agent-flow/provision.prefetch.test.ts
src/modules/slack-agent-flow/orchestrate.test.ts
src/modules/slack-agent-flow/room-actions.test.ts
src/modules/slack-agent-flow/room-canvas.test.ts
scripts/slack-agent-flow-finish.ts
container/agent-runner/src/mcp-tools/rooms.ts
container/agent-runner/src/mcp-tools/rooms.test.ts
container/agent-runner/src/mcp-tools/rooms.instructions.md
container/agent-runner/src/mcp-tools/create-agent-slack.instructions.md
container/skills/slack-construct-agents/SKILL.md
container/skills/slack-construct-agents/instructions.md
container/skills/welcome/addenda/teams-tour.md

5. Register the host module

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):

  pnpm exec tsx scripts/slack-agent-flow-finish.ts --group <newAgentGroupId> --name <slug> --source-group <sourceGroupId> [--origin-instance <key>] [--room none] [--allow-guests] [--restart]

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.