Ship
Merge it at breakfast.
The pull request is there when you sit down, with the plan it followed, the test results, screenshots and the review comments it has already dealt with. Once you merge, it goes into a release that checks itself before it ships.
Pull requests
Grouped by what they need from you.
Open, waiting on your review, waiting on action, or merged, for one project or all of them.
- One list, sorted by what’s nextEach pull request shows its CI, its review state and the session behind it.
- The diff, the threads, the testsRead the diff and its review threads, comment on lines, and see each commit’s test results and coverage, with the failed and flaky tests listed.
Releases
Readiness checks with teeth.
A release checks itself before it ships, and can be undone for ten minutes after.
- Readiness checksA release checks for open tickets and pull requests, failing CI, migrations that haven’t landed, notes, the runbook and tests. If the test gate fails, nobody can force it through.
- Release notes an agent draftsNotes are written from the work that shipped, and you can edit them. “Polish with agent” drafts customer-facing copy, which replaces the notes only when someone accepts it.
- Ship, and publishShip it, undo it within ten minutes if you need to, copy or download the changelog, and publish a GitHub release or tag to each repo you pick.
How it works
From pull request to release
- ReadyThe pull request arrives with its proof.
- MergeYou review and merge.
- CheckThe release checks its readiness.
- ShipNotes, changelog and GitHub releases.
Questions
Asked about pull requests and releases.
Can a release ship with failing tests?
No. A failing test gate can’t be forced past. A shipped release can be undone for ten minutes.
The waitlist