TL;DR: Stop waiting on CI with one long blocking call. Poll the combined status of the head commit on a bounded schedule (short interval, hard max wait), and when the max wait expires, post the review anyway with a note that checks are still pending - or park a draft and retry later. Bounded polling plus a fallback action means the review always lands instead of dying in a timeout.

```text
code review agent timed out waiting for CI status checks before posting review
```

1. Fetch the combined status for the PR's head commit once, with a short request timeout. Record which checks are pending, which passed, and which failed.
   Expected: a list like "3 passed, 1 failed, 2 pending" instead of an open-ended wait.
2. Replace any single long wait with bounded polling: check status every 30 seconds, up to a hard cap of about 10 minutes.
   Expected: the loop exits on its own at the cap even if checks never finish.
3. Decide the on-timeout policy up front and encode it. Option A: post the review with a visible "CI still pending at review time" note. Option B: save the review as a draft, mark the PR as "review drafted, checks pending", and let a follow-up run submit it when checks complete.
   Expected: no code path ends in an unhandled timeout; the review is either posted or safely parked.
4. Record the outcome in the agent's per-PR state: review posted or draft parked, plus which checks were still pending.
   Expected: a follow-up run can pick up exactly where the timed-out run stopped.
5. If you chose the draft policy, add a lightweight recheck job that wakes when the pending checks finish and submits the parked review.
   Expected: the review goes out within minutes of CI completing, without a human nudge.
6. Re-run against a PR with a slow check suite and watch the timeline.
   Expected: the review posts (or parks) at the bounded wait limit, never hanging past it.

## Use this when
- The review run stalls while checks are pending and eventually times out
- The agent log shows repeated status polls with no exit condition
- Reviews arrive hours late because one slow check held up the whole run
- You want reviews posted even when CI is still running

## Not for this skill when
- Checks are failing, not pending (that is a code problem, not a waiting problem)
- The timeout is on fetching the diff or posting comments, not on check status
- A required status check never reports at all because the workflow is misconfigured (fix the workflow, see the actionlint/yamllint skills)
- The agent is rate limited on the status API rather than waiting on check results

## Variant phrasings
- "review agent waits forever for checks to finish"
- "agent blocked on pending status checks before review"
- "CI checks pending, review never posted"
- "how long should a review bot wait for CI"

## Why it happens
Review agents are usually written as a straight-line script: fetch diff, wait for CI, analyze, post. The "wait for CI" step has no deadline because the author assumed checks finish in minutes. On a busy repo a queued workflow or a flaky required check can sit pending for an hour, and the single blocking wait eats the whole run budget. Bounded polling with a fallback turns an assumption into a contract.

## Edge cases
- A check that is "pending" because its workflow file has a syntax error will never complete. Cap the wait, then flag the broken workflow instead of parking the review forever.
- Posting a review while required checks are still pending can confuse branch protection messaging. The pending note in the review body keeps humans oriented.
- If the repo requires checks to pass before merge, a review posted early is advisory only. Say so in the review so nobody treats it as a merge signal.
- Draft parking needs a durable store. A draft kept only in the timed-out run's memory is lost when the run dies.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HZF6Dnh4tWfGlqwXewAqGQ