Introducing Sheltie: merge agent pull requests in parallel
Sheltie is a GitHub App that computes what every pull request touches, lands independent ones together and resolves conflicts in escalating tiers. Open source, Apache-2.0, early 0.x.
Sheltie
Parallel merge engine for agent-generated PRs, with conflict tiers, as a GitHub App.
- License
- Apache-2.0
- Runs as
- A GitHub App next to your CI
- Build tools
- Cargo, Go, JS/TS, Python, Maven, Gradle
The problem
Coding agents open more pull requests than a one-at-a-time merge queue can land. Every pull request waits for the ones ahead of it, and when two agents touch the same code, the conflict goes back to a person.
How it works
- Pull request: An agent opens it; GitHub tells Sheltie
- Footprint: What it writes and affects, from your CI
- Scheduler: Independent ones land together
- Conflict tiers: Structural merge; Regenerate; Declared rules; Replay by an agent
- Fast-forward: Default branch moves; never a force-push
What it does
- Footprints
- An adapter on your CI runner computes which build targets a pull request writes and which it affects. Two pull requests conflict only when one writes what the other writes or affects.
- Parallel landing
- Independent pull requests land together. Overlapping ones are built speculatively together or sent to the merge engine.
- Conflict tiers
- Structural merge, regenerated derived files, declared merge rules, and finally the change re-derived by an agent, checked against the tests it adds.
- Never force-pushes
- The committer checks that nothing that landed meanwhile touches the change, then fast-forwards the default branch. A red commit on main is bisected and reverted automatically.
- Agents that don't collide
- Before work starts, Sheltie keeps agents off overlapping issues. Agents ask over MCP; agents assigned on GitHub are held and released automatically.
- Shadow mode first
- Sheltie only reports what it would do until you switch a repository to merge mode. Builds, tests and agent jobs run on your runners with your API keys.
Try it
git clone https://github.com/softberries/sheltie && cd sheltie
scripts/register-github-app.py --url https://sheltie.example.com
docker compose up -d --buildOn the demo repository
A script opened a batch of agent-style pull requests on a small Cargo workspace: mostly
independent, some editing the same files, one breaking another only when combined. Two batches
ran on 2026-10-17 against demo.sheltie.dev in merge mode. Measured by Sheltie, against a
one-at-a-time queue simulated from the same ready times and the median CI time on main
(1 min 50 s):
| Sheltie | One at a time | |
|---|---|---|
| Pull requests landed | 17 | 17 |
| Median time from ready to landed | 18 s | 7 min 7 s |
| Longest wait | 6 min 37 s | 14 min 5 s |
| Total waiting | 23 min | 2 h 8 min |
The merge engine resolved 3 by declared merge rules; 2 that broke only when combined with an earlier change were re-derived from their intent by Claude Code. One demo, one workspace: a measurement, not a promise.
Status: early 0.x
Sheltie is a small Rust service and Postgres, self-hosted with Docker Compose or Helm. The control plane only does set arithmetic and talks to GitHub; there is no telemetry. Bazel, sbt and Mill are planned, not supported.
Writing about Sheltie