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.

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 reviewer label to another. The choice stays changeable until the pull request opens, after which the pull request is the truth.

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.

Cost caps

A ceiling per run and per month. When a run passes its cap MergeSmith stops it and asks for you, rather than continuing to spend. The branch and any pull request are left in place.

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.

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.