Boro CLI
Boro reviews Linux kernel patch series in several AI stages, builds commits, runs tests and backports patches with conflicts
- 70 ★ on the repository
- Last commit
- Apache-2.0
Extended access
Why this level
- The tool sends the diff and code context to the chosen model, and `build` and `test` run kernel builds and boots on your machine
- `boro apply` changes the git tree: it cherry-picks and rewrites conflicted files
Install
Manual install
cargo install --force --path .Run it in a repository clone. Then set BORO_URL, BORO_KEY, BORO_MODEL and BORO_VALIDATION_MODEL for validation.
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The tool sends the diff and code context to the chosen model, and `build` and `test` run kernel builds and boots on your machine
- `boro apply` changes the git tree: it cherry-picks and rewrites conflicted files
This is third-party code. Review the repository files before installing.
What it does
Boro is a Rust CLI for AI-assisted Linux kernel development inside your own git tree. It serves the stages before a patch series is posted and cases where the normal mailing-list path does not apply: backports, distro kernel maintenance, security-fix integration and local patch-stack iteration. The project is inspired by Sashiko, shares its review prompts and targets a different moment in a patch life. `boro review COMMIT_RANGE` runs a multi-stage review with kernel subsystem prompts, patterns and checklists and an LKML-style summary. `boro build` builds each commit in its own worktree with `vng -b` and asks the model to triage the build log. `boro test` also boots the kernel in `virtme-ng` and runs a quick test the model picks. `boro test --config CONFIG_FOO` builds `HEAD` with an option set, and `--plan` only describes a test plan. `boro apply` carries commits through `git cherry-pick -x -s` and on `diff3` conflicts has `BORO_MODEL` propose a resolution while `BORO_VALIDATION_MODEL` gates it, up to 10 rounds per hunk. With `--message-id` the series comes from lore through `b4`. A cheap model does the broad search, a strong model validates and writes the report, and tokens are counted per stage. Any OpenAI-compatible `chat/completions` endpoint works.
Who it is for. Linux kernel developers and maintainers who prepare patch series, run backports and distro kernels and want an automatic first-pass review on their own machine.
Good fit when
- A ten-patch series has not gone to the list yet and you need a review with kernel subsystem prompts
- A series from lore has to be applied through `boro apply --message-id` and reviewed straight away with `boro review`
- A commit backport hits `diff3` conflicts and a model should resolve them with a second model validating
- Each commit in a range should build and pass a quick test in `virtme-ng`
- Broad search runs on a local model while validation and the report use a strong remote one
Not a fit when
- You need a tool for a project outside the Linux kernel: prompts and checklists are written for the kernel
- The series is already on the list and you need review there: Sashiko exists for that
- Build and tests cannot run without `virtme-ng` and you do not want to install it
- You need a guarantee of no bugs: AI review gives findings and does not replace human review
Example request
Review the series origin/master..HEAD in the kernel with boro review and show a summary of findings by subsystemLimitations
- `boro apply --message-id` needs `b4` on PATH, `build` and `test` need `virtme-ng` (`vng`), and the optional `lei` from `public-inbox` enables the upstream follow-up stage.
- An OpenAI-compatible `chat/completions` endpoint and three variables are required: `BORO_URL`, `BORO_KEY` and `BORO_MODEL`, plus `BORO_VALIDATION_MODEL` for validation.
- Install is from source: `cargo install --force --path .` in a repository clone.
- Review prompts are shared with Sashiko, and the accuracy of findings depends on the chosen models.
How to disable. Remove the binary with `cargo uninstall boro`. Unset `BORO_URL`, `BORO_KEY` and `BORO_MODEL` in the shell; Boro cleans temporary worktrees after `build` and `test` itself.
FAQ
How do I install Boro?
Run `cargo install --force --path .` in a repository clone and set `BORO_URL`, `BORO_KEY`, `BORO_MODEL`. The README lists no registry package.
How is Boro different from Sashiko?
They share review prompts, but Sashiko targets series after they appear on public mailing lists, while Boro targets interactive local review and repair while the series is still being shaped or carried downstream.
How do I apply a series from lore?
Run `boro --source /path/to/linux apply --message-id ID`: Boro fetches the series through `b4`, applies commits one by one and prints the range for `boro review`.
Does Boro boot the kernel?
Yes, `boro test` builds the commit and boots the kernel in `virtme-ng`, where it runs a quick test the model picks. `--plan` builds and boots nothing.
Which models are needed?
Any OpenAI-compatible `chat/completions` endpoint. A cheap local model can do the broad search and a stronger remote one the validation and report.
Discussion
No questions or reviews yet.
Related
CLI toolsCode Buster finds dependency cycles, dead and duplicate code and complexity growth across a repository, locally and without an LLM
A CLI for maintainers: pull request review, failing CI diagnosis and fork sync analysis built on repository evidence.
Builds a call and dependency graph from code and tells an agent who calls a function and what breaks after an edit
jnsahaj skills
jnsahaj/skills
Eight skills for code review, draft pull requests and bug triage one cause at a time, waiting for your go-ahead.
A code-review CLI and plugin for agents: reads a git diff and writes line-level comments with context
CLI with a virtual board of AI experts that reviews a PR or local diff and returns a score, severity level and evidence.
README in short
The README states the purpose: review and repair of kernel patches before posting and in distro branches. A three-command quickstart, the pipeline design, model roles, the review, build, test and apply subcommands and requirements for `b4`, `virtme-ng` and `lei` follow.