Teaching an Agent to merge is easy; the hard part is defining when it must not merge

Jiayuan posted a Merge workflow Prompt on X for an Agent to use. Here, Agent refers to an automated agent that can read the repository, run checks, and post comments. PR is a code merge request, CI is continuous integration checking, and issue is a task ticket.

The process has four steps.

1. Check for conflicts or CI problems. Fix any problems first. If you encounter a major change or a change that requires a decision, do not merge; mention Jiayuan for a decision. After fixing and if no decision is needed, merge directly.

2. If there are no conflicts or CI problems, merge directly.

3. Search the GitHub repo for related issues and PRs. If related items are found, comment in the corresponding place and note that the comment was sent automatically by the agent. Determine whether the corresponding issue or PR can be closed. If it can be closed, close it and remind the user that if it was closed incorrectly, they can reopen it manually.

4. Review the content in this issue again and analyze what can be captured later. If there is nothing, do not force it. Give each item a confidence score; create an issue to push forward directly for anything above 70%.

Teaching an Agent to merge is easy. Defining when it must not merge is hard. The major changes in step one are pause points, but the original text does not list more detailed conditions. ziziran added in a reply: list major changes as explicit pause conditions, such as database migrations, permission changes, and incompatible external interfaces. When one is hit, have the Agent post the change location, the impact of continuing to merge, and possible handling options all at once. Other PRs continue with the original process. This way, when it mentions someone, they can go straight into decision-making without first asking where it is stuck.

The value of this addition is that it also writes the information needed for a decision into the pause conditions. If the Agent only reports one sentence saying a decision is needed, the person still has to ask where it is stuck, and the merge workflow breaks down at communication. The vaguer the pause conditions are, the more likely the Agent is to continue in the wrong place. Writing clear pause conditions is equivalent to moving the decision point earlier.

Among the four steps, steps three and four are easy to overlook. They do not directly determine whether code can be merged, but they determine whether the repository is clearer after merging. Automated comments note their source, related issues are closed when possible and can be reopened manually if closed incorrectly, and these actions make the Agent's behavior traceable. Step four does not force capture; an issue is created only when confidence exceeds 70%, which also avoids creating tasks just for the sake of process.

Original link: https://x.com/jiayuan_jy/status/2118771384122061091