fix(babysit): trim merge-conflict handling to essentials

Author: TheodoreSpeaks

.agents/skills/babysit/SKILL.md

@@ -7,11 +7,10 @@ description: Drive a PR to a clean review (Greptile 5/5, zero open threads) —
 
 Owns a PR end-to-end through review: ship it, wait for the automatic review round, and if it
 isn't already clean, drive fix → reply → resolve → re-review cycles until Greptile reports 5/5
-and there are zero open comment threads. Also keeps the branch mergeable against staging — a
-long-running loop spans hours during which staging can drift out from under the PR and produce
-a real merge conflict, not just the stray-local-commit drift `/ship`'s sync check catches.
-Designed to be run under `/loop` (no fixed interval — let it self-pace on review latency) so it
-survives across multiple wakeups in the same session.
+and there are zero open comment threads. Also keeps the branch mergeable against staging, since
+a long babysit session can outlast staging moving underneath it. Designed to be run under
+`/loop` (no fixed interval — let it self-pace on review latency) so it survives across multiple
+wakeups in the same session.
 
 ## When to use
 
@@ -36,10 +35,9 @@ round. Always check both conditions freshly after every push.
 
 ## Loop
 
-1. **Check current state** before doing anything — this includes mergeable state, not just
-   review state:
+1. **Check current state** before doing anything, including whether the PR is still mergeable:
    ```bash
-   gh pr view <n> --json mergeable,mergeStateStatus
+   gh pr view <n> --json mergeable
    gh pr view <n> --json comments -q '[.comments[] | select(.author.login=="greptile-apps")] | last | .body'
    gh api graphql -f query='
    query { repository(owner: "<owner>", name: "<repo>") { pullRequest(number: <n>) {
@@ -54,44 +52,16 @@ round. Always check both conditions freshly after every push.
    stop yet: re-run the same query with `after: "<endCursor>"` and keep paging until
    `hasNextPage` is `false` before evaluating "clean." A PR with more than 50 threads is rare but
    stopping on a partial page would silently miss unresolved ones past the cutoff.
-   `mergeable` is `UNKNOWN` for a few seconds right after any push or base-branch move while
-   GitHub computes it — re-poll `gh pr view <n> --json mergeable` every few seconds until it
-   settles to `MERGEABLE` or `CONFLICTING` before acting on it; don't treat `UNKNOWN` as either.
-   If `mergeable` is `CONFLICTING`, skip straight to step 2 (Resolve merge conflicts) — do not
-   evaluate review cleanliness yet, since Greptile/Cursor threads anchored to a conflicting diff
-   can be stale and CI can't even run to confirm anything.
-   If `mergeable` is `MERGEABLE`, Greptile is 5/5, and every thread across all pages has
-   `isResolved: true`, stop — report the outcome (see "Reporting" below) and skip the rest of
-   this list.
-
-2. **If `mergeable` is `CONFLICTING`**, resolve it before anything else this round. This can
-   happen even on a PR that was clean at creation, since staging moves several times a day —
-   recheck every iteration, don't assume it's a one-time state handled by `/ship`.
-   ```bash
-   git status                      # stash -u first (ship-sync-fix pattern) if anything uncommitted
-   git fetch origin staging
-   git rebase origin/staging
-   ```
-   Resolve each conflicted file on its actual merits — open it, read both sides inside the
-   `<<<<<<<` / `=======` / `>>>>>>>` markers, and keep the intent of *both* changes where they're
-   not truly contradictory. Never resolve with a blanket `git checkout --ours`/`--theirs` across
-   a whole file — that silently discards one side's real change instead of merging it. `git add`
-   each resolved file, then `git rebase --continue`; repeat until the rebase finishes clean (a
-   rebase with **zero remaining conflicts** does not by itself mean the resolution is correct —
-   see the next point).
-   - A conflict resolution is a code change like any other: before pushing, run this repo's
-     typecheck/lint pass on the touched files (the same checks `/ship` step 6 runs) — merge
-     markers can resolve syntactically clean and still be semantically wrong or fail to compile.
-   - Push with `git push --force-with-lease` — a rebase here always rewrites already-published
-     history, so a plain `git push` will be rejected.
-   - Re-poll `gh pr view <n> --json mergeable,mergeStateStatus` until it reports `MERGEABLE`
-     (not `UNKNOWN`) before moving on. If it still reports `CONFLICTING`, the rebase resolved
-     against a stale local `origin/staging` — `git fetch origin staging` again and redo the
-     rebase; don't push a second time believing it's fixed without this recheck.
-   - This push needs a fresh review like any other code change — go to step 8 (re-trigger
-     review) rather than trying to also address old review threads in the same pass, especially
-     if the conflict touched files a thread was anchored to (that anchor may no longer be valid
-     against the resolved code). Re-evaluate thread state fresh once the new round lands.
+   If `mergeable` comes back `CONFLICTING`, go fix that first (step 2) before evaluating review
+   state — a conflicting PR can't run CI, and this can happen mid-loop even on a PR that was
+   clean at creation, since staging moves several times a day. Otherwise, if Greptile is 5/5 and
+   every thread across all pages has `isResolved: true`, stop — report the outcome (see
+   "Reporting" below) and skip the rest of this list.
+
+2. **If the PR has a merge conflict**, fix it: `git fetch origin staging`, `git rebase
+   origin/staging`, resolve the conflicts for real (don't just take one side blindly), then push
+   with `--force-with-lease`. Continue on to step 8 to trigger a fresh review of the resolved
+   code.
 
 3. **If no review has run yet** (fresh PR, no Greptile/Cursor comments): they usually run
    automatically on PR open — confirm via `gh pr checks <n>` (look for `Cursor Bugbot` /
@@ -130,11 +100,7 @@ round. Always check both conditions freshly after every push.
    committing — not just lint/typecheck/boundary-validation, but also the conditional `/cleanup`
    (if this round's fix touched UI code) and `/db-migrate` (if it touched schema/migrations)
    gates from `/ship` steps 4 and 5. A review-fix round is still a code change and can trip
-   either gate just as easily as the original commit did. This is the same sync check as step 2
-   above but for local-drift, not for the base-branch textual conflicts step 2 handles — step 2
-   already left the branch rebased onto current `origin/staging` when it ran, so this step is
-   normally a no-op in that case, but still run it: it also catches stray local commits that
-   have nothing to do with merge conflicts.
+   either gate just as easily as the original commit did.
 
 7. **Commit and push** the round's fixes as one commit — `--force-with-lease` whenever step 6's
    sync check rewrote history, which includes a plain `git rebase origin/staging` that completed
@@ -164,17 +130,15 @@ round. Always check both conditions freshly after every push.
    in a sleep loop. Pass the same `/loop babysit PR <n>` prompt on each wakeup so the loop
    resumes correctly.
 
-10. **Stop conditions**: clean state reached (see above), or the same unresolved finding
-    survives two consecutive rounds with no new information, or the same merge conflict recurs
-    every round with no new information (e.g. a semantic conflict you can't confidently resolve
-    without changing intent), or the user interrupts — surface any of these to the user instead
-    of looping forever.
+10. **Stop conditions**: clean state reached (see above), or the same unresolved finding or
+    merge conflict survives two consecutive rounds with no new information (surface it to the
+    user instead of looping forever), or the user interrupts.
 
 ## Reporting
 
-When the loop ends, summarize: how many rounds it took, what was actually fixed (one line each),
-what was pushed back on as a false positive and why, how many merge conflicts came up and against
-which staging commits (if any), and the final Greptile score / thread count / mergeable state.
+When the loop ends, summarize: how many rounds it took, what was actually fixed (one line each,
+including any merge conflict resolved), what was pushed back on as a false positive and why, and
+the final Greptile score / thread count.
 
 ## Hard rules
 
@@ -184,9 +148,4 @@ which staging commits (if any), and the final Greptile score / thread count / me
   pattern elsewhere in the codebase solving the same class of problem and match it.
 - Never silently drop a finding — every thread gets either a code fix or a reasoned reply.
 - Always re-run the `/ship`-style sync check before every push in the loop, not just the first.
-- Never resolve a merge conflict with a blanket `--ours`/`--theirs` across a whole file — read
-  both sides and preserve the real intent of each; a wrong resolution ships silently since
-  nothing else catches it.
-- Never treat `mergeable: UNKNOWN` as either `MERGEABLE` or `CONFLICTING` — poll until it settles.
-- Never evaluate review-thread cleanliness while `mergeable` is `CONFLICTING` — resolve the
-  conflict first, since threads anchored to a conflicting diff can be stale.
+- Never resolve a merge conflict by blindly taking one side — check the actual diff.

.claude/commands/babysit.md

@@ -6,11 +6,10 @@ description: Drive a PR to a clean review (Greptile 5/5, zero open threads) —
 
 Owns a PR end-to-end through review: ship it, wait for the automatic review round, and if it
 isn't already clean, drive fix → reply → resolve → re-review cycles until Greptile reports 5/5
-and there are zero open comment threads. Also keeps the branch mergeable against staging — a
-long-running loop spans hours during which staging can drift out from under the PR and produce
-a real merge conflict, not just the stray-local-commit drift `/ship`'s sync check catches.
-Designed to be run under `/loop` (no fixed interval — let it self-pace on review latency) so it
-survives across multiple wakeups in the same session.
+and there are zero open comment threads. Also keeps the branch mergeable against staging, since
+a long babysit session can outlast staging moving underneath it. Designed to be run under
+`/loop` (no fixed interval — let it self-pace on review latency) so it survives across multiple
+wakeups in the same session.
 
 ## When to use
 
@@ -35,10 +34,9 @@ round. Always check both conditions freshly after every push.
 
 ## Loop
 
-1. **Check current state** before doing anything — this includes mergeable state, not just
-   review state:
+1. **Check current state** before doing anything, including whether the PR is still mergeable:
    ```bash
-   gh pr view <n> --json mergeable,mergeStateStatus
+   gh pr view <n> --json mergeable
    gh pr view <n> --json comments -q '[.comments[] | select(.author.login=="greptile-apps")] | last | .body'
    gh api graphql -f query='
    query { repository(owner: "<owner>", name: "<repo>") { pullRequest(number: <n>) {
@@ -53,44 +51,16 @@ round. Always check both conditions freshly after every push.
    stop yet: re-run the same query with `after: "<endCursor>"` and keep paging until
    `hasNextPage` is `false` before evaluating "clean." A PR with more than 50 threads is rare but
    stopping on a partial page would silently miss unresolved ones past the cutoff.
-   `mergeable` is `UNKNOWN` for a few seconds right after any push or base-branch move while
-   GitHub computes it — re-poll `gh pr view <n> --json mergeable` every few seconds until it
-   settles to `MERGEABLE` or `CONFLICTING` before acting on it; don't treat `UNKNOWN` as either.
-   If `mergeable` is `CONFLICTING`, skip straight to step 2 (Resolve merge conflicts) — do not
-   evaluate review cleanliness yet, since Greptile/Cursor threads anchored to a conflicting diff
-   can be stale and CI can't even run to confirm anything.
-   If `mergeable` is `MERGEABLE`, Greptile is 5/5, and every thread across all pages has
-   `isResolved: true`, stop — report the outcome (see "Reporting" below) and skip the rest of
-   this list.
-
-2. **If `mergeable` is `CONFLICTING`**, resolve it before anything else this round. This can
-   happen even on a PR that was clean at creation, since staging moves several times a day —
-   recheck every iteration, don't assume it's a one-time state handled by `/ship`.
-   ```bash
-   git status                      # stash -u first (ship-sync-fix pattern) if anything uncommitted
-   git fetch origin staging
-   git rebase origin/staging
-   ```
-   Resolve each conflicted file on its actual merits — open it, read both sides inside the
-   `<<<<<<<` / `=======` / `>>>>>>>` markers, and keep the intent of *both* changes where they're
-   not truly contradictory. Never resolve with a blanket `git checkout --ours`/`--theirs` across
-   a whole file — that silently discards one side's real change instead of merging it. `git add`
-   each resolved file, then `git rebase --continue`; repeat until the rebase finishes clean (a
-   rebase with **zero remaining conflicts** does not by itself mean the resolution is correct —
-   see the next point).
-   - A conflict resolution is a code change like any other: before pushing, run this repo's
-     typecheck/lint pass on the touched files (the same checks `/ship` step 6 runs) — merge
-     markers can resolve syntactically clean and still be semantically wrong or fail to compile.
-   - Push with `git push --force-with-lease` — a rebase here always rewrites already-published
-     history, so a plain `git push` will be rejected.
-   - Re-poll `gh pr view <n> --json mergeable,mergeStateStatus` until it reports `MERGEABLE`
-     (not `UNKNOWN`) before moving on. If it still reports `CONFLICTING`, the rebase resolved
-     against a stale local `origin/staging` — `git fetch origin staging` again and redo the
-     rebase; don't push a second time believing it's fixed without this recheck.
-   - This push needs a fresh review like any other code change — go to step 8 (re-trigger
-     review) rather than trying to also address old review threads in the same pass, especially
-     if the conflict touched files a thread was anchored to (that anchor may no longer be valid
-     against the resolved code). Re-evaluate thread state fresh once the new round lands.
+   If `mergeable` comes back `CONFLICTING`, go fix that first (step 2) before evaluating review
+   state — a conflicting PR can't run CI, and this can happen mid-loop even on a PR that was
+   clean at creation, since staging moves several times a day. Otherwise, if Greptile is 5/5 and
+   every thread across all pages has `isResolved: true`, stop — report the outcome (see
+   "Reporting" below) and skip the rest of this list.
+
+2. **If the PR has a merge conflict**, fix it: `git fetch origin staging`, `git rebase
+   origin/staging`, resolve the conflicts for real (don't just take one side blindly), then push
+   with `--force-with-lease`. Continue on to step 8 to trigger a fresh review of the resolved
+   code.
 
 3. **If no review has run yet** (fresh PR, no Greptile/Cursor comments): they usually run
    automatically on PR open — confirm via `gh pr checks <n>` (look for `Cursor Bugbot` /
@@ -129,11 +99,7 @@ round. Always check both conditions freshly after every push.
    committing — not just lint/typecheck/boundary-validation, but also the conditional `/cleanup`
    (if this round's fix touched UI code) and `/db-migrate` (if it touched schema/migrations)
    gates from `/ship` steps 4 and 5. A review-fix round is still a code change and can trip
-   either gate just as easily as the original commit did. This is the same sync check as step 2
-   above but for local-drift, not for the base-branch textual conflicts step 2 handles — step 2
-   already left the branch rebased onto current `origin/staging` when it ran, so this step is
-   normally a no-op in that case, but still run it: it also catches stray local commits that
-   have nothing to do with merge conflicts.
+   either gate just as easily as the original commit did.
 
 7. **Commit and push** the round's fixes as one commit — `--force-with-lease` whenever step 6's
    sync check rewrote history, which includes a plain `git rebase origin/staging` that completed
@@ -163,17 +129,15 @@ round. Always check both conditions freshly after every push.
    in a sleep loop. Pass the same `/loop babysit PR <n>` prompt on each wakeup so the loop
    resumes correctly.
 
-10. **Stop conditions**: clean state reached (see above), or the same unresolved finding
-    survives two consecutive rounds with no new information, or the same merge conflict recurs
-    every round with no new information (e.g. a semantic conflict you can't confidently resolve
-    without changing intent), or the user interrupts — surface any of these to the user instead
-    of looping forever.
+10. **Stop conditions**: clean state reached (see above), or the same unresolved finding or
+    merge conflict survives two consecutive rounds with no new information (surface it to the
+    user instead of looping forever), or the user interrupts.
 
 ## Reporting
 
-When the loop ends, summarize: how many rounds it took, what was actually fixed (one line each),
-what was pushed back on as a false positive and why, how many merge conflicts came up and against
-which staging commits (if any), and the final Greptile score / thread count / mergeable state.
+When the loop ends, summarize: how many rounds it took, what was actually fixed (one line each,
+including any merge conflict resolved), what was pushed back on as a false positive and why, and
+the final Greptile score / thread count.
 
 ## Hard rules
 
@@ -183,9 +147,4 @@ which staging commits (if any), and the final Greptile score / thread count / me
   pattern elsewhere in the codebase solving the same class of problem and match it.
 - Never silently drop a finding — every thread gets either a code fix or a reasoned reply.
 - Always re-run the `/ship`-style sync check before every push in the loop, not just the first.
-- Never resolve a merge conflict with a blanket `--ours`/`--theirs` across a whole file — read
-  both sides and preserve the real intent of each; a wrong resolution ships silently since
-  nothing else catches it.
-- Never treat `mergeable: UNKNOWN` as either `MERGEABLE` or `CONFLICTING` — poll until it settles.
-- Never evaluate review-thread cleanliness while `mergeable` is `CONFLICTING` — resolve the
-  conflict first, since threads anchored to a conflicting diff can be stale.
+- Never resolve a merge conflict by blindly taking one side — check the actual diff.