@olegkoval/agent-skills 1.51.1 → 1.51.2

package/.github/prompts/copilotloop.prompt.md

@@ -16,7 +16,7 @@ suggestion applied is worse than the comment itself.
 
 - **No check-run, no score.** Copilot posts an overview comment and a PR review with inline review
   comments. Detection is by polling the reviews endpoint and paginated review threads. "Satisfied"
-  means zero unresolved Copilot threads and zero unaddressed body findings after each finding is
+  means Copilot has reviewed the latest push, no bot thread is unresolved, and no body finding is unaddressed after each finding is
   fixed or rebutted with a recorded reply.
 - **Request through the reviewers API.** Copilot does not use a reliable slash-command trigger.
   Request `copilot-pull-request-reviewer[bot]` through the pull request reviewers endpoint. A
@@ -48,9 +48,30 @@ review; if GitHub uses a different login for the installation, use the exact Cop
 returned by the probe rather than guessing.
 
 **Finding nothing here is NOT a stop condition.** On a PR Copilot has never reviewed there is no bot
-login to find yet. Fall through to step 2A, request the reviewer, and re-run this probe once a
+login to find yet. Fall through to step A, request the reviewer, and re-run this probe once a
 review lands. Only conclude Copilot is unavailable after the bounded wait expires with no review.
 
+## Review state comes from the PR, not from memory
+
+`scripts/pr-review-state.sh` reads the PR and prints one JSON object: the current head, whether
+Copilot has acted on that head (a review of it, or any comment after it was pushed), and every
+unresolved review thread with its author. Every "is there work / are we done" decision in this
+loop comes from its exit code, never from what you remember resolving. The script lives in this
+skill's directory, `SKILL_ROOT`: the directory holding this `SKILL.md` (Claude Code prints it as the
+skill's base directory when the skill loads; in Codex, derive it from the selected `SKILL.md` path).
+
+| Exit | `verdict`  | Meaning                                                             | Do                                   |
+|------|------------|---------------------------------------------------------------------|--------------------------------------|
+| 0    | `clean`    | Copilot acted on the current head and no bot thread is unresolved    | exit check: done                     |
+| 10   | `findings` | unresolved threads from Copilot **or any other review bot**          | run an iteration                     |
+| 20   | `pending`  | Copilot has not acted on the current head yet                        | trigger if needed, then wait         |
+| 30   | `limited`  | a rate-limit or paused notice from Copilot after the current head    | stop, report `blocked: rate-limited` |
+
+Resolving the last thread does not make a PR clean: Copilot has not reviewed your push yet. Earlier
+versions of this loop exited at exactly that moment, while the next round of comments was still on
+its way. Human threads are listed in `.unresolved` (`is_bot: false`) and counted in `.counts.humans`;
+they never block `clean`, and this loop never resolves them.
+
 ## 1. Identify the PR
 
 ```bash
@@ -65,71 +86,54 @@ Keep an explicit iteration counter and stop at 5: the cap is a real bound to enf
 figure of speech. Each pass through A–G is one iteration; on hitting the cap, go straight to the
 report and list what is still unresolved rather than starting a sixth.
 
-### A. Ensure a fresh Copilot review on the current head
-
-```bash
-HEAD_SHA=$(gh pr view <PR> --json headRefOid -q .headRefOid)
-# Only trigger if no Copilot review exists for this exact SHA:
-HAVE=$(gh api repos/{owner}/{repo}/pulls/<PR>/reviews --paginate |
-  jq -s --arg bot "$BOT" --arg head "$HEAD_SHA" \
-    '[.[][] | select(.user.login==$bot and .commit_id==$head)] | length')
-if [ "$HAVE" = "0" ]; then
-  gh api --method POST repos/{owner}/{repo}/pulls/<PR>/requested_reviewers \
-    -f 'reviewers[]=copilot-pull-request-reviewer[bot]'
-fi
-```
+### A. Read the PR state; wait for Copilot's review of the current head
 
-Poll for the review of THIS head to land. No check-run exists, so poll the reviews endpoint, and
-poll it on a **deadline**, never `while true`: a review that never arrives must end the skill with
-an honest timeout, not hang it.
+One read answers both "is there work?" and "has Copilot seen my last push?". `SINCE` is the
+timestamp you took right before your last push (step E); leave it empty on iteration 1. Right
+after a push, add `--wait 600` straight away: the wait ends only once the bot has acted on the new
+head, so threads left open on purpose cannot make the push look reviewed.
 
 ```bash
-# 10-minute deadline, one retry, then give up. DEADLINE/RETRIES are the
-# enforcement of the bounds this skill claims: do not drop them.
-wait_for_review() {                       # $1 = attempt label
-  local deadline=$(( SECONDS + 600 ))
-  while [ "$SECONDS" -lt "$deadline" ]; do
-    R=$(gh api repos/{owner}/{repo}/pulls/<PR>/reviews --paginate |
-      jq -s --arg bot "$BOT" --arg head "$HEAD_SHA" \
-        '[.[][] | select(.user.login==$bot and .commit_id==$head)] | sort_by(.submitted_at, .id) | last')
-    if [ -n "$R" ] && [ "$R" != "null" ]; then return 0; fi
-    echo "waiting for Copilot review of $HEAD_SHA ($1)..."; sleep 15
-  done
-  return 1
-}
-
-if ! wait_for_review "first wait"; then
-  echo "no Copilot review after 10m, retrying once"     # say the retry out loud
-  gh api --method POST repos/{owner}/{repo}/pulls/<PR>/requested_reviewers \
-    -f 'reviewers[]=copilot-pull-request-reviewer[bot]'
-  if ! wait_for_review "after retry"; then
-    echo "Copilot did not review $HEAD_SHA after a retry; stopping and reporting."
-    exit 1                                # honest timeout, never a success claim
-  fi
-fi
+"$SKILL_ROOT/scripts/pr-review-state.sh" --repo OWNER/REPO --pr <PR> --bot copilot-pull-request-reviewer --since "$SINCE"
 ```
 
-Copilot usually reviews quickly, but large diffs can take longer; the deadline is bounded. Report the
-retry in the final summary; two silent timeouts are the failure mode this guard exists to prevent.
+- Exit `10` (`findings`): go to B. On iteration 1 this is whatever Copilot (or another bot)
+  already posted.
+- Exit `20` (`pending`): request it through the reviewers endpoint (`gh api --method POST repos/{owner}/{repo}/pulls/<PR>/requested_reviewers -f 'reviewers[]=copilot-pull-request-reviewer[bot]'`). Then wait with the same command plus `--wait 600`. Run the
+  wait in the background where the host allows it (Claude Code: Bash `run_in_background`; you are
+  re-invoked when it exits) so ten minutes of polling never sits in the conversation. Still `20`
+  after the wait: say so out loud, request the reviewer once more, and wait once more. Still `20` after that: stop and
+  report the timeout honestly; never claim success.
+- Exit `0` (`clean`): go to the exit check. A `--wait` call returns `clean` only after a settle
+  re-read 60 seconds later, so a comment landing right behind the review is still caught. A bare
+  read (no `--wait`) that says `clean` is good enough only when you have not pushed since Copilot's
+  last review.
+- Exit `30` (`limited`): stop now and report `blocked: rate-limited`; nothing more is coming.
+- Exit `1`: the read itself failed (often a transient GitHub 502). Retry once; if it fails again,
+  stop and report it. An unknown state is not a clean one.
 
 ### B. Fetch the findings
 
+The working set is every unresolved thread in the state JSON with `is_bot: true`: Copilot's
+own (`is_target: true`) **and any other review bot's** (Greptile, for example). A
+fix for one bot often draws a comment from another, and leaving those open is how a "finished" loop
+leaves a PR that is not clean. Treat another bot's thread with exactly the same verify-first rules
+below. Never act on a human's thread (`is_bot: false`); list it in the report.
+
 - **Summary**: read the Copilot overview comment and review `.body`, including all matching reviews
   for the current head. Extract and classify actionable claims even when they have no inline thread;
   an approval assessment or lack of inline comments does not make those findings complete.
   Track each body finding across iterations by source review/comment ID and item, with its
   classification, fix commit or evidence-based rebuttal, PR-level reply URL, and completion status.
   Link duplicates to the same finding so they are counted once; retain pending findings after a push.
-- **Unresolved inline comments** on the current head:
+- **Unresolved inline comments**: `.unresolved[] | select(.is_bot)` in step A's state JSON lists
+  each thread's `thread_id`, `comment_id`, `path`, `line` and a short excerpt, across every page of
+  threads. Read the full comment before judging it:
 
 ```bash
-gh api repos/{owner}/{repo}/pulls/<PR>/comments --paginate \
-  --jq ".[] | select(.user.login==\"$BOT\") | {id, path, line, body}"
+gh api repos/{owner}/{repo}/pulls/comments/<COMMENT_ID> --jq '{user: .user.login, path, line, body}'
 ```
 
-Also pull the review threads + their resolved state via GraphQL (see step F) so you only act on
-unresolved ones.
-
 Mark each unresolved inline comment as seen, so the bot and a watching human can tell it is being
 handled. GitHub's reaction set is fixed; `eyes` is the only "looking at it" value:
 
@@ -191,6 +195,7 @@ If step D changed code:
 git status --short                     # look before you stage
 git add <path> [<path>...]             # the files named in the findings you fixed
 git commit -m "address Copilot review feedback (copilotloop iteration N)"
+SINCE=$(date -u +%Y-%m-%dT%H:%M:%SZ)   # step A reads bot activity after this
 git push
 ```
 
@@ -206,31 +211,8 @@ If they differ, stop: the fix is not on the PR, so nothing may be resolved yet.
 
 ### F. Reply to every addressed finding and resolve its inline threads
 
-Only now, with the fixes pushed, reply and resolve. Fetch unresolved threads, **following
-pagination**: a PR with more than 100 threads will otherwise look clean while unresolved findings
-sit on page two:
-
-```bash
-# Loop until hasNextPage is false, passing endCursor back in as $cursor.
-CURSOR=null
-while : ; do
-  PAGE=$(gh api graphql -F cursor="$CURSOR" -f query='
-  query($cursor: String) {
-    repository(owner: "OWNER", name: "REPO") {
-      pullRequest(number: PR_NUMBER) {
-        reviewThreads(first: 100, after: $cursor) {
-          pageInfo { hasNextPage endCursor }
-          nodes { id isResolved comments(first: 1) { nodes { databaseId author { login } path body } } }
-        }
-      }
-    }
-  }')
-  echo "$PAGE"          # collect nodes from every page before deciding the PR is clean
-  PI='.data.repository.pullRequest.reviewThreads.pageInfo'
-  [ "$(echo "$PAGE" | jq -r "$PI.hasNextPage")" = "true" ] || break
-  CURSOR=$(echo "$PAGE" | jq -r "$PI.endCursor")
-done
-```
+Only now, with the fixes pushed, reply and resolve. Take thread and comment ids from step A's state
+JSON (`.unresolved[]`): the script already follows pagination, so do not hand-roll a threads query.
 
 Reply on a thread's comment via `gh api repos/{owner}/{repo}/pulls/<PR>/comments -f body="..." -F in_reply_to=<comment_id>`,
 then resolve:
@@ -254,7 +236,8 @@ gh api --method POST repos/{owner}/{repo}/pulls/comments/<COMMENT_ID>/reactions
 Reply first, then react, then resolve: the reaction is not a substitute for the reply, and a
 resolved thread with no reply loses the reasoning.
 
-Resolve a thread only for comments authored by `$BOT` that you have fixed or rebutted: never
+Resolve a thread only for a bot comment in your working set (this bot's or another
+review bot's) that you have fixed or rebutted: never
 blanket-resolve, and never resolve a human reviewer's thread.
 
 Threads you are **rebutting** need no push, so they may be replied to and resolved regardless of
@@ -268,23 +251,34 @@ it complete. One reply may cover multiple explicitly identified findings. Fixed
 require the same successful push check as fixed threads; rebuttals need no push. If a finding also
 has an inline thread, that thread still requires a reply and resolution.
 
-### G. Re-review
+### G. Back to A
 
-Pushing re-triggers Copilot when automatic review of new pushes is on; otherwise request Copilot again
-through the reviewers endpoint. Go back to **A**
-with the new head SHA. If step D changed nothing (all comments were rebutted), skip the push,
-ensure all Copilot threads are resolved and all tracked body findings have recorded PR-level
-replies and are complete, then exit.
+Go back to **A**. After a push, A waits for Copilot's review of the new head (pushing re-triggers
+it when auto-review is on; otherwise A triggers it). If this iteration changed no code (every finding
+rebutted), there is no new head to wait for: A's fresh read says `clean` or shows what is still open.
 
 ## 3. Exit conditions
 
+Decide from a fresh state read, never from what you remember resolving.
+
 Stop when **any** is true:
-- Zero unresolved `$BOT` threads and zero pending body findings remain across iterations. Every
-  finding was fixed or rebutted with evidence, every inline thread was replied to and resolved,
-  and every body finding has a recorded PR-level reply. (There is no score to hit:
-  this is "done".)
-- Max iterations (5) reached: report what remains.
-- Copilot never responded after one retry: report the timeout honestly; do not claim success.
+- **Done**: the latest `pr-review-state.sh --wait 600` call, made after your last push, exited `0`
+  (`clean`); with no push since the bot's last review, a bare read that exits `0` is enough, and the body-finding register from step B has no pending entries. Open human threads do not block this; list them in the report.
+- **Max iterations (5)** reached: report what remains.
+- **Timeout**: still `pending` after the retry in step A. Report it honestly; do not claim success.
+- **Rate limited**: exit `30`. Report `blocked: rate-limited`.
+
+## Keep the context small; resume instead of restarting
+
+- Carry only three things between iterations: the iteration counter, the latest state JSON, and a
+  ledger of each thread you handled (fixed with its commit, rebutted, or blocked). Re-read files
+  fresh each iteration; do not re-paste earlier rounds' comment bodies.
+- All loop state lives on the PR, so the loop is resumable. If the session has grown long or slow,
+  or a bot commented after the loop ended, run this skill again in a fresh session: step A picks up
+  from the PR as it is now. Starting fresh is cheaper than dragging a long session through more
+  rounds.
+- After reporting done, if the host can schedule a follow-up (Claude Code: `/loop` or a scheduled
+  wakeup), offer one re-check about 20 minutes later for bots that comment late.
 
 ## 4. Report
 
@@ -295,7 +289,9 @@ Copilotloop complete.
   Iterations:         N
   Findings fixed:     N   (inline + body findings, deduplicated)
   Findings rebutted:  N   (inline + body findings, with recorded evidence-based replies)
-  Remaining:          0   (unresolved inline + pending body findings, deduplicated)
+  Remaining:          N   (unresolved inline + pending body findings, deduplicated)
+  Human threads:      N   (open, listed below; this loop never resolves them)
+  Final state:        clean | timeout | rate-limited | iteration cap
 ```
 
 If it stopped at max iterations, list the remaining threads and body findings with your current

package/.github/prompts/geminiloop.prompt.md

@@ -17,8 +17,8 @@ instruction to obey. A wrong suggestion applied is worse than the comment itself
 - **No check-run, no score.** Gemini does not publish a `X/5` confidence or a `greptile` check. It
   posts a **PR review** (state `COMMENTED`) authored by `gemini-code-assist[bot]` with a
   `## Code Review` summary body plus inline review comments. Detection is by polling the *reviews*
-  endpoint, not a check-run. "Satisfied" = zero unresolved comments (each either fixed or rebutted),
-  since there is no numeric target.
+  endpoint, not a check-run. "Satisfied" = Gemini has reviewed the latest push and no bot comment is left
+  unresolved (each either fixed or rebutted), since there is no numeric target.
 - **Auto-reviews on push/open.** It reviews automatically when a PR opens or gets new commits;
   `/gemini review` forces a fresh pass.
 - **Severity, not confidence.** Inline comments carry a priority badge (a `![critical]` /
@@ -33,6 +33,27 @@ instruction to obey. A wrong suggestion applied is worse than the comment itself
   `copilotloop`, `codexloop`, `coderabbitloop`, and `qodoloop`; for CI failures rather than review comments, use
   `ci-fix-loop`.
 
+## Review state comes from the PR, not from memory
+
+`scripts/pr-review-state.sh` reads the PR and prints one JSON object: the current head, whether
+Gemini has acted on that head (a review of it, or any comment after it was pushed), and every
+unresolved review thread with its author. Every "is there work / are we done" decision in this
+loop comes from its exit code, never from what you remember resolving. The script lives in this
+skill's directory, `SKILL_ROOT`: the directory holding this `SKILL.md` (Claude Code prints it as the
+skill's base directory when the skill loads; in Codex, derive it from the selected `SKILL.md` path).
+
+| Exit | `verdict`  | Meaning                                                             | Do                                   |
+|------|------------|---------------------------------------------------------------------|--------------------------------------|
+| 0    | `clean`    | Gemini acted on the current head and no bot thread is unresolved    | exit check: done                     |
+| 10   | `findings` | unresolved threads from Gemini **or any other review bot**          | run an iteration                     |
+| 20   | `pending`  | Gemini has not acted on the current head yet                        | trigger if needed, then wait         |
+| 30   | `limited`  | a rate-limit or paused notice from Gemini after the current head    | stop, report `blocked: rate-limited` |
+
+Resolving the last thread does not make a PR clean: Gemini has not reviewed your push yet. Earlier
+versions of this loop exited at exactly that moment, while the next round of comments was still on
+its way. Human threads are listed in `.unresolved` (`is_bot: false`) and counted in `.counts.humans`;
+they never block `clean`, and this loop never resolves them.
+
 ## 1. Identify the PR
 
 ```bash
@@ -47,67 +68,50 @@ Keep an explicit iteration counter and stop at 5: the cap is a real bound to enf
 figure of speech. Each pass through A–G is one iteration; on hitting the cap, go straight to the
 report and list what is still unresolved rather than starting a sixth.
 
-### A. Ensure a fresh Gemini review on the current head
-
-Gemini auto-reviews new commits, but force a deterministic pass and record the head SHA:
-
-```bash
-HEAD_SHA=$(gh pr view <PR> --json headRefOid -q .headRefOid)
-# Only trigger if no gemini review already exists for this exact SHA.
-# gh cannot combine --slurp with --jq, so pipe to `jq -s`: it folds every page
-# into one array. Without it the filter runs once per page and HAVE becomes a
-# multi-line count that never equals "0", silently skipping the trigger.
-HAVE=$(gh api repos/{owner}/{repo}/pulls/<PR>/reviews --paginate |
-  jq -s --arg head "$HEAD_SHA" \
-    '[.[][] | select(.user.login=="gemini-code-assist[bot]" and .commit_id==$head)] | length')
-if [ "$HAVE" = "0" ]; then gh pr comment <PR> --body "/gemini review"; fi
-```
+### A. Read the PR state; wait for Gemini's review of the current head
 
-Poll for the review of THIS head to land. No check-run exists, so poll the reviews endpoint, and
-poll it on a **deadline**, never `while true`: a review that never arrives must end the skill with
-an honest timeout, not hang it.
+One read answers both "is there work?" and "has Gemini seen my last push?". `SINCE` is the
+timestamp you took right before your last push (step E); leave it empty on iteration 1. Right
+after a push, add `--wait 600` straight away: the wait ends only once the bot has acted on the new
+head, so threads left open on purpose cannot make the push look reviewed.
 
 ```bash
-# 10-minute deadline, one retry, then give up.
-wait_for_review() {                       # $1 = attempt label
-  local deadline=$(( SECONDS + 600 ))
-  while [ "$SECONDS" -lt "$deadline" ]; do
-    R=$(gh api repos/{owner}/{repo}/pulls/<PR>/reviews --paginate |
-      jq -s --arg head "$HEAD_SHA" \
-        '[.[][] | select(.user.login=="gemini-code-assist[bot]" and .commit_id==$head)] | sort_by(.submitted_at, .id) | last')
-    if [ -n "$R" ] && [ "$R" != "null" ]; then return 0; fi
-    echo "waiting for Gemini review of $HEAD_SHA ($1)..."; sleep 15
-  done
-  return 1
-}
-
-if ! wait_for_review "first wait"; then
-  echo "no Gemini review after 10m, retrying once"     # say the retry out loud
-  gh pr comment <PR> --body "/gemini review"
-  if ! wait_for_review "after retry"; then
-    echo "Gemini did not review $HEAD_SHA after a retry; stopping and reporting."
-    exit 1                                # honest timeout, never a success claim
-  fi
-fi
+"$SKILL_ROOT/scripts/pr-review-state.sh" --repo OWNER/REPO --pr <PR> --bot gemini-code-assist --since "$SINCE"
 ```
 
-Report the retry in the final summary; two silent timeouts are the failure mode this guard exists
-to prevent.
+- Exit `10` (`findings`): go to B. On iteration 1 this is whatever Gemini (or another bot)
+  already posted.
+- Exit `20` (`pending`): post `/gemini review` (`gh pr comment <PR> --body "/gemini review"`). Then wait with the same command plus `--wait 600`. Run the
+  wait in the background where the host allows it (Claude Code: Bash `run_in_background`; you are
+  re-invoked when it exits) so ten minutes of polling never sits in the conversation. Still `20`
+  after the wait: say so out loud, post `/gemini review` once more, and wait once more. Still `20` after that: stop and
+  report the timeout honestly; never claim success.
+- Exit `0` (`clean`): go to the exit check. A `--wait` call returns `clean` only after a settle
+  re-read 60 seconds later, so a comment landing right behind the review is still caught. A bare
+  read (no `--wait`) that says `clean` is good enough only when you have not pushed since Gemini's
+  last review.
+- Exit `30` (`limited`): stop now and report `blocked: rate-limited`; nothing more is coming.
+- Exit `1`: the read itself failed (often a transient GitHub 502). Retry once; if it fails again,
+  stop and report it. An unknown state is not a clean one.
 
 ### B. Fetch the findings
 
-- **Summary** (the `## Code Review` body): the review `.body` from the object above: read the
+The working set is every unresolved thread in the state JSON with `is_bot: true`: Gemini's
+own (`is_target: true`) **and any other review bot's** (Greptile, for example). A
+fix for one bot often draws a comment from another, and leaving those open is how a "finished" loop
+leaves a PR that is not clean. Treat another bot's thread with exactly the same verify-first rules
+below. Never act on a human's thread (`is_bot: false`); list it in the report.
+
+- **Summary** (the `## Code Review` body): the latest review `.body` from this bot (`gh pr view <PR> --json reviews`): read the
   overall take and the severity spread.
-- **Unresolved inline comments** on the current head:
+- **Unresolved inline comments**: `.unresolved[] | select(.is_bot)` in step A's state JSON lists
+  each thread's `thread_id`, `comment_id`, `path`, `line` and a short excerpt, across every page of
+  threads. Read the full comment before judging it:
 
 ```bash
-gh api repos/{owner}/{repo}/pulls/<PR>/comments --paginate \
-  --jq '.[] | select(.user.login=="gemini-code-assist[bot]") | {id, path, line, body}'
+gh api repos/{owner}/{repo}/pulls/comments/<COMMENT_ID> --jq '{user: .user.login, path, line, body}'
 ```
 
-Also pull the review threads + their resolved state via GraphQL (see step F) so you only act on
-unresolved ones.
-
 Mark each unresolved comment as seen, so the bot and a watching human can tell it is being handled.
 GitHub's reaction set is fixed; `eyes` is the only "looking at it" value:
 
@@ -162,6 +166,7 @@ If step D changed code:
 git status --short                     # look before you stage
 git add <path> [<path>...]             # the files named in the findings you fixed
 git commit -m "address gemini review feedback (geminiloop iteration N)"
+SINCE=$(date -u +%Y-%m-%dT%H:%M:%SZ)   # step A reads bot activity after this
 git push
 ```
 
@@ -177,31 +182,8 @@ If they differ, stop: the fix is not on the PR, so nothing may be resolved yet.
 
 ### F. Reply to and resolve every addressed thread
 
-Only now, with the fixes pushed, reply and resolve. Fetch unresolved threads, **following
-pagination**: a PR with more than 100 threads will otherwise look clean while unresolved findings
-sit on page two:
-
-```bash
-# Loop until hasNextPage is false, passing endCursor back in as $cursor.
-CURSOR=null
-while : ; do
-  PAGE=$(gh api graphql -F cursor="$CURSOR" -f query='
-  query($cursor: String) {
-    repository(owner: "OWNER", name: "REPO") {
-      pullRequest(number: PR_NUMBER) {
-        reviewThreads(first: 100, after: $cursor) {
-          pageInfo { hasNextPage endCursor }
-          nodes { id isResolved comments(first: 1) { nodes { databaseId author { login } path body } } }
-        }
-      }
-    }
-  }')
-  echo "$PAGE"          # collect nodes from every page before deciding the PR is clean
-  PI='.data.repository.pullRequest.reviewThreads.pageInfo'
-  [ "$(echo "$PAGE" | jq -r "$PI.hasNextPage")" = "true" ] || break
-  CURSOR=$(echo "$PAGE" | jq -r "$PI.endCursor")
-done
-```
+Only now, with the fixes pushed, reply and resolve. Take thread and comment ids from step A's state
+JSON (`.unresolved[]`): the script already follows pagination, so do not hand-roll a threads query.
 
 Reply on a thread's comment via `gh api repos/{owner}/{repo}/pulls/<PR>/comments -f body="..." -F in_reply_to=<comment_id>`,
 then resolve:
@@ -225,24 +207,40 @@ gh api --method POST repos/{owner}/{repo}/pulls/comments/<COMMENT_ID>/reactions
 Reply first, then react, then resolve: the reaction is not a substitute for the reply, and a
 resolved thread with no reply loses the reasoning.
 
-Resolve a thread only for comments authored by `gemini-code-assist[bot]` that you have fixed or
-rebutted: never blanket-resolve, and never resolve a human reviewer's thread.
+Resolve a thread only for a bot comment in your working set (this bot's or another
+review bot's) that you have fixed or rebutted: never blanket-resolve, and never resolve a human reviewer's thread.
 
 Threads you are **rebutting** need no push, so they may be replied to and resolved regardless of
 whether step D changed code.
 
-### G. Re-review
+### G. Back to A
 
-Pushing re-triggers Gemini automatically; go back to **A** with the new head SHA. If step D changed
-nothing (all comments were rebutted), skip the push, ensure all threads are resolved, and exit.
+Go back to **A**. After a push, A waits for Gemini's review of the new head (pushing re-triggers
+it when auto-review is on; otherwise A triggers it). If this iteration changed no code (every finding
+rebutted), there is no new head to wait for: A's fresh read says `clean` or shows what is still open.
 
 ## 3. Exit conditions
 
+Decide from a fresh state read, never from what you remember resolving.
+
 Stop when **any** is true:
-- Zero unresolved `gemini-code-assist[bot]` comments remain, and every comment this round was fixed
-  or rebutted+resolved. (There is no score to hit: this is "done".)
-- Max iterations (5) reached: report what remains.
-- Gemini never responded after one retry: report the timeout honestly; do not claim success.
+- **Done**: the latest `pr-review-state.sh --wait 600` call, made after your last push, exited `0`
+  (`clean`); with no push since the bot's last review, a bare read that exits `0` is enough. Open human threads do not block this; list them in the report.
+- **Max iterations (5)** reached: report what remains.
+- **Timeout**: still `pending` after the retry in step A. Report it honestly; do not claim success.
+- **Rate limited**: exit `30`. Report `blocked: rate-limited`.
+
+## Keep the context small; resume instead of restarting
+
+- Carry only three things between iterations: the iteration counter, the latest state JSON, and a
+  ledger of each thread you handled (fixed with its commit, rebutted, or blocked). Re-read files
+  fresh each iteration; do not re-paste earlier rounds' comment bodies.
+- All loop state lives on the PR, so the loop is resumable. If the session has grown long or slow,
+  or a bot commented after the loop ended, run this skill again in a fresh session: step A picks up
+  from the PR as it is now. Starting fresh is cheaper than dragging a long session through more
+  rounds.
+- After reporting done, if the host can schedule a follow-up (Claude Code: `/loop` or a scheduled
+  wakeup), offer one re-check about 20 minutes later for bots that comment late.
 
 ## 4. Report
 
@@ -252,7 +250,9 @@ Geminiloop complete.
   Iterations:         N
   Comments fixed:     N   (genuinely-correct findings)
   Comments rebutted:  N   (false positives / nits, resolved with rationale)
-  Remaining:          0
+  Remaining:          N   (bot threads still open)
+  Human threads:      N   (open, listed below; this loop never resolves them)
+  Final state:        clean | timeout | rate-limited | iteration cap
 ```
 
 If it stopped at max iterations, list the remaining threads with your current assessment