Uh oh!
There was an error while loading. Please reload this page.
chore(skill): check branch is synced with origin/staging before pushing - #5529
Conversation
…pushing Prevents PRs from silently picking up extraneous commits when a branch/worktree is cut from a stale or diverged local staging/main.
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryLow Risk Overview Adds Reviewed by Cursor Bugbot for commit 04017a8. Configure here. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Greptile SummaryThis PR updates the ship and babysit workflows to catch stale branch history before it reaches a PR. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (9): Last reviewed commit: "fix(ship-skill): push step needs force-w..." | Re-trigger Greptile |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Ships (via /ship's sync check), waits for Greptile/Cursor Bugbot, triages every open thread (fix real findings, push back on false positives), replies + resolves each thread, re-triggers review, and loops until Greptile is 5/5 with zero open threads.
fddabad to
7eaec2cCompareKeeps the Cursor /commands mirrors of ship and babysit in sync with the Claude Code .agents/skills versions so they don't drift.
…rebase, avoid fixed temp branch name - Final verify now diffs actual commit subjects between git log and the PR, not just a count — a corrupted branch's inflated count could coincidentally match a later count check - The pre-commit count in step 2 was being compared against the post-commit PR in step 9, which would mismatch even on success; now compares content at the point it's actually available - Recovery flow stashes uncommitted work before rebasing so it isn't blocked by a dirty tree, and checks for an existing tmp branch before reusing the name
waleedlatif1
commented
Jul 9, 2026
waleedlatif1
commented
Jul 9, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…p-branch name blocks recovery - A clean git rebase can replay stray commits with zero conflicts, so 'rebase succeeded' was being treated as sufficient — now the log is always re-checked after rebasing, clean or not, before trusting it - The recovery text told the agent to 'pick another name' if ship-sync-tmp was taken but then hardcoded that literal name anyway; now it just deletes the leftover (disposable, single-purpose) branch instead of introducing a naming scheme - babysit's step 5 pointed at re-running the log check alone; it now points at the full /ship step 2 recovery flow, since a review loop spanning a long session is exactly where drift compounds silently
waleedlatif1
commented
Jul 9, 2026
waleedlatif1
commented
Jul 9, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…verify, paginate threads, verify after every push - ship-sync-tmp deletion is now conditional on the branch existing — a bare 'git branch -D' on a first recovery attempt with no leftover would fail and block the rebuild before it started - step 9's final commit-content verify now fetches origin/staging first, matching step 2; a stale local ref could mask real drift - babysit's reviewThreads query now checks pageInfo.hasNextPage and pages through all threads instead of assuming 50 is always enough - babysit now re-runs the sync-content verify after every push, not just before it, so a bad push or a PR that drifted mid-loop doesn't go unnoticed across review rounds
waleedlatif1
commented
Jul 9, 2026
waleedlatif1
commented
Jul 9, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…ing wrong line, stale step reference - git log --oneline is newest-first, gh pr view commits is oldest-first — the two content-verify commands now use --reverse so a positional comparison doesn't spuriously fail on any multi-commit branch - 'select(...) | .body | tail -1' pipes every matching comment's full body through the pipeline and keeps only the last LINE of the combined output (the review-count footer), not the last COMMENT — demonstrated this myself this session reading the footer instead of the actual score. Now uses '[.comments[]] | last | .body' - Cursor's babysit.md pointed at '/ship step 9', but Cursor's ship.md only has 7 steps (no cleanup/migration steps) — now points at step 7 and cross-references the 9-step Claude Code skill copy
waleedlatif1
commented
Jul 9, 2026
waleedlatif1
commented
Jul 9, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…oldest-first - git refuses to delete the branch currently checked out, so if an earlier interrupted recovery left the agent sitting on ship-sync-tmp, the conditional delete would find the branch and then fail to remove it, blocking the rest of the rebuild. Now checks out the original branch first (a no-op if already there). - git log's default order is newest-first; cherry-picking session SHAs in that displayed order applies the newest commit before older ones, which can fail or produce the wrong history with 2+ session commits. Now explicit: cherry-pick oldest-first, using --reverse to get them in that order directly.
waleedlatif1
commented
Jul 9, 2026
waleedlatif1
commented
Jul 9, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…p branch, make tmp delete idempotent - Step 4 of the rebuild checks out ship-sync-tmp at origin/staging, so HEAD no longer contains the session's commits by the time the old step 4 (now step 5) ran 'origin/staging..HEAD' to find them — that range was always empty by then, following the steps literally would cherry-pick nothing. Now captures the SHA list first, against the original branch name explicitly, before any branch switch. - The show-ref-guarded delete still exits 1 (git show-ref's own failure) on the common first-attempt case where there's no leftover branch, which could halt a caller that stops on nonzero exit before ever reaching the rebuild. Replaced with a plain delete + || true, which always succeeds whether or not there was anything to delete.
waleedlatif1
commented
Jul 9, 2026
waleedlatif1
commented
Jul 9, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…s it was meant to leave behind - The 'capture the range' step from the previous round's fix captured origin/staging..<original-branch> wholesale — but in exactly the scenario that triggers this rebuild, that range also contains the unrecognized/stray commits, so cherry-picking 'all of it' recreated the same polluted branch. Now explicit: read the log, write down only the SHA(s) you recognize as your own, never the whole range. - babysit's pre-push gate list named lint/typecheck/boundary-validation but dropped ship's conditional /cleanup and /db-migrate steps, which a review-fix round can trip just as easily as the original commit. - babysit's force-with-lease condition only covered the cherry-pick rebuild path, but a plain 'git rebase origin/staging' that completes with no conflicts also rewrites already-published history and needs the same force push.
waleedlatif1
commented
Jul 9, 2026
waleedlatif1
commented
Jul 9, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
…it's Step 2's sync recovery rewrites already-pushed commits on a branch that's been pushed before, but the push step only said 'push using the current branch name' with no force-with-lease — a plain push would be rejected in exactly the polluted-remote case step 2 exists to fix. babysit already got this fix; ship's own push step didn't.
waleedlatif1
commented
Jul 9, 2026
waleedlatif1
commented
Jul 9, 2026
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 04017a8. Configure here.
Uh oh!
There was an error while loading. Please reload this page.
Summary
git log --oneline origin/staging..HEADbefore pushing, so a branch/worktree cut from a stale or diverged local staging doesn't silently drag dozens of extraneous commits into a PRType of Change
Testing
Verified the recovery steps against PR #5527, which had exactly this problem (branch's local base had a stray commit not in origin/staging, ballooning the PR to 100+ commits) — rebuilt cleanly via cherry-pick per the new instructions.
Checklist