Gap
mcp__pare-github__pr-checks returns a point-in-time snapshot of a PR's check runs. There's no way to block until the checks reach a terminal state, which is the core need when driving a PR to green before merging.
gh has this (gh pr checks <n> --watch --interval 30, which exits 0 on all-pass / non-zero on failure), but we can't shell out to it — the repo's hooks block gh pr ... and steer to the pare tools, and the pare tools are the dogfood path anyway. Today the workaround is a background sleep N then re-poll pr-checks, which is clumsy and imprecise (you either over-sleep or poll too early).
Request
Add a wait/watch mode to pr-checks (or a sibling tool, e.g. pr-checks-wait):
wait: true (or watch: true) — poll until every check reaches a terminal bucket (pass/fail/skip/cancel), then return the final snapshot.pollIntervalMs — default ~30000 (GitHub rate limits).timeoutMs — bound the wait; on timeout return the latest snapshot with a timedOut: true flag rather than hanging.- Return shape: same as
pr-checks today plus a top-level conclusion ("passed" | "failed" | "timed_out") so the caller can branch without re-deriving from the buckets.
Use case
The driving loop is: open PR → wait for CI → merge if green / fix if red. Without a wait mode the agent has to hand-roll a background sleep + re-poll cycle every time. A first-class wait mode makes "drive this PR to green" a single call.
Notes
- Mirroring
gh pr checks --watch semantics (exit/conclusion reflects pass vs fail) would make the mapping obvious.
- A
requiredOnly: true option (wait only on required checks) would be a nice follow-up but isn't essential for v1.
Filed from a Chipzen session that hit this while driving PR chipzen-ai/Chipzen#3108 to merge.
Gap
mcp__pare-github__pr-checksreturns a point-in-time snapshot of a PR's check runs. There's no way to block until the checks reach a terminal state, which is the core need when driving a PR to green before merging.ghhas this (gh pr checks <n> --watch --interval 30, which exits 0 on all-pass / non-zero on failure), but we can't shell out to it — the repo's hooks blockgh pr ...and steer to the pare tools, and the pare tools are the dogfood path anyway. Today the workaround is a backgroundsleep Nthen re-pollpr-checks, which is clumsy and imprecise (you either over-sleep or poll too early).Request
Add a wait/watch mode to
pr-checks(or a sibling tool, e.g.pr-checks-wait):wait: true(orwatch: true) — poll until every check reaches a terminal bucket (pass/fail/skip/cancel), then return the final snapshot.pollIntervalMs— default ~30000 (GitHub rate limits).timeoutMs— bound the wait; on timeout return the latest snapshot with atimedOut: trueflag rather than hanging.pr-checkstoday plus a top-levelconclusion("passed" | "failed" | "timed_out") so the caller can branch without re-deriving from the buckets.Use case
The driving loop is: open PR → wait for CI → merge if green / fix if red. Without a wait mode the agent has to hand-roll a background sleep + re-poll cycle every time. A first-class wait mode makes "drive this PR to green" a single call.
Notes
gh pr checks --watchsemantics (exit/conclusion reflects pass vs fail) would make the mapping obvious.requiredOnly: trueoption (wait only on required checks) would be a nice follow-up but isn't essential for v1.Filed from a Chipzen session that hit this while driving PR chipzen-ai/Chipzen#3108 to merge.