fix(ship-skill,babysit): fix reversed commit-list order, tail-1 grabbing 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

Author: waleedlatif1

.agents/skills/babysit/SKILL.md

@@ -35,12 +35,16 @@ round. Always check both conditions freshly after every push.
 
 1. **Check current state** before doing anything:
    ```bash
-   gh pr view <n> --json comments -q '.comments[] | select(.author.login=="greptile-apps") | .body' | tail -1
+   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>) {
      reviewThreads(first: 50) { pageInfo { hasNextPage endCursor } nodes { id isResolved path line
        comments(first: 5) { nodes { id databaseId author { login } body } } } } } } }'
    ```
+   `[.comments[]] | last | .body`, not `... | .body | tail -1` — the latter pipes every matching
+   comment's full multi-line body through the pipeline and keeps only the final *line* of that
+   combined output (usually the "Reviews (n): Last reviewed commit..." footer), not the last
+   *comment*, so it silently misses the actual "Confidence Score: X/5" line.
    `reviewThreads(first: 50)` is a single page — check `pageInfo.hasNextPage`. If `true`, don't
    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
@@ -88,9 +92,11 @@ round. Always check both conditions freshly after every push.
    sync check required a rebuild), then run `/ship` step 9's post-push verify — not just before
    the first push, every push in the loop:
    ```bash
-   git fetch origin staging && git log --oneline origin/staging..HEAD
+   git fetch origin staging && git log --oneline --reverse origin/staging..HEAD
    gh pr view <n> --json commits -q '.commits[].messageHeadline'
    ```
+   `--reverse` matches `git log`'s newest-first default to the PR commit list's oldest-first
+   order — without it a positional comparison can spuriously fail on any multi-commit branch.
    These two lists must describe the same commits. A review loop runs many pushes across many
    rounds; checking sync only before the push (step 5) and never after is how a bad push or a
    PR whose commit history quietly went stale between rounds goes unnoticed.

.agents/skills/ship/SKILL.md

@@ -35,13 +35,16 @@ When the user runs `/ship`:
 8. **Push to origin** using the current branch name
 9. **Create a PR** to staging with a description in the user's voice, then do a final content check — not a count check — comparing what actually landed:
    ```bash
-   git fetch origin staging && git log --oneline origin/staging..HEAD
+   git fetch origin staging && git log --oneline --reverse origin/staging..HEAD
    gh pr view <n> --json commits -q '.commits[].messageHeadline'
    ```
    Re-fetch first — comparing against a stale local `origin/staging` ref can mask real drift or
-   flag a false mismatch even when the branch and push are correct. These two lists must
-   describe the same commits (same subjects, one of which is the commit from step 7). If they
-   don't match, the branch still has a problem — redo step 2's fix and `git push --force-with-lease`.
+   flag a false mismatch even when the branch and push are correct. `--reverse` makes the git log
+   oldest-first, matching the PR commit list's order — plain `git log` is newest-first, and a
+   positional/line-by-line comparison against the PR's oldest-first list can spuriously fail on
+   any multi-commit branch. These two lists must describe the same commits in the same order
+   (same subjects, the last one being the commit from step 7). If they don't match, the branch
+   still has a problem — redo step 2's fix and `git push --force-with-lease`.
 
 ## Commit Message Format
 

.cursor/commands/babysit.md

@@ -29,12 +29,16 @@ round. Always check both conditions freshly after every push.
 
 1. **Check current state** before doing anything:
    ```bash
-   gh pr view <n> --json comments -q '.comments[] | select(.author.login=="greptile-apps") | .body' | tail -1
+   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>) {
      reviewThreads(first: 50) { pageInfo { hasNextPage endCursor } nodes { id isResolved path line
        comments(first: 5) { nodes { id databaseId author { login } body } } } } } } }'
    ```
+   `[.comments[]] | last | .body`, not `... | .body | tail -1` — the latter pipes every matching
+   comment's full multi-line body through the pipeline and keeps only the final *line* of that
+   combined output (usually the "Reviews (n): Last reviewed commit..." footer), not the last
+   *comment*, so it silently misses the actual "Confidence Score: X/5" line.
    `reviewThreads(first: 50)` is a single page — check `pageInfo.hasNextPage`. If `true`, don't
    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
@@ -79,12 +83,15 @@ round. Always check both conditions freshly after every push.
    `/ship` does before committing.
 
 6. **Commit and push** the round's fixes as one commit (`--force-with-lease` only if step 5's
-   sync check required a rebuild), then run `/ship` step 9's post-push verify — not just before
-   the first push, every push in the loop:
+   sync check required a rebuild), then run `/ship` step 7's post-push verify — not just before
+   the first push, every push in the loop (the Cursor `/ship` has 7 steps; the Claude Code skill
+   version's equivalent is step 9 — see `.agents/skills/babysit/SKILL.md` if working from that copy):
    ```bash
-   git fetch origin staging && git log --oneline origin/staging..HEAD
+   git fetch origin staging && git log --oneline --reverse origin/staging..HEAD
    gh pr view <n> --json commits -q '.commits[].messageHeadline'
    ```
+   `--reverse` matches `git log`'s newest-first default to the PR commit list's oldest-first
+   order — without it a positional comparison can spuriously fail on any multi-commit branch.
    These two lists must describe the same commits. A review loop runs many pushes across many
    rounds; checking sync only before the push (step 5) and never after is how a bad push or a
    PR whose commit history quietly went stale between rounds goes unnoticed.

.cursor/commands/ship.md

@@ -29,13 +29,16 @@ When the user runs `/ship`:
 
 7. **Create a PR** to staging with a description in the user's voice, then do a final content check — not a count check — comparing what actually landed:
    ```bash
-   git fetch origin staging && git log --oneline origin/staging..HEAD
+   git fetch origin staging && git log --oneline --reverse origin/staging..HEAD
    gh pr view <n> --json commits -q '.commits[].messageHeadline'
    ```
    Re-fetch first — comparing against a stale local `origin/staging` ref can mask real drift or
-   flag a false mismatch even when the branch and push are correct. These two lists must
-   describe the same commits (same subjects, one of which is the commit from step 5). If they
-   don't match, the branch still has a problem — redo step 2's fix and `git push --force-with-lease`.
+   flag a false mismatch even when the branch and push are correct. `--reverse` makes the git log
+   oldest-first, matching the PR commit list's order — plain `git log` is newest-first, and a
+   positional/line-by-line comparison against the PR's oldest-first list can spuriously fail on
+   any multi-commit branch. These two lists must describe the same commits in the same order
+   (same subjects, the last one being the commit from step 5). If they don't match, the branch
+   still has a problem — redo step 2's fix and `git push --force-with-lease`.
 
 ## Commit Message Format