From Slack

After this page you can start a bee from Slack, read the status card it posts back, and steer the run by replying in-thread. The contract holds here as everywhere: No human writes code. A human always reviews.

Anatomy of a mention

@cube-agent repo:3sidedcube/some-api The /api/health endpoint returns 500 on cold start.

Three parts:

1. The mention: @cube-agent. This is what wakes the trigger in a channel; anything not addressed to the bot is ignored. (In a DM you skip the mention entirely; see Direct messages below.)
2. repo:org/name: an inline token, expanded to the GitHub repo. Always include it. A shorthand works too: repo:firstaid-ios is matched against the live project catalog and resolved to the full repo. When you name a bee, the run is rejected unless a repo resolves from the inline token or from a linked ticket's repo field. If you leave it off an unnamed mention, the swarm agent will try to resolve the repo from the channel's registered project, and shorthand repo names or plain-English hints in the ask (like "the firstaid iOS app") are now matched against the actual project catalog before it gives up. If it still can't tell which project you mean, it parks the request and asks "Which project is this for?" in-thread; mention the bot again in the thread with the repo: token or the project name to resume.
3. The task: everything else, in plain English. A Jira-style ticket key anywhere in the message (e.g. ABC-123, uppercase) is picked up automatically and linked to the run.

Naming a bee, or not

If you don't name a bee, the request goes to the swarm agent, the default general agent (ADR 0055). Name one of the four recipe bees anywhere in the message to take its shortcut instead:

A misspelled bee name doesn't fail; it falls through to the swarm agent, which handles the request anyway.

The status card

The bot posts one status card in a thread under your mention and edits it in place for the whole run, so there is no message spam. Edits are silent; you only get pinged when the run actually needs you or finishes.

Your original mention also gets a reaction as a channel-level glance: 👀 accepted, ✅ done, ❌ failed.

Replying in-thread

To answer a question, steer, or follow up, @mention the bot again in the same thread. Your reply continues the same run (same pipeline, same status card) rather than starting a new one. This works even after the conversation has closed: a reply in the thread reopens it.

Two rules:

• Only the original requester's replies continue the run. Someone else mentioning the bot in your thread starts a fresh run.
• A plain sign-off ("thanks", "done", "ok", 👍) closes the conversation without launching anything. If you go quiet, an open conversation closes itself after 15 minutes of idle; mention the bot in-thread to pick it back up.

Examples

@cube-agent repo:3sidedcube/some-api The /api/health endpoint returns 500 on cold start.

@cube-agent a11y-bee repo:3sidedcube/3sc-website Audit the homepage for accessibility issues.

@cube-agent support-bee repo:3sidedcube/some-api ABC-123 Password reset emails never arrive for new accounts.

@cube-agent Also add a regression test for the cold-start path.   ← in-thread, continues the same run

For what happens after dispatch (planning, clarifying questions, and the PR) see how Swarm thinks.

Direct messages

You can DM the bot directly, no @mention needed. Everything above still applies (the status card, the bees, the sign-offs); what changes is how the conversation is kept together. A DM is one rolling conversation:

• A message carrying a fresh signal, a repo: token, a bee name, or a new ticket key, starts a new run.
• A plain top-level follow-up continues your newest run: same pipeline, same status card.
• A reply typed inside a specific run's thread continues that run, even when a newer one is open.
• A sign-off ("thanks", "done", "ok") closes the open conversation. If there's nothing to close, you just get a ✅ reaction. Either way, nothing is launched.
• A message after a close reopens the same conversation where you left off.

Because the whole DM is one conversation, give a genuinely new request one of those fresh signals (a repo: token, a bee name, or a ticket key). Without one, it reads as a follow-up to whatever's open.

Pinning a default project

Tired of typing repo: in every DM? Pin one:

• pin <project> (as the whole message) sets that project as the DM's default. Every new request in the DM resolves against it.
• unpin clears it.
• An explicit repo: token in a message beats the pin for that message, shorthand included.
• pin with a name the bot doesn't recognise replies with the list of projects it knows, so a miss doubles as discovery.
• A pin is a convenience, not a permission: your project membership is still checked on every run it starts.

Several tickets at once

Name more than one ticket key in a single message, in a channel mention or a DM, and each ticket gets its own independent run: its own status card, its own budget, its own outcome. One failing doesn't sink the others. After dispatch you get one summary reply, e.g. "Dispatched 2 of 3 runs: SC-101 ✅, SC-102 ✅ · SC-103 ❌ (reason)".

Two things to know:

• The fan-out is capped at 5 tickets per message. Past the cap nothing dispatches; the bot asks you to split the request into smaller batches.
• A later plain follow-up in the same place continues only the newest of the runs. To steer a specific one, open its status card's View run link and continue it from there.

See it in action

How channels map to projects via Hive connectors, and when you need a repo signal in the ask.

DM routing: a repo token starts a fresh run, a plain follow-up continues the newest one, a second repo token runs in parallel.

Pin a project in your DM and every ask defaults to it; unpin to clear; pinning an unknown name lists your projects.

Multiple tickets in one message fan out into independent runs.

Replying inside a run's thread continues that run.