docs(skill): make ship-and-babysit proactive (#2581)

.codex/skills/ship-and-babysit/SKILL.md

@@ -10,7 +10,8 @@ Use this skill for `tinyhumansai/openhuman` when the user wants a branch shipped
 - 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
+- proactively run likely merge-gate validation and start fixing issues immediately
+- monitor CI and review feedback in a polling loop without waiting idly for every check to finish
 - address actionable review comments and push follow-up fixes
 - stop only when the PR is green and clean
 
@@ -27,6 +28,8 @@ Use this skill for `tinyhumansai/openhuman` when the user wants a branch shipped
 - 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.
+- Default to autonomous execution. Do not stop to ask the user process questions when a reasonable safe default exists.
+- Only ask the user a question when the workflow is genuinely blocked by missing access, missing credentials, or an irreversible choice that cannot be inferred from repo context.
 
 ## Workflow
 
@@ -41,7 +44,7 @@ Use this skill for `tinyhumansai/openhuman` when the user wants a branch shipped
    - `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.
+   - If the name does not follow convention and it is already a non-`main` branch, keep using it unless it is still local and trivially safe to rename without disrupting 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.
@@ -66,48 +69,62 @@ Use this skill for `tinyhumansai/openhuman` when the user wants a branch shipped
    - 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.
+6. Immediately after opening or reusing the PR, start proactive validation based on the touched area instead of waiting for remote CI to finish:
+   - run the smallest set of likely merge-gate commands that cover the changed code
+   - prioritize fast failure detectors first, such as format, typecheck, lint, targeted tests, and cargo checks relevant to touched files
+   - fix locally discovered failures right away, then commit and push again before the next CI poll
 
 ### 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.
+Run an explicit poll loop until the PR is green and clean. Do not treat this as a one-shot status check, and do not sit idle waiting for all checks to complete before acting.
 
 - 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.
+- Between ticks, prefer useful work over passive waiting:
+  - inspect completed failures as soon as they appear
+  - inspect review comments and unresolved threads immediately
+  - run likely local validations on changed areas while remote checks are still pending
+  - push fixes as soon as they are ready instead of batching them behind the full CI timeline
 
 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`:
+3. If any completed 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:
+4. If checks are still mostly `PENDING`, do not wait for the whole matrix to finish before taking action:
+   - inspect the changed files and recent commit diff
+   - run the most relevant local merge-gate commands proactively
+   - fix any locally reproduced failure immediately
+   - commit and push as soon as the fix is validated
+5. Fetch PR review comments:
    - `gh api repos/tinyhumansai/openhuman/pulls/<pr-number>/comments --paginate`
-5. Fetch issue-level PR comments:
+6. 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:
+7. 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:
+8. Specifically inspect bot feedback from `coderabbitai` and `coderabbitai[bot]`, but also check for human actionable review comments.
+9. 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:
+10. 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:
+11. After addressing a review thread, resolve it through the GitHub review-thread API when appropriate.
+12. Track whether new issue-level CodeRabbit comments appeared since the previous tick so the loop does not exit while fresh bot feedback is waiting.
+13. 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
@@ -134,6 +151,8 @@ Prefer targeted test commands when the touched area is narrow, but do not claim
 - 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.
+- The skill should not ask the user for confirmation about routine workflow choices such as branch naming, whether to start fixing CI, or whether to act on obvious actionable failures.
+- The skill should assume the user wants active babysitting: inspect, fix, commit, and push continuously until blocked or green.
 - Review handling must include:
   - PR review comments
   - issue-level PR comments