Reviewing a bee PR

After reading this page you'll be able to recognise a bee's PR, review it with the right priorities, and send it back for another pass. The contract that makes this page matter: No human writes code. A human always reviews.

From the settled Slack card to the PR on GitHub, and the plan, changes, and logs behind it.

A finished run's workspace: the PR it opened, the plan, the diff, and the logs.

How to spot a bee PR

Three signals identify a bee's work:

• PR author: the PR is opened by cube-bees[bot], the GitHub App identity.
• Commit author: commits are authored as 3sc-agent-bee (agent@3sidedcube.com). Both agent images bake this git identity as the default, so bee commits show up as the bee in the history rather than under whatever identity the in-run tooling would otherwise pick.
• Branch name: recipe bees create branches prefixed agent/, e.g. agent/support-bee-fix-null-crash.

You'll usually find out because Swarm assigned the PR to you. At PR-open time it resolves the most recent human committer on the repo's default branch and sets them as assignee and requested reviewer, the person most likely to have context. If that's you, the review is yours unless you hand it off.

What to check first

Review in this order; it front-loads the checks that most often fail:

1. Does it solve the ask? Read the original request (the Jira ticket, Slack thread, or dashboard task) before reading the diff. The PR body is required to explain what changed and why, list risks for the reviewer, and flag anything unfinished under "Remaining Work"; hold it to that. A clean diff that answers the wrong question is still a rejection.
2. Tests. Did the bee add or update tests for the change, and does CI pass? Recipe bees run lint and the test suite before pushing, but treat the checks on the PR as the source of truth.
3. Scope creep. The diff should touch only what the ask needed. Bees are instructed to ship focused PRs ("a PR with 5 fixes and a clear report is better than 20 fixes that never land"). If the diff wanders into unrelated refactors, that's a request-changes on its own.

Then review it like any human PR: correctness, security, conventions. PR titles follow Conventional Commits (fix(api): handle null status in health endpoint). Some runs open as draft PRs (project-routed runs with a draft PR policy); you mark those ready when satisfied. Either way, bees have submission authority, never merge authority: the merge button is the human decision.

Requesting changes

Comment on the PR and mention the bee:

@cube-bees the fix works but the new test asserts on the error message
string. Assert on the error code instead, and drop the console.log in
src/api/client.js.

The GitHub trigger picks the comment up, starts a follow-up run against the same repo with your comment as the task, and the bee posts its reply (outcome or clarifying question) back as a comment on the PR. From then on, further comments from you on the same PR continue the same conversation. Even after it closes, your next comment reopens it. You don't need to re-mention.

Two things that do not trigger a follow-up: a GitHub "Request changes" review with no @cube-bees mention in a comment, and comments from anyone other than the original requester (a bystander's comment never matches your conversation; they need their own @cube-bees mention, which starts their own run).

Close or iterate?

Iterate when the direction is right and the gap is specific: wrong assertion, missed edge case, style drift. One or two follow-up comments usually lands it.

Close when the bee misunderstood the ask at the root, or the ask itself was wrong. Steering a fundamentally wrong PR costs more than re-triggering with a sharper brief; runs are cheap, review time isn't. Close it, then re-trigger from Slack or the dashboard with what you learned about how to phrase the task.

Your review is the swarm's training signal

What you merge, what you send back, and what you close tells Swarm which patterns work. That signal is only useful if it reaches Hive, the shared knowledge layer. See keeping Hive healthy for how review outcomes become patterns the whole swarm reuses.