What the agent does
The agent reads the workspace before it reads the issue's suggested file, because a Rust fix in the wrong crate does not compile the book. In a repository shaped like rust-lang/mdBook, Cargo.toml is a workspace on edition 2024 with rust-version 1.88.0 and license MPL-2.0. The package mdbook is version 0.5.4. Members are the root crate, crates/*, examples/remove-emphasis/mdbook-remove-emphasis and guide/guide-helper. The library crates are mdbook-core, mdbook-driver, mdbook-html, mdbook-markdown, mdbook-preprocessor, mdbook-renderer and mdbook-summary. pulldown-cmark is pinned at 0.13.4 with a comment that it is part of the public API and must not be bumped. The agent does not touch that line to make a parse test pass.
The binary is src/main.rs. create_clap_command builds init, build, test, clean and completions, and watch and serve are cfg-gated on features. A CLI issue is a change in src/cmd plus a test under tests/testsuite. A markdown issue belongs in mdbook-markdown. A theme or search issue belongs in mdbook-html. The integration suite is tests/testsuite, and its main.rs loads modules such as build, markdown, preprocessor, renderer, redirects and theme, with a prelude that exposes BookTest and snapbox::str. A behaviour change gets a BookTest fixture, a book.toml and a chapter, rather than a unit test that constructs internal structs the suite never uses.
The command CI runs is the one the agent runs. .github/workflows/main.yml's test job installs Rust through ci/install-rust.sh and runs cargo test --workspace --locked --target, then cargo test --workspace --no-default-features. A separate job runs cargo fmt --check. One matrix row is the MSRV, rust 1.88.0, with a comment to keep it aligned with guide/src/guide/installation.md and Cargo.toml. The agent runs cargo test --workspace --locked on the host target. --locked matters because Cargo.lock is in the tree. It runs the no-default-features invocation when the change is not behind the watch or serve feature. It does not run the full operating-system matrix in the sandbox, and the pull request says that.
The book's own source is a useful oracle and a trap. guide/book.toml sets title, output.html, the playground and the search boosts, and guide/src/SUMMARY.md is the table of contents. An issue about the guide is a change there, tested by building that book. An issue about the tool is not fixed by editing the guide to match the bug. rustfmt.toml is the format the fmt job checks. The agent runs cargo fmt on the files it touched and does not reformat the workspace.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Resolve GitHub issue #ISSUE in this repository. Read the issue and its comments. In a workspace laid out like rust-lang/mdBook, read the workspace Cargo.toml first: edition 2024, rust-version 1.88.0, package version 0.5.4. Put a CLI change in src/cmd, a markdown change in crates/mdbook-markdown, and an HTML change in crates/mdbook-html. Do not bump pulldown-cmark. Add a BookTest under tests/testsuite with a book.toml fixture. Run cargo test --workspace --locked, and cargo test --workspace --no-default-features if the change is not feature-gated. Run cargo fmt only on the files you edited. Open a pull request whose body says Fixes and the issue number and includes the cargo test summary. Do not claim the OS matrix ran.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is a pull request. The diff names one crate, the new files under tests/testsuite/
You open the pull request from the session. The transcript shows the cargo test invocation, the target triple, and any fmt check on the edited files. The sandbox did not execute the Windows, macOS and musl rows of main.yml. Those run when the pull request's checks start on GitHub.
Before merging, a reviewer checks that the BookTest would fail without the fix, that the new book.toml does not disable the assertion by turning the feature off, and that edition stays 2024 and rust-version stays 1.88.0. The MSRV comment in Cargo.toml asks for installation.md to move with that field, so a pull request that changes only one of them is sent back.
Run it on every labelled GitHub issue
Have your server accept the GitHub issues webhook. When the event is issues.labeled and the added label is the one you use for this job, POST the body to https://api.prix.dev/o/{org}/sessions with resources set to the repository and the issue number filled into input. Put the webhook delivery id in the Idempotency-Key header so a retry is the same session. Without the Rush GitHub App on that repository the answer is 422 RESOURCE_NOT_ACCESSIBLE.
After you set webhook_url on the key, Rush POSTs run.completed, run.failed or run.cancelled, and the payload's session_url is the GET that carries the pull request. Signatures use the whsec_ secret from when the URL was set. Creates beyond max_concurrent, 4 by default, return 429. A labelling of many old issues should wait for a free slot rather than retry in a tight loop.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
cargo test --workspace --locked on mdBook compiles the CLI, the HTML renderer, the preprocessors and the guide helper. That is a long compile to keep on a laptop that is also editing something else, and --locked fails if you casually cargo update. The agent runs it in a sandbox with a fresh clone, so your local target directory and your Cargo.lock are not the ones under test.
The pull request shows the crate that moved and the BookTest that pins the behaviour. The transcript shows the exact cargo test line and that the operating-system matrix was left to GitHub Actions. Other issues labelled the same way run in parallel, each with its own sandbox and its own branch.
Frequently asked questions
Does it run the whole CI matrix?
It runs cargo test --workspace --locked on the sandbox target, plus the no-default-features form when the change is not behind watch or serve. main.yml also builds musl, macOS, Windows and the 1.88.0 MSRV row. Those stay on the pull request's GitHub Actions runs. The agent does not report them as done.
Will it upgrade pulldown-cmark or the MSRV?
No. The workspace pins pulldown-cmark 0.13.4 and says it is part of the public API, and rust-version is 1.88.0 with a note to keep installation.md in step. A test that needs a newer parser is reported as blocked. The pull request does not edit that dependency to go green.
Where do new tests go?
Under tests/testsuite, as a BookTest with its own book.toml, which is how build, markdown, redirects and theme are already covered. A unit test inside a crate is used only when the issue is about a function that BookTest cannot see, and the pull request says why the integration fixture was not enough.
Does cargo fmt rewrite the repository?
The prompt limits fmt to the files the agent edited. The CI job is cargo fmt --check on the whole workspace, so a drive-by reformat would show up as noise in the diff. rustfmt.toml stays as it is.
What if the issue is about the guide, not the tool?
guide/book.toml and guide/src/SUMMARY.md are the book's own source, and guide/guide-helper is a workspace member. The agent edits those when the issue says the documentation is wrong, and it still adds or adjusts a test when the guide is describing a behaviour the suite can build. It does not edit the guide to hide a tool bug.