MergeSmithHow MergeSmith works
MergeSmith turns a ticket into a merged pull request. You stay in charge of the two decisions that matter: whether the plan is right, and whether the result is good enough to ship.
1. You hand over a ticket
Notion tells MergeSmith the moment a ticket reaches the status you chose — many people pair that with a checkbox, so ordinary triage does not hand work over by accident. Nothing else on your board is touched, and a slow background sweep catches anything a notification missed.
2. The agent plans
It reads enough of your repository to write a real plan: which files it will change, and what it will reuse. If the ticket is ambiguous it comes back with questions instead of guessing, and you answer them in a form.
3. You approve
You see the plan before any code exists. Approve it, ask for changes and get a new version, or decline and close the ticket. Nothing is written to your repository until you approve.
4. The agent implements
It works on its own branch and opens a pull request against your default branch. You get a link, and the ticket moves to In Review.
5. Reviewer and agent trade rounds
A reviewer reads the pull request and leaves comments; once they stop for 60 seconds, the agent addresses the whole batch in one pass and pushes again. This repeats up to the number of rounds you set. If comments remain after that, MergeSmith stops and hands it to you rather than looping forever — and from the run page you can send the agent back in for one more round whenever you decide it is worth it.
5½. You can talk to it too
While the pull request is open, the run page has a message box. Ask the agent for a change in your own words — something you noticed on staging, a wording tweak, anything — and it starts a fix round on the same branch. Your requests never count against the review round cap, and a message sent while the agent is mid-round waits and goes with the next one.
6. It merges on your terms
Whatever your repository already requires is waited for — MergeSmith merges only once GitHub says the pull request is mergeable, and says which check it is waiting on meanwhile. On top of that you decide one thing: whether it asks you first, or merges as soon as it can.
What it will not do
- Touch a repository you did not select when installing it.
- Write code before you approve a plan, unless you switch approval off yourself.
- Keep spending after it passes a cost cap you set.
- Deploy anything. It adds a label you already have and waits; the workflow that reacts to it is yours, and MergeSmith never creates a label or changes a repository setting.
- Merge past your own rules. It waits for GitHub to say the pull request is mergeable, so whatever branch protection requires is required.
If something goes wrong
Every run has a timeline showing each step, what the agent reported, who started reviewing, and what MergeSmith decided — newest first, with the plans folded in where they happened. When a run stops early — a failure, a cost cap, or review rounds running out — it says which, and the branch and pull request are still there for you to pick up by hand.
The pull request’s checks sit beside the timeline, each one a link to its page on GitHub. A failed or cancelled check has a Run again button, and a checkbox can re-run failures for you automatically — up to twice per check, then it stays red for a person to look at. Try again sends a stopped run back to the agent, and Cancelends MergeSmith’s involvement while leaving everything already on GitHub exactly as it is.