Stop Requesting Copilot Into a Reached Rate Limit

.agents/skills/pr-review-conduct/SKILL.md

@@ -66,10 +66,11 @@ visible comments, routinely still carries a finding nobody has answered. Treatin
    A refusal is not that coverage, so this item stays unsatisfied under one, and the loop clears
    it where it can. A file-count refusal is cleared by splitting the pull request, which is the
    only cause on record that the loop can clear. `pr_review.py wait` exit `46` is the one nothing
-   the loop does clears, an account-quota refusal carrying the current head, which is the case
-   "Which Reviewers a Repository Actually Has" below states. Exit `47` is that same account state
-   read from the reviewer's activity elsewhere when this head carries none of its own, and exit
-   `41` holding across several heads with no cause its body names reaches it the slower way.
+   the loop does clears, the pull request's newest Copilot review being an account-quota refusal
+   or an error refusal read as a possible quota hit, on this head or an earlier one, which is the
+   case "Which Reviewers a Repository Actually Has" below states. Exit `47` is that same account
+   state read from the reviewer's activity elsewhere when this head carries none of its own, and
+   exit `41` holding across several heads with no cause its body names reaches it the slower way.
    Those three are `wait`'s alone: `status` exits 0 over a refusal, carrying it as `refusal=` in
    the digest line instead, so reading that exit code as the absence of one would falsely satisfy
    this item on the exact state it exists to catch. That is where the
@@ -156,9 +157,11 @@ must have done.
 - **Copilot's absence blocks, and is answered elsewhere.** Merge Gate item 2 requires Copilot's own
   coverage of the current head, and the loop's own re-request step below is where a missing one is
   answered, on the terms stated there. A refusal naming the account quota is its own case rather
-  than a review: it covers no head, so the gate stays unsatisfied, and nothing the loop does
-  clears it, since the refusal names no time to wait for and re-requesting returns it again. That
-  one goes to the maintainer, rather than into a wait with no stated end.
+  than a review, and so is one saying only that Copilot encountered an error, which is what the
+  weekly rate limit posts. Either covers no head, so the gate stays unsatisfied, and nothing the
+  loop does clears it, since re-requesting returns it again and spends quota doing so. Where the
+  reviewer's run log names a reset time `pr_review.py` reports it. Either refusal goes to the
+  maintainer, rather than into a wait.
 
 Where a reviewer's behavior still surprises you after reading what it posted, the hub's
 `docs/pr-reviewer-reference.md` records what each one does, what shapes it, and which repositories

.claude-plugin/fleet-skills/.source-digests/pr-review-conduct

@@ -1 +1 @@
-b526db5d9b32632a
+e611a6183eb65c72

.claude-plugin/fleet-skills/skills/pr-review-conduct/SKILL.md

@@ -66,10 +66,11 @@ visible comments, routinely still carries a finding nobody has answered. Treatin
    A refusal is not that coverage, so this item stays unsatisfied under one, and the loop clears
    it where it can. A file-count refusal is cleared by splitting the pull request, which is the
    only cause on record that the loop can clear. `pr_review.py wait` exit `46` is the one nothing
-   the loop does clears, an account-quota refusal carrying the current head, which is the case
-   "Which Reviewers a Repository Actually Has" below states. Exit `47` is that same account state
-   read from the reviewer's activity elsewhere when this head carries none of its own, and exit
-   `41` holding across several heads with no cause its body names reaches it the slower way.
+   the loop does clears, the pull request's newest Copilot review being an account-quota refusal
+   or an error refusal read as a possible quota hit, on this head or an earlier one, which is the
+   case "Which Reviewers a Repository Actually Has" below states. Exit `47` is that same account
+   state read from the reviewer's activity elsewhere when this head carries none of its own, and
+   exit `41` holding across several heads with no cause its body names reaches it the slower way.
    Those three are `wait`'s alone: `status` exits 0 over a refusal, carrying it as `refusal=` in
    the digest line instead, so reading that exit code as the absence of one would falsely satisfy
    this item on the exact state it exists to catch. That is where the
@@ -156,9 +157,11 @@ must have done.
 - **Copilot's absence blocks, and is answered elsewhere.** Merge Gate item 2 requires Copilot's own
   coverage of the current head, and the loop's own re-request step below is where a missing one is
   answered, on the terms stated there. A refusal naming the account quota is its own case rather
-  than a review: it covers no head, so the gate stays unsatisfied, and nothing the loop does
-  clears it, since the refusal names no time to wait for and re-requesting returns it again. That
-  one goes to the maintainer, rather than into a wait with no stated end.
+  than a review, and so is one saying only that Copilot encountered an error, which is what the
+  weekly rate limit posts. Either covers no head, so the gate stays unsatisfied, and nothing the
+  loop does clears it, since re-requesting returns it again and spends quota doing so. Where the
+  reviewer's run log names a reset time `pr_review.py` reports it. Either refusal goes to the
+  maintainer, rather than into a wait.
 
 Where a reviewer's behavior still surprises you after reading what it posted, the hub's
 `docs/pr-reviewer-reference.md` records what each one does, what shapes it, and which repositories

.github/skills/pr-review-conduct/SKILL.md

@@ -66,10 +66,11 @@ visible comments, routinely still carries a finding nobody has answered. Treatin
    A refusal is not that coverage, so this item stays unsatisfied under one, and the loop clears
    it where it can. A file-count refusal is cleared by splitting the pull request, which is the
    only cause on record that the loop can clear. `pr_review.py wait` exit `46` is the one nothing
-   the loop does clears, an account-quota refusal carrying the current head, which is the case
-   "Which Reviewers a Repository Actually Has" below states. Exit `47` is that same account state
-   read from the reviewer's activity elsewhere when this head carries none of its own, and exit
-   `41` holding across several heads with no cause its body names reaches it the slower way.
+   the loop does clears, the pull request's newest Copilot review being an account-quota refusal
+   or an error refusal read as a possible quota hit, on this head or an earlier one, which is the
+   case "Which Reviewers a Repository Actually Has" below states. Exit `47` is that same account
+   state read from the reviewer's activity elsewhere when this head carries none of its own, and
+   exit `41` holding across several heads with no cause its body names reaches it the slower way.
    Those three are `wait`'s alone: `status` exits 0 over a refusal, carrying it as `refusal=` in
    the digest line instead, so reading that exit code as the absence of one would falsely satisfy
    this item on the exact state it exists to catch. That is where the
@@ -156,9 +157,11 @@ must have done.
 - **Copilot's absence blocks, and is answered elsewhere.** Merge Gate item 2 requires Copilot's own
   coverage of the current head, and the loop's own re-request step below is where a missing one is
   answered, on the terms stated there. A refusal naming the account quota is its own case rather
-  than a review: it covers no head, so the gate stays unsatisfied, and nothing the loop does
-  clears it, since the refusal names no time to wait for and re-requesting returns it again. That
-  one goes to the maintainer, rather than into a wait with no stated end.
+  than a review, and so is one saying only that Copilot encountered an error, which is what the
+  weekly rate limit posts. Either covers no head, so the gate stays unsatisfied, and nothing the
+  loop does clears it, since re-requesting returns it again and spends quota doing so. Where the
+  reviewer's run log names a reset time `pr_review.py` reports it. Either refusal goes to the
+  maintainer, rather than into a wait.
 
 Where a reviewer's behavior still surprises you after reading what it posted, the hub's
 `docs/pr-reviewer-reference.md` records what each one does, what shapes it, and which repositories

scripts/README.md

@@ -188,7 +188,7 @@ Everything else is decidable and says so. One of the reviewer's own nodes in vie
 
 The digest reports the completed head review's effective effort as `lite`, `balanced`, or `max` when its metadata provides one. It reports `effort_source=default` for `Default (<level>)` and `effort_source=explicit` for a bare level. Missing metadata reports `unknown` for both fields. Effort is informational and never changes the coverage or completion verdict. The workflow never selects or changes the user-controlled setting.
 
-`wait` exits `41` when the review carrying the head is a **refusal**, meaning its body opens by saying it did not review. That answer arrives as a formal review, `state: COMMENTED`, with the correct commit and zero inline threads, so it satisfies every coverage check a clean pass does and renders a digest byte for byte identical to one. The `40` reasoning does not reach it, because that reasoning rests on a comment carrying no commit, and this carries the right one. A pull request of 301 changed files, one over the reviewer's limit of 300, read as `rounds=1 review_on_head=yes threads=0 unresolved=0 merge=CLEAN` and was one command from merging on a review that never ran. A refusal is therefore not coverage: `review_on_head` reports `NO`, the summary line carries a `refusal=YES` of its own, since `rounds=1 review_on_head=NO` is equally what a stale round looks like and the two want opposite responses, and the body prints whole because its wording is the only thing separating a file-count refusal, cleared by splitting the pull request, from a quota one, cleared by waiting. The script reads neither cause, only that the round declined. The match is on the body's **opening line**, since a refusal is the whole body where a review that merely quotes the wording carries it below its own overview, and this script and this file are exactly that quotation. One line rather than two, because a review's first line is its heading and its second is the overview prose: reading two passed every case except the review describing this check, which reported itself as a refusal of itself. The cost is the other direction, that a refusal introduced by a heading would sit below the opening and be missed, and answering that shape means telling a refusal from an overview rather than reading one line further. It is an alternation over the runbook's phrasings for the same reason the suppressed heading is, and a case asserts the script's pattern is the one the runbook publishes. The reading is **head-scoped**, unlike a suppressed finding, because a refusal is a statement about one commit that a push retires, and a genuine review of that same head outranks it, coverage that landed being coverage. The field is spent by that coverage as well as the exit code is, or the summary line reads `review_on_head=yes refusal=YES` and tells a reader to split a pull request the reviewer has just reviewed. The liveness query carries no bodies, so a refusal reads there as ordinary coverage. That is deliberate: it ends the wait, which is what a terminal outcome should do, and the full read every wait finishes with is what tells the two apart, so no exit code comes from the cheaper reading.
+`wait` exits `41` when the review carrying the head is a **refusal**, meaning its body opens by saying it did not review. That answer arrives as a formal review, `state: COMMENTED`, with the correct commit and zero inline threads, so it satisfies every coverage check a clean pass does and renders a digest byte for byte identical to one. The `40` reasoning does not reach it, because that reasoning rests on a comment carrying no commit, and this carries the right one. A pull request of 301 changed files, one over the reviewer's limit of 300, read as `rounds=1 review_on_head=yes threads=0 unresolved=0 merge=CLEAN` and was one command from merging on a review that never ran. A refusal is therefore not coverage: `review_on_head` reports `NO`, the summary line carries a `refusal=YES` of its own, since `rounds=1 review_on_head=NO` is equally what a stale round looks like and the two want opposite responses, and the body prints whole because its wording is the only thing separating a file-count refusal, cleared by splitting the pull request, from a quota one, cleared by waiting. One body names no cause at all, "Copilot encountered an error and was unable to review this pull request", which is what the weekly rate limit posts, so `status` and `wait` read the job log of the reviewer's own failed Actions run on that commit: a logged rate limit reports as `refusal=QUOTA` with the reset time it states, and anything else as `refusal=ERROR`, a possible quota hit. `wait` sends no request while the pull request's newest Copilot review is a quota or error refusal, on this head or an earlier one, since a request into a reached limit spends what it cannot recover, and exits `46` unless a request already pending after a refusal on an earlier head lands. Where nothing covers the head, the digest's `refusal=` field reads that refusal from the earlier head too. Past the quota and error refusals, the script reads no cause, only that the round declined. The match is on the body's **opening line**, since a refusal is the whole body where a review that merely quotes the wording carries it below its own overview, and this script and this file are exactly that quotation. One line rather than two, because a review's first line is its heading and its second is the overview prose: reading two passed every case except the review describing this check, which reported itself as a refusal of itself. The cost is the other direction, that a refusal introduced by a heading would sit below the opening and be missed, and answering that shape means telling a refusal from an overview rather than reading one line further. It is an alternation over the runbook's phrasings for the same reason the suppressed heading is, and a case asserts the script's pattern is the one the runbook publishes. The `41` reading is **head-scoped**, unlike a suppressed finding, because a refusal is a statement about one commit that a push retires, and a genuine review of that same head outranks it, coverage that landed being coverage. The field is spent by that coverage as well as the exit code is, or the summary line reads `review_on_head=yes refusal=YES` and tells a reader to split a pull request the reviewer has just reviewed. The liveness query carries no bodies, so a refusal reads there as ordinary coverage. That is deliberate: it ends the wait, which is what a terminal outcome should do, and the full read every wait finishes with is what tells the two apart, so no exit code comes from the cheaper reading.
 
 `status` and `wait` both exit `42` where the round covering the head read **fewer files than the pull request changed**, or where an earlier round read fewer and the round covering the head states no coverage of its own, and `43` where it states its coverage in a wording this script does not read. Coverage of the head was the only coverage anything checked, and coverage of the diff is a second reading stated in a line nothing parsed: a partial round carries the right `commit.oid`, raises no threads, and reports "generated no comments", so it is the clean pass byte for byte in everything read. Over 332 Copilot review bodies on this repository, five rounds across three pull requests reported reading fewer files than were changed and all three merged, one of them leaving a file of three unread across **both** its rounds. This is the third instance of the shape `refusal` and `suppressed` are the first two, and the only one nothing was reading.