Your first bee run
Trigger your first bee from Slack, follow the living status card, and review the pull request it delivers.
After this page you'll have run your first bee: one Slack mention against a real repo, ending in a pull request you review. Total hands-on time is about a minute; the bee does the rest.
A first run, end to end: mention the bot with a repo and an ask, watch the status card, see it land on the dashboard.
Step 1: mention the bot with a repo and an ask
In a Slack channel where the bot is installed, write one message: mention the bot, include repo:org/name, then say what you want done in plain English.
@cube-agent repo:3sidedcube/some-api The /api/health endpoint returns 500 on cold start. Find and fix the cause.The repo: token is the org/name pair, not a URL: repo:3sidedcube/some-api, never repo:https://github.com/.... Everything else in the message is your ask. Don't name a bee: with no bee named, the request routes to the swarm agent, the default general agent, which is what you want for your first run.
Step 2: watch the status card
The bot reacts to your mention with π and posts one status card in the thread. That card is the run's single source of truth: it's edited in place as the run progresses, so the thread doesn't fill with noise. New messages are reserved for moments that need you.
Stage by stage:
- β³ Reading your requestβ¦: posted immediately, before the run is dispatched. The card carries a View run button linking to the run's page on the dashboard from the start.
- π On it: the run was accepted and dispatched. The card stays on this state while the bee works; it next changes when the run needs you or finishes. (βοΈ Working appears only later, when the run picks a follow-up thread reply back up.)
- βΈοΈ Waiting: the bee needs a decision from you, or it finished a turn and is holding the thread open for follow-ups. When it's a question, you also get a new thread reply with the question and an @-mention. Answer in the thread and the same run resumes.
- β / β: the terminal state, either done with the outcome or failed with the reason.
Step 3: the PR arrives in the thread
When the run produces a pull request, two things happen: the card settles with a PR line and a View PR button, and a new thread reply lands with the named PR link. That reply is the ping that tells you it's done.
Step 4: review it
No human writes code. A human always reviews. The bee never merges its own work. Open the PR on GitHub, read the diff, and approve, request changes, or close it like any other PR. Reviewing a bee PR covers what to check first.
The thread stays live for follow-ups: reply in the same thread and mention the bot to continue the same run: "also add a regression test", "why did you change the config?". When you're finished, a plain sign-off ("thanks", "done", π) closes the conversation without launching anything.
For the full Slack surface (continuing closed threads, naming a specific bee, ticket keys), see Slack.
Troubleshooting
You forgot repo:. If the channel is bound to a project in Hive, the repo can resolve automatically from the project's default repo. If the project can't be determined, the bee asks in the thread ("I couldn't tell which project this is for") and parks the request; reply in the thread, mention the bot, and include repo:org/name, and it picks the original request back up. If the project is known but has no default repo bound in Hive, the run is rejected with "No repo resolved" instead; post a fresh mention with repo:org/name.
Unknown repo. If the GitHub App can't access the repo (wrong name, or the app isn't installed on it), the run is rejected before it starts, and the card settles to β "Couldn't start this run" with the reason. Check the spelling, or ask a GitHub org admin to install the Cube Bees App on that repo.
The bee fails. The card settles to β with the failure reason, your mention gets a β reaction, and a new reply @-mentions you with the reason and a link to the run on the dashboard. Read the run page to see where it stopped, then post a fresh mention to retry.