How 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; the agent addresses them 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.

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, and what MergeSmith decided. 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.