From b2e8a6bfba6d39a1fa011612c94115a01e41d822 Mon Sep 17 00:00:00 2001 From: Darren Cheng Date: Wed, 24 Jun 2026 00:02:10 -0700 Subject: [PATCH 1/2] docs(pr): add slow-check probe + AI re-reviewer churn tips MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two additive doc improvements to the /pr skill loop (no control-flow change): - Step 4a: add a check-runs status probe to distinguish a genuinely-running slow CI check (in_progress + real started_at) from a stuck/queued one (queued >3min or no run), preventing both premature give-up and silent infinite waits. - Step 4c: note that AI re-reviewers (CodeRabbit, claude-review/robothanx CI jobs) re-review on every push and surface new incremental findings; expect 2-4 cycles to converge and don't treat a new finding after a clean round as loop-stuck — the "same failure 3+ times" guard targets recurring findings. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude --- agents/skills/pr/SKILL.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/agents/skills/pr/SKILL.md b/agents/skills/pr/SKILL.md index 08fccd34..b0c735f6 100644 --- a/agents/skills/pr/SKILL.md +++ b/agents/skills/pr/SKILL.md @@ -171,6 +171,17 @@ gh pr view --repo --json mergeStateStatus,mergeable Then use `gh pr checks --repo ` to see the current state of all checks. - If checks are still running, poll `gh pr checks` with exponential backoff: wait 60s, then 120s, then 240s, capping at 300s between polls. Stop after 30 minutes total and report to the user. +- **Distinguish a genuinely-running slow check from a stuck/queued one** before either continuing to wait or declaring it stuck. A required check on a slow repo (a 10-minute build-test, for example) is easy to mistake for a wedged workflow. Probe the underlying check-run status for the head commit: + + ``` + gh api repos///commits//check-runs \ + --jq '.check_runs[] | select(.name|test("";"i")) | {name, status, started_at}' + ``` + + - `status: "in_progress"` with a real `started_at` = genuinely running. Keep waiting (continue the backoff) — this is normal for slow checks, not a stall. + - `status: "queued"` for more than ~3 minutes, or no matching run at all = the check is stuck or was never scheduled. Surface this to the user rather than polling silently. + + This prevents both premature give-up on a slow-but-healthy check and a silent infinite wait on one that will never start. - If `gh pr checks` reports "no checks reported" for 3+ minutes **and** `mergeStateStatus` is not DIRTY, the workflow may be misconfigured, paused, or require approval — surface this to the user rather than continuing to poll silently. - If all checks pass, proceed to 4c to check for unresolved review threads. Only go to Step 5 when CI is green **and** 4c confirms zero unresolved threads. - If any checks have failed, proceed to 4b immediately — do not wait. @@ -248,6 +259,8 @@ gh api graphql -f query=' **After addressing all threads:** if any code changes were made, stage, commit, and push them before looping back. +**Expect AI re-reviewers to re-review on every push.** Tools like CodeRabbit and CI-based reviewers (a `claude-review`/`robothanx`-style job) re-run on each new commit, and each pushed fix frequently surfaces NEW incremental findings — often 2nd-order effects of the fix you just made (e.g., adding a call inside a signal handler prompts the next review to flag that call's missing timeout). This is normal: expect 2-4 cycles to converge, and do not treat a fresh finding after an otherwise-clean round as the loop being stuck. The "stuck (same failure 3+ times)" guard in Step 4d applies to the SAME finding recurring after you tried to fix it — genuinely-new findings each round are progress, not churn. + #### 4d: Loop back to 4a After pushing fixes or addressing comments, loop back to wait for CI again. Continue until CI is fully green and no unresolved comments remain. From ef8a77a1b4ee9d70d198ae51bd842b3dc95737a2 Mon Sep 17 00:00:00 2001 From: Darren Cheng Date: Wed, 24 Jun 2026 00:03:42 -0700 Subject: [PATCH 2/2] docs(pr): tighten slow-check probe per review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Address review findings on the Step 4a check-runs probe: - note the placeholder must match the exact gh pr checks name (a typo yields a false "no run") - make the queued threshold measurable via created_at instead of an unanchored "~3 minutes" 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude --- agents/skills/pr/SKILL.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/agents/skills/pr/SKILL.md b/agents/skills/pr/SKILL.md index b0c735f6..b087a9b8 100644 --- a/agents/skills/pr/SKILL.md +++ b/agents/skills/pr/SKILL.md @@ -175,11 +175,13 @@ Then use `gh pr checks --repo ` to see the current state of ``` gh api repos///commits//check-runs \ - --jq '.check_runs[] | select(.name|test("";"i")) | {name, status, started_at}' + --jq '.check_runs[] | select(.name|test("";"i")) | {name, status, started_at, created_at}' ``` + Replace `` with the exact check name from the `gh pr checks` output above — a typo in the filter returns "no run" even when the check is healthy, so confirm the name first. + - `status: "in_progress"` with a real `started_at` = genuinely running. Keep waiting (continue the backoff) — this is normal for slow checks, not a stall. - - `status: "queued"` for more than ~3 minutes, or no matching run at all = the check is stuck or was never scheduled. Surface this to the user rather than polling silently. + - `status: "queued"` with `created_at` more than ~3 minutes in the past, or no matching run at all (after confirming the name is right) = the check is stuck or was never scheduled. Surface this to the user rather than polling silently. This prevents both premature give-up on a slow-but-healthy check and a silent infinite wait on one that will never start. - If `gh pr checks` reports "no checks reported" for 3+ minutes **and** `mergeStateStatus` is not DIRTY, the workflow may be misconfigured, paused, or require approval — surface this to the user rather than continuing to poll silently.