zbobr is a GitHub-backed AI task orchestrator.
It reads tasks from GitHub issues, runs configurable multi-stage pipelines with AI agents, and publishes work results as pull requests.
- Custom pipeline configuration: define your own roles, stages, transitions, pauses, retries, and cross-pipeline calls in
zbobr.toml. - Multiple AI tools: run roles with different tools (
copilot,claude, more executors can be added). - Strong defaults from
init:zbobr initcreates a working starter config, prompts, and directories. - GitHub as source of truth:
- task context and control live in issues (title/body/comments/labels/state),
- implementation result lives in pull requests and branches.
One zbobr instance controls one target repository and one task repository.
- Task repository: issues are tasks and orchestration state.
- Target repository: where code changes are implemented and PRs are opened.
The orchestrator advances tasks stage-by-stage and stores progress in GitHub so humans and agents share the same control plane.
cargo install --path zbobrzbobr init my-workspace
cd my-workspaceinit creates:
zbobr.tomlwith default dispatcher/task/repo/workflow sectionsprompts/with role prompt templatesrepos/andworkspaces/directories for runtime data
Edit zbobr.toml:
[tasks].github_repoand[tasks].github_token[repo].repository,[repo].branch,[repo].github_token
zbobr setupzbobr task list --select
zbobr task process --select
# or move all eligible tasks one step:
zbobr task advancezbobr workflow is fully declarative in zbobr.toml.
You define:
workflow.roles.*: role prompt + allowed MCP toolsworkflow.pipelines.*.stages.*: stage behavior- transitions:
on_success,on_failure,on_intermediate,on_no_report - execution controls:
pause,call(jump into another pipeline)
Example (shortened):
[workflow.roles.worker]
prompt = "prompts/worker.md"
mcp = ["stop_with_error", "report_success", "report_failure", "get_ctx_rec"]
[workflow.pipelines.work]
stages.working = { role = "worker", prompts = ["prompts/task.md"], on_intermediate = "reviewing" }
stages.reviewing = { role = "reviewer", prompts = ["prompts/task.md"], on_failure = "working" }This lets you tailor the process to your team without changing Rust code.
zbobr supports multiple executors. Today that includes at least:
- Copilot executor
- Claude executor
Default tool/model are configured in [dispatcher], and executor-specific defaults are configured in [executor.*].
This enables patterns such as:
- planning with one model/tool,
- implementation with another,
- review/testing with a different setup.
Agents consume task context from the issue thread and configured prompts.
Humans control progression by updating issue state/signals and comments.
Useful commands:
zbobr task show 42
zbobr task update 42 --state "pending:main"
zbobr task update 42 --signal "go_working"Workers implement changes in the target repository branch and produce a PR tied to the task.
Operational evidence stays in GitHub:
- issue discussion and reports,
- commits and branch,
- pull request conversation and checks.
# Create and inspect tasks
zbobr task create "Add feature X" --description "..."
zbobr task list
zbobr task show 42
# Process tasks
zbobr task process 42
zbobr task process --select
zbobr task advance
# Maintenance
zbobr cleanup --dry-run
zbobr cleanupRuntime config is loaded from zbobr.toml (or override files via config flags).
Top-level sections:
dispatcher: global runtime behavior (instance/tool/model/workspace settings)tasks: GitHub task backend configurationrepo: GitHub repository backend configurationexecutor: per-tool executor defaultsworkflow: roles and pipelines
- Rust/Cargo (to build and install
zbobr) - GitHub access tokens for task and repo backends
- Installed AI CLIs/tools used by your configured executors (for example Copilot CLI and/or Claude Code)
- Token scopes and permissions:
docs/github-token-permissions.md - Pipeline transitions reference:
docs/transitions.md