Cleave

Problem Large pull requests are where code review breaks down. A 1,000-line PR gets skimmed, approved late, and hides bugs. Stacked PRs fix this, but splitting a big branch by hand is slow and error-prone. Asking an AI to "split it" adds a worse problem: the AI rewrites code while splitting, so the stack no longer matches what was written, and the middle layers often don't pass the tests. Target users: engineers and reviewers on teams that ship big PRs, and open-source maintainers who want AI help without AI-written code. Solution Cleave splits a large PR into a stack of small layers that are proven, not just proposed. The engine cuts the diff into atoms (hunks and whole-file changes) and maps the dependencies between them from the code. Inside IBM Bob IDE, a custom ✂ Cleave mode lets Bob decide how to group and order those atoms, and nothing else: Bob can't edit files or run commands, it can only move hunks through Cleave's tools. The engine then rebuilds every prefix of the stack in its own git worktree and runs the project's tests on each one. A stack is called verified only when five checks pass: every atom appears exactly once (coverage), no layer depends on a later one (order), the top layer is byte-identical to the original PR (fidelity), every layer passes the tests on its own (shippability), and the stack adds zero lines of new code (partition). When a layer fails, Bob reads the test log and moves atoms until it passes. How people use it A developer runs "cleave init" in their repository, opens Bob IDE, switches to ✂ Cleave and types "Cleave <branch> onto main". Bob plans the layers, the engine builds cleave/* branches, and "cleave publish" opens one chained pull request per layer. "cleave push" sends the run to the Cleave web app, which shows the stack, each layer's test results, the activity log and a public proof page reviewers can open. Splits can also be queued from the browser and run on the developer's machine with Bob Shell. Proof on a real PR On our fork of IBM's Galaxium Travels demo app, a 1,034-line PR (loyalty tiers and seat upgrades, 11 files) became 5 layers of 107 to 294 changed lines. Each layer passes the backend's own tests on its own (72, 76, 83, 88 and 92 tests). All 15 atoms are covered, all 18 dependencies are respected, the top tree is identical to the PR, and there are 0 foreign lines, verified in one round. What makes it different? Cleave treats the AI as a planner, not an author. Correctness comes from git and the test suite, not from trusting the model. An evaluation harness applies the same five checks to a one-prompt Bob baseline on diffs rebuilt from real commit history, so the comparison is measured, not claimed.