PR babysitter

Keeps the pull requests 1mn opened mergeable — when your base branch moves and a PR goes conflicted, it re-merges the base, conservatively resolves non-overlapping conflicts, and pushes; otherwise it flags the exact region for you.

When 1mn opens a pull request and you don't merge it right away, your main branch keeps moving — and a PR that was clean can go conflicted before you get to it. The PR babysitter keeps those PRs mergeable in the background: it re-merges the latest base into the PR branch, resolves the conflict when doing so is unambiguous, and pushes to the same branch so the review thread stays intact. When a safe resolution isn't possible, it stops and flags the exact conflicting region for you instead of guessing.

Prerequisites

A connected GitHub repo — the babysitter clones it to reproduce and resolve the merge.
An agent-opened pull request. Only PRs 1mn itself opened (from a coding, error triage, docs, or content run) are watched — your own hand-authored PRs are never touched.

How a PR gets watched

You don't start this loop; opening a PR does. The moment a loop opens a pull request, 1mn records a watch for it. That watch lives until the PR reaches a terminal state — merged, closed, or stale — moving through these states in between:

watching — mergeable; nothing to do.
conflicted — the base branch moved and the PR no longer merges cleanly.
resolving — a babysitter run is actively reconciling it.
flagged — the conflict needs human judgment; left for you with the region called out.

A daily sweep re-checks each active watch's mergeability. When one turns conflicted, it spawns a babysitter run to fix it.

How a resolution run works

Confirms the conflict. It reads the PR's current state. If GitHub already reports it clean (the conflict resolved itself upstream) or the PR is closed/merged, there's nothing to do and it says so.
Reproduces the merge. It clones the repo, checks out the PR's head branch, and merges the latest base (usually main) into it — surfacing the exact files git reports as conflicted. It posts a one-line progress note on the originating ticket so you see the run is moving.
Judges each conflict.
- Safe → resolve. The two sides touch different, non-overlapping lines — both changes can coexist (the canonical case is two separate additions, like each side adding a different import). It produces the union of both sides, keeping each side's work, and removes the markers.
- Unsafe → flag. The two sides change the same statement, value, or logic, so the correct combined result needs product judgment. It does not guess. If any conflict in the run is unsafe, the whole run is treated as a flag.
Resolve path: it commits the merge, verifies the build didn't break where that's cheap to check, and pushes to the same head branch — updating the existing PR, never opening a replacement. It leaves a short comment describing exactly what it reconciled.
Flag path: it aborts the merge (pushing nothing) and comments on the PR naming the conflicting file and region, why it's ambiguous, and that a human needs to resolve it manually.

Conservative by design

A wrong auto-resolution is worse than an honest flag. The babysitter only merges when it's confident the result preserves both sides' intent — it never blindly takes one side or deletes the other's work. When in doubt, it flags.

Example

A resolution comment on a PR whose base moved:

Merged latest `main` into this branch. Both sides added a new import to
`app/routes/settings.tsx` on adjacent lines — combined them, both kept,
no logic changed. Back to mergeable.

A flag comment, when the conflict isn't safe to auto-resolve:

The base branch moved and created a conflict I can't safely auto-resolve.
Both this PR and `main` changed the return value of `computeBudget()` in
`app/lib/ads/budget.ts` (lines 48–61) — reconciling them needs a product
decision. Please resolve this one manually.

What you get

A conflicted PR brought back to mergeable — reconciled and pushed to the same branch, with a comment explaining what was combined — or
A clear flag on the PR naming the file, region, and why it's ambiguous, so you can resolve it by hand.

Either way, merging is always yours. The babysitter keeps the PR ready; it never merges.

Notes & limits

Agent-opened PRs only. Your own pull requests are never watched or modified.
Same branch, same PR. Resolutions are pushed to the PR's existing head branch, preserving its review thread — it never opens a replacement PR.
It gives up after repeated re-conflicts. If a PR keeps re-conflicting across about five resolution attempts, the babysitter stops trying and comments that it needs a human.
Watches expire. A PR that goes ~14 days without being merged is marked stale and no longer babysat — merge or close it to keep it live, or reopen it and a new run picks it back up.
One PR per run. Each run fixes the single PR it was spawned for.