# Ship And Babysit

> End-to-end PR shipping workflow for tinyhumansai/openhuman: commit local changes, push to the user's fork, open or reuse a PR against main, then babysit CI and CodeRabbit feedback until the PR is green and clean. Use when the user asks to ship, open a PR, monitor CI, address review comments, or 'babysit' a branch.

- Skill: `lgwanai/ship-and-babysit` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add lgwanai/ship-and-babysit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lgwanai/ship-and-babysit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: lgwanai (https://skillmd.com/u/lgwanai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lgwanai/ship-and-babysit

---


# Ship and Babysit

Use this skill for `tinyhumansai/openhuman` when the user wants a branch shipped end to end:

- commit the local changes
- push the branch to the user's fork
- open or reuse a PR against `tinyhumansai/openhuman:main`
- monitor CI and review feedback in a polling loop
- address actionable review comments and push follow-up fixes
- stop only when the PR is green and clean

## Preconditions

- Work from the repository root.
- Follow repo rules from `AGENTS.md`, including validation and PR checklist requirements.
- Assume `origin` is the user's writable fork and `upstream` points to `tinyhumansai/openhuman`.
- Resolve the fork owner once near the start and reuse it:
  - `FORK_OWNER=$(git remote get-url origin | sed -E 's#.*[:/]([^/]+)/[^/]+(\.git)?$#\1#')`
- If `origin` resolves to `tinyhumansai`, stop and ask the user to add a fork remote. Never push branches to upstream.
- If work starts on local `main`, create a new descriptive branch before committing so the changes leave `main` immediately.
- Never push directly to `main`.
- Never push to `upstream`.
- Never amend or rewrite commits that are already pushed unless the user explicitly asks for it.
- Never bypass hooks for breakage introduced by your own changes.

## Workflow

### Phase 1: Inspect and Commit

1. Inspect the branch before changing anything. Prefer parallel reads:
   - `git status --short`
   - `git diff --stat`
   - `git diff --cached --stat`
   - `git log --oneline --decorate -n 12`
2. Determine the current branch:
   - `git rev-parse --abbrev-ref HEAD`
3. Confirm the branch normally follows `feat/`, `fix/`, `refactor/`, `chore/`, `docs/`, or `test/`.
   - If the current branch is `main`, create a new descriptive branch immediately and continue there.
   - If the name does not follow convention and it is already a non-`main` branch, ask before renaming. Do not auto-rename a pushed branch.
4. If there are uncommitted changes, carry them onto the new branch before doing anything else so local `main` stays free of agent-authored commits.
5. If there are uncommitted changes, run the smallest meaningful local validation for the touched area before committing.
6. Stage only relevant files and create a focused conventional commit message.
7. If there are no local changes, continue without creating a commit.

### Phase 2: Push

1. Push the current branch to `origin`.
2. If upstream tracking is missing, push with `-u`.
3. If a pre-push hook fails on your own changes, fix the issue and push again.
4. If a pre-push hook fails only because of unrelated pre-existing breakage, push with `--no-verify` and record that explicitly in the PR body.
5. After every later fix commit in the babysit loop, push again. Do not stop at a local commit.

### Phase 3: Open or Reuse the PR

1. Verify remotes with `git remote -v` and confirm `upstream` points at `tinyhumansai/openhuman`.
2. Check for an existing PR for the exact branch:
   - `gh pr list --repo tinyhumansai/openhuman --head <fork-owner>:<branch> --state open --json number,url`
3. If a PR exists, capture its number and URL and reuse it.
4. If no PR exists:
   - inspect `git log main..HEAD` and `git diff main...HEAD`
   - fill `.github/PULL_REQUEST_TEMPLATE.md` exactly
   - create the PR against `tinyhumansai/openhuman:main` with `--head <fork-owner>:<branch>`
5. Print the PR URL to the user.

### Phase 4: Babysit Loop

Run an explicit poll loop until the PR is green and clean. Do not treat this as a one-shot status check.

- Poll about every 5 minutes.
- Stay in the loop for up to 12 ticks, about 60 minutes total.
- If the environment does not support durable wakeups, remain in-session and use repeated polling with `sleep 270`.
- On each tick, post a short progress update to the user.

Each tick:

1. Fetch CI status:
   - `gh pr checks <pr-number> --repo tinyhumansai/openhuman --json name,state,link,description`
2. Treat `PENDING` as still in progress. Do not claim success while checks are still running.
3. If any check is `FAILURE` or `CANCELLED`:
   - if the `link` is a GitHub Actions run URL, extract the run id and inspect failing logs with `gh run view <id> --log-failed --repo tinyhumansai/openhuman`
   - otherwise work from the check name, state, and description
   - make the smallest correct fix
   - rerun targeted validation
   - commit
   - push
4. Fetch PR review comments:
   - `gh api repos/tinyhumansai/openhuman/pulls/<pr-number>/comments --paginate`
5. Fetch issue-level PR comments:
   - `gh api repos/tinyhumansai/openhuman/issues/<pr-number>/comments --paginate`
6. Inspect review threads via GraphQL, not just flat comments, so unresolved discussions do not slip through:
   - query `reviewThreads` with pagination until `hasNextPage` is false
7. Specifically inspect bot feedback from `coderabbitai` and `coderabbitai[bot]`, but also check for human actionable review comments.
8. For each actionable review comment or unresolved review thread:
   - read the referenced file and line
   - apply the smallest correct fix
   - rerun targeted validation
   - commit
   - push
9. For incorrect, stale, or out-of-scope review feedback:
   - reply in the existing review thread with concrete reasoning
   - do not open a new unrelated review
   - resolve or dismiss only when the reasoning is explicit and the platform supports it
10. After addressing a review thread, resolve it through the GitHub review-thread API when appropriate.
11. Track whether new issue-level CodeRabbit comments appeared since the previous tick so the loop does not exit while fresh bot feedback is waiting.
12. Exit the loop only when all of these are true:
   - all required checks are `SUCCESS`
   - no unresolved actionable review threads remain
   - no new actionable CodeRabbit issue comments remain
   - the latest fixes are committed and pushed to the PR branch

If the loop reaches the hard cap, stop and report the PR URL, current CI snapshot, and any unresolved review threads or comments.

## Useful Checks

- `pnpm typecheck`
- `pnpm lint`
- `pnpm format:check`
- `pnpm test:unit`
- `cargo check --manifest-path Cargo.toml`
- `cargo check --manifest-path app/src-tauri/Cargo.toml`
- `pnpm test:rust`

Prefer targeted test commands when the touched area is narrow, but do not claim validation passed if a command was not run.

## Notes

- Do not merge the PR unless the user explicitly asks.
- Reuse an existing PR when one already exists for the branch.
- Always push follow-up commits so the PR actually updates after fixes.
- If invoked from `main`, branch first, then ship. Do not make the user clean up agent commits from `main`.
- Checking `gh pr checks --watch` once is not sufficient babysitting. The skill should actively re-poll CI and review surfaces until the exit condition is met.
- Review handling must include:
  - PR review comments
  - issue-level PR comments
  - unresolved review threads
- If CI or review surfaces reveal unrelated pre-existing breakage, call it out clearly and avoid masking it as fixed.
- If GitHub auth, remotes, or branch protection do not allow the workflow, report the exact blocker and stop at the first blocked step.

## Invocation Hints

- `Use $ship-and-babysit for this branch`
- `Ship this and babysit the PR`
- `Open the PR and stay on CI until it is green`