Settings

What each option changes, and what it costs you when you turn it off.

Ask me questions

On by default. When the agent hits something genuinely ambiguous it stops and asks, and you answer in a form rather than a conversation. Turn it off and it will decide for itself and list its assumptions in the plan instead — faster, and more likely to build the wrong thing from a thin ticket.

I approve plans

On by default, and the setting most worth keeping. With it on, no code is written until you have read what the agent intends to do. With it off, a ticket becomes a pull request unattended.

Review rounds

How many times the agent may respond to reviewer comments before MergeSmith gives up and hands the pull request to you. Three is a reasonable default. A cap is not pessimism: without one, a reviewer and an agent that disagree will keep each other busy indefinitely.

The cap only limits what happens on its own. From the run page you can send the agent back in for another round after the automatic ones run out, and anything you ask it yourself — through the message box on the run page — never counts against the cap. It guards against a loop, not against you.

Who reviews

Three choices. Your own process leaves things as they are today — MergeSmith waits for whatever review your repository already runs, and does nothing of its own. The reviewer MergeSmith offers is a Claude reviewer workflow, given to you the first time you turn this on as a pull request you merge like any other change to your repository. No reviewskips straight to the merge conditions below.

Whichever you pick, MergeSmith applies your trigger label when the pull request opens, and applies it again after every round of fixes. The reviewer removes the label once it is done with a round, which is what lets MergeSmith apply it again for the next one.

A round is a burst of comments, not a single one. MergeSmith waits until 60 seconds pass with nothing new before treating a review as finished, then sends the agent to address all of it in one pass — six comments in a row from a reviewer still cost one round, not six.

Run out of rounds and MergeSmith stops rather than let the two go back and forth forever: the run stops and asks for you, with the branch and pull request left in place to pick up by hand.

Labels on the pull request

Labels are how MergeSmith starts anything your repository already knows how to do — a reviewer, a preview environment, a staging deploy. It applies the ones you choose and nothing else; what each one means belongs to the workflow that listens for it.

You pick from the labels your repository already has, and MergeSmith will not create one. That is not fastidiousness: GitHub’s API creates an unknown label rather than refusing, so a typo would quietly add something to your repository settings. A label it cannot find is reported on the run instead.

The project sets what is usual and each run can differ — clear them for one ticket, or add a deploy label to another, straight from the run page. Keep the selection matching the project and it keeps following the project; change it and that ticket has its own list. Saving works for the whole run: before the pull request opens the labels wait for it, and afterwards a save changes the pull request right away, even while the agent is working.

Before it may merge

Your own tests need no configuration here. GitHub already refuses to merge a pull request its repository is not happy with, so MergeSmith waits for GitHub to call it mergeable and says which check it is waiting on. Nothing to list, and nothing to keep in step when you change branch protection.

To see what your repository requires, open any pull request — GitHub marks the required checks there.

That leaves only what MergeSmith itself has to do, or ask you for:

• My approval— the pull request waits until you press Merge. You can press it early: the merge still waits for the tests, which is what “merge it when it goes green” means.
• Merge without asking me — the opposite. It merges as soon as GitHub says it can.
• Merge method — squash, merge commit, or rebase.

A pull request that can never become mergeable — a conflict, a failed check — stops the run and says so, rather than waiting for something that cannot happen.

Failing checks

The run page lists every check on the pull request, worst news first, each one linking to its page on GitHub. A failed or cancelled check gets a Run again button — useful for a deploy that hit a flaky moment or a suite that was cancelled mid-run.

A checkbox under the list re-runs failures automatically, for that run only. It tries each check at most twice and then leaves it red: a check that fails twice in a row is telling you something, and spending CI minutes drowning it out helps nobody.

Cost caps

A ceiling per run. When a run passes it, MergeSmith stops the run and asks for you rather than continuing to spend, and leaves the branch and any pull request in place.

A ceiling across a whole month is planned, but nothing enforces one yet — today only the per-run cap actually stops spending.

Notifications

Paste a Slack incoming webhook URL and MergeSmith posts when a plan is ready, when questions are waiting, when a pull request opens, and when something needs you. Each message links back here — the buttons stay in the app.

A Slack webhook is tied to one channel, chosen when you create it. Posting somewhere else means a new webhook, not a change here.

Messages carry the icon of the Slack app the webhook belongs to. Upload one under Basic information → Display information in Slack, or the posts arrive under whatever placeholder Slack gave the app.

Pause

Stops new tickets being picked up, without disconnecting anything. Runs already under way carry on. Useful before a large refactor, or while you are changing what your trigger status means.