busybees 发布 Go CLI，用多角色编码智能体在 GitHub 上跑软件工厂

busybees is a lightweight software factory: a Go CLI (bees) that runs a staff of headless coding-agent sessions — product manager, project manager, developers, reviewers, QA and, when you enable it, a release manager, against one or more GitHub repositories.

Humans steer it through GitHub. Create and label issues, comment, merge pull requests; the bees do the rest. Every role runs in its own temporary git worktree and talks to the other roles through a local mailbox. Each project has a bees.toml; optional user-level defaults share agent profiles and role mappings across projects.

Contributing to busybees itself? See CONTRIBUTING.md.

Install

macOS and Linux, on amd64 (x86-64) and arm64:

curl -fsSL https://raw.githubusercontent.com/kpenfound/busybees/main/install.sh | sh

The script downloads the latest release, checks it against the SHA-256 sums published with it, and installs the bees binary in /usr/local/bin — using sudo only if that directory is not writable. Re-running it upgrades an existing install in place. BEES_VERSION picks a release and BEES_INSTALL_DIR where it goes; both go on sh, not on curl:

curl -fsSL https://raw.githubusercontent.com/kpenfound/busybees/main/install.sh |
    BEES_VERSION=v0.2.0 BEES_INSTALL_DIR="$HOME/.local/bin" sh

Anywhere the script does not cover — Windows, another architecture, or a build of unreleased main — build from source with Go 1.25+ instead:

git clone https://github.com/kpenfound/busybees.git
cd busybees
go install ./cmd/bees

Releasing describes what a release contains and how to install one by hand.

Quick start

You need gh (authenticated), git, and Claude Code (claude), logged in. Inside a clone of the repository you want built:

bees init --template issue-driven   # writes bees.toml, creates .bees/ and the GitHub labels
bees run                            # draws a live view; --no-tui logs instead

Then open an issue describing a feature, label it bees, and watch: the product manager breaks it into work items, the project manager refines them, a developer builds each one and opens a pull request, the reviewer approves it, and QA tests the default branch after every merge. Two things wait for you: a feature a bee proposes carries bees:proposal until you remove the label, and every approved pull request is yours to merge. Config templates describes the other ways to run the factory.

Key features

GitHub is the workflow. Issues and pull requests move through labels (bees:triage → bees:ready → bees:in-progress → bees:review → bees:approved), and only items matching your configured filter are visible, so bees coexists with ordinary work in the same repository. See Workflow.
A role per session. The product manager, project manager, developers, reviewers and QA each run as a fresh headless session in its own worktree, with a role-specific prompt and its own model. A role runs as Claude Code — with skills and a fallback profile for when the primary hits its usage limit — or as Codex, opencode or pi (with pi-mcp-adapter). See Roles.
Features become GitHub sub-issues. The product manager turns a feedback or feature issue into work items tracked as native sub-issues, and can discuss a feature with you under bees:planning before breaking it down. See Filing work.
A developer → reviewer loop. A developer implements a work item and opens a pull request; a reviewer reviews it, and the two iterate until it is approved. See developer and reviewer.
Releases from finished milestones. With the release manager enabled, a milestone whose issues are all closed ships as a tag named after it, a GitHub release with generated notes, and the milestone closed. See Releases.
A review on request. Put bees:review-requested on any pull request the factory can see, yours included, and the reviewer submits one GitHub review on it. See Asking for a review of any pull request.
A review of any pull request, without a factory. bees review <pr> reviews a pull request from six angles in read-only sessions, lets you select, dismiss, defer or ask about each finding, and posts what you selected as one GitHub review. See Reviewing a pull request.
Evals of the factory, and of one role. bees eval runs the factory against fixture repositories with an in-memory GitHub, merges what it approves, and grades the result with each fixture's own test. bees eval <role> runs one role on its own and grades its session. See Evals.
A GitHub App of its own. With [github] naming a GitHub App, the factory writes as the App's bot, and sessions get installation tokens scoped to the repository, never the App's key. See [github].
A local mailbox, not GitHub comments. Roles ask each other questions and exchange review feedback through a mailbox in the state directory; every comment a bee posts on GitHub is to a person, and ends with an invisible marker. See The mailbox.
Several projects per process. A machine config lists each project's bees.toml. bees run -d runs in the background; SIGHUP reloads the list and every project's bees.toml and user-level profile defaults. See Running in the background.
A config per project. bees.toml holds project settings, the visibility filter, scheduler limits, agent profiles, and global and per-role prompt/skills/MCP settings; ~/.config/bees/defaults.toml can supply shared profiles and selectors. See Configuration and bees.example.toml.
A CLI for status, cost and control. bees status, bees cost, bees tick, bees exec, bees notes, and bees kill. See CLI reference.
It stops itself rather than overspend. scheduler.max_cost_per_day pauses new sessions once the rolling 24-hour spend reaches it; two companion budgets cap a single issue and a single session, and all three are unlimited by default. The claude session limit pauses the whole factory the same way when the account runs out of capacity, and bees status reports the daily spend against the budget and says when either pause is in force. See Cost budgets and The claude session limit.

Documentation

These pages are also published at https://kpenfound.github.io/busybees/.

Document	What it covers
docs/workflow.md	The GitHub-centred workflow: filter, label state machine, questions, review loop, escalation, QA
docs/roles.md	Each role's responsibilities, inputs, outcomes, and how to customise or disable it
docs/configuration.md	Complete `bees.toml` reference
docs/security.md	What each sandbox mode protects and what it does not: filesystem, network, credentials
docs/templates.md	The named ways to run the factory: which roles run, what merges on its own, what waits for a person
docs/cli.md	Every `bees` command
docs/evals.md	`bees eval`: running the factory, or one role, against fixture cases, the case layout, grading
docs/review.md	`bees review`: how a review runs, its findings, reviewer notes, and its two configuration files
docs/architecture.md	How `bees run` works: the scheduler loop, the developer worker, sessions, the mailbox, the state directory, crash recovery
docs/releasing.md	Cutting a release: the tag, the workflow, the assets it publishes
CONTRIBUTING.md	Building, testing and the contributor workflow

Acknowledgements

Inspired by swarms, scaled down to one job: a software factory driven by GitHub.

License

MIT