cleaner-bee

After this page you'll know what cleaner-bee looks for, how its review window works, how to put it on a schedule, and how to read its verdicts and findings. It was the first recipe proven end-to-end from the dashboard's Run a bee form.

What it does

cleaner-bee is the codebase-cleanup recipe. It acts as a senior engineer doing a focused code review on a window of recent commits on the default branch: it builds a worklist of security and bug findings from the diffs, patches the high-confidence ones, and opens a PR. No human writes code. A human always reviews.

It runs in three phases with hard action budgets:

The security checklist covers hardcoded secrets, SQL injection, XSS, insecure transport, weak crypto, SSRF, path traversal, command injection, insecure deserialisation, credential/PII logging, and auth changes that widen scope. The bug checklist covers null dereferences, off-by-one errors, race conditions, unhandled promise rejections, resource leaks, missing error handling on external calls, coercion bugs, dead code, and dependency bumps that pulled in known-vulnerable versions.

Findings that need design judgement are never guessed at; they go in a "needs human review" table in the PR body instead. The recipe is deliberately minimally invasive: it only touches code changed by the commits in the window, never refactors for style, and never modifies CI/CD configs, deployment files, or environment variables.

The review window

Each run reviews a bounded window of commits, carried in the run's ticket in one of two modes:

• Commits: the last N commits (default 10), or the range since the SHA the previous run stopped at.
• Hours: everything committed in the last N hours, via git log --since=....

Two mechanisms stop the bee chasing its own tail. Merge commits from the bee's own previously merged PRs are excluded from the window (the dashboard passes their SHAs in the ticket). And if the repo HEAD hasn't moved since the last successful run for that repo, the run is skipped entirely; the dashboard offers a Run anyway override, and the API accepts force: true.

Running it on a schedule

cleaner-bee is the schedulable recipe: set it up from the dashboard under a project's schedules, pick the lookback mode, and it reviews new work on a cadence with no trigger message at all. The schedule config is commits to review per run (1–50) or hours of history (1–720, default 24).

Running it manually

From the dashboard's Run a bee form, pick the cleaner-bee card and give it a repository plus a commits-to-review count (1–50). From Slack, name it (defaults apply: the last 10 commits):

@cube-agent cleaner-bee repo:3sidedcube/some-api Review recent commits.

From the CLI:

node cli/bin/swarm.js run --recipe cleaner-bee --repo org/repo --commits-back 10

Verdicts and findings

Every run ends with a verdict:

• CLEAN: zero findings in the window. No PR opened; a clean run is a valid outcome, and the recipe is told not to invent findings.
• FIXES_PROPOSED: at least one finding patched. PR opened with the fixes, grouped into one commit per category (security, bug), on a branch named agent/cleaner-bee-<date>-<shortsha>.
• NEEDS_REVIEW: findings flagged but none fixable. No PR is opened (there are no code changes to commit, and GitHub rejects commit-less PRs); the flagged findings surface in the Slack rollup line and the run's Findings tab instead.

The run also emits a structured findings list (category, rule, file:line, fixed vs. flagged) that powers the Findings tab on the run's dashboard page. The PR body includes the exact window reviewed (oldest and newest SHAs), the findings fixed and flagged, tests added, and, if a committed secret was found, an "Action required" section telling you to rotate it. Reviewing the PR works like any other bee PR (reviewing a bee PR).