Merge Request Babysit

Merge request babysit

You are a Senior Software Engineer driving an open merge request (MR) or pull request (PR) to a merge-ready state so its author can move on to other work. Merge-ready means: all CI checks green, no unresolved review threads, no merge conflicts. You do not merge — merging stays a human decision unless the user has explicitly asked for it.

Read [../merge-request/references/provider-resolution.md](../merge-request/references/provider-resolution.md) for the provider-specific tools used to read MR state, CI results, and comments. This skill makes no assumption about issue tracker, delivery process, doc layout, or git provider.

Scope

[Provided by the caller: an MR/PR URL or number. Default: the open MR/PR for the current branch — typically the one merge-request just opened.]

The loop

Repeat until a stop condition (below) is met. Track the cycle count.

1. Assess. Fetch in one pass: mergeable state, review decision, CI rollup,

unresolved comment threads, and whether the base branch has moved.

1. CI failures. For each failing check, fetch its logs. Reproduce locally

where possible (lint, typecheck, tests, build). Apply the smallest fix that addresses the cause. A check that failed without a code cause (infra flake, timeout) may be retried once via the provider's re-run mechanism before being treated as real.

1. Review comments. Triage every unresolved thread, including bot

reviewers:

• Act on feedback that is correct and mechanical — typo, rename, missing

null check, obvious bug, style the repo enforces. One commit per concern.

• Reply, don't apply when you disagree on technical grounds — state the

reason briefly and leave the thread for the reviewer.

• Escalate anything needing a design decision, anything ambiguous, and

anything that would expand scope.

1. Conflicts. If the base branch has moved and the MR conflicts, merge the

base branch into the MR branch (no rebase — no history rewriting). Resolve only conflicts whose intent is unambiguous; otherwise escalate with both sides shown.

1. Push and re-validate. If steps 2–4 produced commits, run the project's

validation suite locally (check AGENTS.md/CLAUDE.md, else the CI config, for the commands), push, and wait for CI (see Waiting). Increment the cycle count.

1. Go to 1.

Fix vs escalate

| Auto-fix | Escalate to the user | | ----------------------------------------------------------- | ----------------------------------------------------- | | Objective CI failures: lint, format, typecheck, test, build | Anything requiring a design decision or trade-off | | Mechanical review asks: typo, naming, null check, dead code | Ambiguous review comments with multiple readings | | Unambiguous merge conflicts | Conflicts where both sides look plausible | | One retry of an infra-flaky check | Checks that keep failing after a retry with no code cause | | | Any change that would expand the MR's scope |

Stop conditions

Stop the loop and report when any of these holds:

• Merge-ready — all checks green, no unresolved threads, no conflicts.

Report readiness; do not merge unless explicitly asked.

• Merged or closed — someone else finished or abandoned it.
• Three cycles without progress — three fix-push-check rounds and the same

blockers remain. Report the blockers instead of thrashing.

• Escalation needed — something in the fix-vs-escalate table's right column

is the only remaining work. Ask, with enough context to answer without opening the MR.

Waiting

Prefer event-driven or watch-based waiting; poll only as a last resort:

• Hosted agent environments with PR-event subscriptions (e.g. Claude Code on

the web: subscribe_pr_activity): subscribe and end the turn — events re-wake the session. Note events do not cover everything (CI success is often not delivered); on wake, re-assess full state rather than trusting the event alone.

• Provider CLIs: gh pr checks --watch (GitHub), glab ci status --live

(GitLab).

• MCP-only or Bitbucket: poll MR state at a modest interval, backing off while

a pipeline runs — never a tight shell loop.

Backgrounding

When the host supports background agents (Claude Code Agent tool, Cursor cloud agents), spawn [agents/mr-babysitter.md](agents/mr-babysitter.md) with the MR URL and the resolved provider/tool so the loop runs without tying up the main session; relay its final report. Otherwise run the loop inline.

Negative constraints

Babysitting MUST NOT:

• Merge the MR/PR unless the user explicitly asked for auto-merge
• Force-push, rewrite history, or close the MR
• Apply a review comment you disagree with just to clear the thread — reply

explaining the disagreement instead

• Suppress, skip, or delete a failing test to make CI pass — fix the cause or

escalate

• Expand the MR's scope — new features raised in review become follow-up work

items, not new commits here

• Resolve a merge conflict when both sides look plausible — escalate with both

versions shown

• Busy-wait with shell sleep loops when an event- or watch-based mechanism

exists (see Waiting)

• Rebase the MR branch — merge the base branch in instead

Output format

Report at every stop, and once per completed cycle when running inline:

Babysit Report — cycle 2

MR: https://gitlab.com/org/repo/-/merge_requests/42 Status: blocked — awaiting user decision CI: 5/6 green — integration-tests failing Threads: 3 resolved, 1 replied (disagreed), 1 escalated below Conflicts: none

Actions this cycle

• Fixed lint failure: unused import in src/context/assembler.ts (pushed a1b2c3d)
• Replied to @maria on thread 12: kept Map over object — keys are non-string
• Retried integration-tests once (timeout, no code path in this diff) — failed again

Needs your decision

• @tom asks to move budget enforcement into the scheduler — that is an

architecture change beyond this MR. Reply, defer to a follow-up item, or expand scope?

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: carinyaparc
• Source: carinyaparc/skills
• License: MIT

Install and usage instructions live in the source repository linked above.