support-bee

After this page you'll know when to hand a bug report to support-bee, how to trigger it from Slack, Jira, the dashboard, or the CLI, and how to read the outcome it reports.

What it does

support-bee is the bug-fix recipe. Give it a ticket describing a defect and a repo, and it clones the repo, hunts down the root cause, implements a minimal fix, writes or updates unit tests, and opens a pull request. No human writes code. A human always reviews. The PR lands like any other and waits for you.

It works in three phases with hard action budgets, so a run can't wander off exploring the codebase:

The recipe is told that shipping beats perfection: a PR with a partial fix and clear reviewer notes is preferred over a complete fix that never gets pushed. If the root cause is still unclear after the investigation budget, it says so instead of guessing.

How to trigger it

Name support-bee anywhere in a Slack mention to skip classification and run this recipe directly (Slack):

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

From Jira, add a support-bee label before moving the ticket to the "AI" status (Jira). From the dashboard, use the Run a bee form (dashboard). From a checkout of the repo:

./scripts/run-agent.sh \
  --recipe support-bee \
  --repo "https://github.com/3sidedcube/some-api" \
  --ticket "POST /api/users returns 422 when email contains a + character. Expected: 201."

If you don't name a bee at all, the request routes to the swarm agent instead, which also handles bug fixes, just without this recipe's phase structure.

What a good ticket looks like

The investigation budget is small, so aim the bee. The best tickets name the endpoint, page, or module, describe expected vs. actual behaviour, and paste any error message or log line, like the example above. "The app is broken sometimes" burns the whole budget on searching.

The ticket text is treated as untrusted data, not instructions: the recipe reads it for the bug description but refuses embedded instructions to weaken security controls, skip tests, or touch CI.

Outcomes

Every run ends with a verdict, surfaced with the run on the dashboard:

• SUCCESS: fix PR opened.
• NO_ROOT_CAUSE_FOUND: investigation was inconclusive within budget; no PR. The reason summarises what was tried.
• NO_PR_OPENED: root cause found, but no code change applies (config issue, environment problem, user error, or the fix lives in another repo). The reason states the root cause, often the most useful outcome short of a fix.
• BLOCKED_PUSH_REJECTED: the fix was ready but GitHub refused the push.

Guardrails

The recipe follows Cube coding standards, the STRIDE security checklist, and the shared PR rules, all injected as context at the start of the run. It always works on a branch named agent/support-bee-<short-desc>, never commits to main, and never modifies CI/CD configs, deployment files, or environment variables. Before opening the PR it runs the linter and the test suite; if tests fail it attempts one fix, then documents the failure in the PR body rather than looping.