diff --git a/.codex/skills/ship-and-babysit/SKILL.md b/.codex/skills/ship-and-babysit/SKILL.md index 3d91336cc..930352155 100644 --- a/.codex/skills/ship-and-babysit/SKILL.md +++ b/.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 :` 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 --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 --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//comments --paginate` -5. Fetch issue-level PR comments: +6. Fetch issue-level PR comments: - `gh api repos/tinyhumansai/openhuman/issues//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