Ship And Babysit

---
description: Commit, push to origin (fork), open PR to tinyhumansai/openhuman:main, then poll every ~5min for CodeRabbit comments and CI failures, resolve them, and exit when clean.
allowed-tools: Bash, Read, Edit, Write, Agent, Skill
---

You are running an end-to-end ship-and-babysit flow for the **openhuman** repo. Follow these phases in order. Be concise in user-facing text — one short sentence per phase transition is enough.

Repo facts (from `CLAUDE.md`):

- Upstream: `tinyhumansai/openhuman` (not a fork). PRs target **`main`**.
- Push branches to **`origin`** (the user's own fork of `tinyhumansai/openhuman`). Treat `upstream` as fetch-only.
- PRs are opened with `--head <fork-owner>:<branch>` against `tinyhumansai/openhuman:main`.
- PR template: `.github/PULL_REQUEST_TEMPLATE.md`. Issue templates under `.github/ISSUE_TEMPLATE/`.
- Feature work requires matching E2E coverage before shipping.

**Resolve the fork owner once at the start** and reuse it for the rest of the flow:

```bash
FORK_OWNER=$(git remote get-url origin | sed -E 's#.*[:/]([^/]+)/[^/]+(\.git)?$#\1#')

The flow is fork-only: origin must be the user's fork. If origin resolves to tinyhumansai (the upstream org), stop and ask the user to add a fork remote — never push branches to the upstream repo.

Phase 1 — Commit

1. Run git status, git diff (staged + unstaged), and recent git log in parallel to understand pending changes and the repo's commit message style.
2. If there are no changes to commit AND the branch is already pushed AND a PR already exists, skip to Phase 4.
3. If there are uncommitted changes, stage relevant files (avoid secrets / large binaries / .env), then create a commit using a conventional prefix (feat:, fix:, refactor:, chore:, docs:, test:). Use a HEREDOC for the message.
4. Never use --no-verify to bypass commit hooks for your own changes. If a hook fails on your changes, fix the underlying issue and create a NEW commit (do not amend pushed commits).

Feature E2E rule

• Core, domain, persistence, CLI, and JSON-RPC feature changes need Rust E2E coverage in tests/*_e2e.rs; new or changed RPC surfaces usually belong in tests/json_rpc_e2e.rs.
• Frontend user flows need Playwright E2E coverage in app/test/e2e/specs/*.spec.ts.
• Mock backend calls all the way through with scripts/mock-api-server.mjs, scripts/mock-api/*, or app/test/e2e/mock-server.ts; do not hit real backend services or third-party APIs in E2E.
• Use focused commands when possible:
  • pnpm test:rust:e2e -- --suite <suite>
  • pnpm --filter openhuman-app test:e2e:web:build
  • bash app/scripts/e2e-web-session.sh test/e2e/specs/<spec>.spec.ts
• Unit tests still matter for narrow logic, but they do not replace E2E coverage for newly built features.

Phase 2 — Push

1. Determine current branch with git rev-parse --abbrev-ref HEAD. Confirm it follows the feat/|fix/|refactor/|chore/|docs/|test/ prefix convention. Never push directly to main. If the branch doesn't match the convention, stop and ask the user to either rename it or confirm the deviation — don't auto-rename pushed branches.
2. Push to origin with -u if upstream tracking is missing. Never push to upstream. Never force-push to main.
3. Pre-push hook policy (per CLAUDE.md): if a pre-push hook fails on something unrelated to your changes (pre-existing breakage on main in code you didn't touch), push with --no-verify and call it out in the PR body. If the hook fails on your own changes, fix and re-push. Don't ask — just do the right thing and tell the user what you did.

Phase 3 — Open PR

1. Verify upstream remote with git remote -v. It should point at tinyhumansai/openhuman. If missing, ask the user before adding it.
2. Check whether a PR already exists for this branch: gh pr list --repo tinyhumansai/openhuman --head <fork-owner>:<branch> --state open --json number,url
   • If a PR exists, capture its number and url, print the URL, skip steps 3–5, and proceed straight to Phase 4 with that PR#.
3. If none exists, draft a title (<70 chars) and a body that follows .github/PULL_REQUEST_TEMPLATE.md exactly. Inspect commits with git log main..HEAD and the diff with git diff main...HEAD to write the summary. If you bypassed a pre-push hook, note it in the PR body.
   • When filling the Submission Checklist, every item must be checked. Use - [x] N/A: <reason> when an item does not apply; unchecked N/A items still fail scripts/check-pr-checklist.mjs.
4. Create the PR:

   gh pr create --repo tinyhumansai/openhuman --base main --head <fork-owner>:<branch> \
     --title "..." --body "$(cat <<'EOF'
   ...template-filled body...
   EOF
   )"
   

5. Add appropriate labels/type if conventional for this repo.
6. Capture the PR number and URL — you will need them in Phase 4. Print the URL to the user.

Phase 4 — Babysit loop (~5 minutes)

Repeat the following loop until the exit condition is met. Use ScheduleWakeup to pace at 270s (stays inside the prompt-cache window) — re-enter this phase each tick by passing the same /ship-and-babysit invocation back as the prompt.

Hard cap: 12 ticks (~60 minutes). After that, stop the loop and ask the user, including PR URL, current CI snapshot, and any unresolved CodeRabbit threads. Maintain an explicit tickCount that increments by 1 on every loop entry (regardless of whether you commit or only wait on CI), and pass it through in the ScheduleWakeup reason (e.g. "tick 5/12: waiting on CI for PR #1115") so the counter is visible across ticks and can't drift if a tick produces no commits.

Each tick:

1. Fetch CI status: gh pr checks <PR#> --repo tinyhumansai/openhuman --json name,state,link,description
   • gh pr checks --json returns a link field (an Actions URL like …/actions/runs/<id>/job/<jobId>), not a run id directly. Extract the run id with a regex that's robust to trailing s