docs: read the reviewer's status notice when a review loop is stuck

.claude/skills/implementing-github-issues/SKILL.md

@@ -550,7 +550,7 @@ Guardrails:
 1. **Batch** every finding in the pass. Don't fix-and-push one at a time — that's exactly what turns one class of issue into N rounds.
 2. **Resolve** them together by the rule above (resolve the class, a test per fix).
 3. **Run the internal review loop** (Phase 10b) over the batched diff — the clean-eyes pass, looped until it surfaces nothing new — so you also catch the *adjacent* edges this round's comments imply before the reviewer does.
-4. **Push once**, then wait for the verdict. "Green" = the reviewer **approves** *or* a fresh review reports **0 actionable comments** — not merely the absence of new comments. A bot reviewer (CodeRabbit) often will **not** flip `CHANGES_REQUESTED → APPROVED` on its own after a push, so the loop can hang waiting for an approval that never comes. **When it's stuck** — every thread addressed but the review decision hasn't moved — bump it: comment `@coderabbitai review` to force a fresh pass (and `@coderabbitai resolve` to close out addressed threads). A fresh 0-actionable review is green; new findings are the next round → repeat from step 1.
+4. **Push once**, then wait for the verdict. "Green" = the reviewer **approves** *or* a fresh review reports **0 actionable comments** — not merely the absence of new comments. A bot reviewer (CodeRabbit) often will **not** flip `CHANGES_REQUESTED → APPROVED` on its own after a push, so the loop can hang waiting for an approval that never comes. **When it's stuck** — every thread addressed but the review decision hasn't moved, or no fresh review appeared — first **read the reviewer's own recent comments for a status notice**, then do exactly what it says. Bots post these: e.g. CodeRabbit auto-pauses after *an influx of commits* (which this very batch-and-push loop produces) and prints the commands to use. Run the one the notice names — `@coderabbitai resume` to re-enable automatic reviews (a *paused* loop will **not** recover from a one-shot `@coderabbitai review`), `@coderabbitai review` for a single pass, `@coderabbitai resolve` to close addressed threads. Don't guess between them; the notice tells you which. A fresh 0-actionable review is green; new findings are the next round → repeat from step 1.
 
 This is what makes the round cap survivable: each round closes a whole *class* and pre-empts its neighbors, so you converge in a round or two instead of bleeding one edge per round into a lockup. The internal loop (10b) is not just a pre-post gate — it runs on **every** round, on the batched changes, before each push.
 

.codex/skills/implementing-github-issues/SKILL.md

@@ -550,7 +550,7 @@ Guardrails:
 1. **Batch** every finding in the pass. Don't fix-and-push one at a time — that's exactly what turns one class of issue into N rounds.
 2. **Resolve** them together by the rule above (resolve the class, a test per fix).
 3. **Run the internal review loop** (Phase 10b) over the batched diff — the clean-eyes pass, looped until it surfaces nothing new — so you also catch the *adjacent* edges this round's comments imply before the reviewer does.
-4. **Push once**, then wait for the verdict. "Green" = the reviewer **approves** *or* a fresh review reports **0 actionable comments** — not merely the absence of new comments. A bot reviewer (CodeRabbit) often will **not** flip `CHANGES_REQUESTED → APPROVED` on its own after a push, so the loop can hang waiting for an approval that never comes. **When it's stuck** — every thread addressed but the review decision hasn't moved — bump it: comment `@coderabbitai review` to force a fresh pass (and `@coderabbitai resolve` to close out addressed threads). A fresh 0-actionable review is green; new findings are the next round → repeat from step 1.
+4. **Push once**, then wait for the verdict. "Green" = the reviewer **approves** *or* a fresh review reports **0 actionable comments** — not merely the absence of new comments. A bot reviewer (CodeRabbit) often will **not** flip `CHANGES_REQUESTED → APPROVED` on its own after a push, so the loop can hang waiting for an approval that never comes. **When it's stuck** — every thread addressed but the review decision hasn't moved, or no fresh review appeared — first **read the reviewer's own recent comments for a status notice**, then do exactly what it says. Bots post these: e.g. CodeRabbit auto-pauses after *an influx of commits* (which this very batch-and-push loop produces) and prints the commands to use. Run the one the notice names — `@coderabbitai resume` to re-enable automatic reviews (a *paused* loop will **not** recover from a one-shot `@coderabbitai review`), `@coderabbitai review` for a single pass, `@coderabbitai resolve` to close addressed threads. Don't guess between them; the notice tells you which. A fresh 0-actionable review is green; new findings are the next round → repeat from step 1.
 
 This is what makes the round cap survivable: each round closes a whole *class* and pre-empts its neighbors, so you converge in a round or two instead of bleeding one edge per round into a lockup. The internal loop (10b) is not just a pre-post gate — it runs on **every** round, on the batched changes, before each push.
 

packages/cli/src/bootstrap-assets/skills/implementing-github-issues/SKILL.md

@@ -550,7 +550,7 @@ Guardrails:
 1. **Batch** every finding in the pass. Don't fix-and-push one at a time — that's exactly what turns one class of issue into N rounds.
 2. **Resolve** them together by the rule above (resolve the class, a test per fix).
 3. **Run the internal review loop** (Phase 10b) over the batched diff — the clean-eyes pass, looped until it surfaces nothing new — so you also catch the *adjacent* edges this round's comments imply before the reviewer does.
-4. **Push once**, then wait for the verdict. "Green" = the reviewer **approves** *or* a fresh review reports **0 actionable comments** — not merely the absence of new comments. A bot reviewer (CodeRabbit) often will **not** flip `CHANGES_REQUESTED → APPROVED` on its own after a push, so the loop can hang waiting for an approval that never comes. **When it's stuck** — every thread addressed but the review decision hasn't moved — bump it: comment `@coderabbitai review` to force a fresh pass (and `@coderabbitai resolve` to close out addressed threads). A fresh 0-actionable review is green; new findings are the next round → repeat from step 1.
+4. **Push once**, then wait for the verdict. "Green" = the reviewer **approves** *or* a fresh review reports **0 actionable comments** — not merely the absence of new comments. A bot reviewer (CodeRabbit) often will **not** flip `CHANGES_REQUESTED → APPROVED` on its own after a push, so the loop can hang waiting for an approval that never comes. **When it's stuck** — every thread addressed but the review decision hasn't moved, or no fresh review appeared — first **read the reviewer's own recent comments for a status notice**, then do exactly what it says. Bots post these: e.g. CodeRabbit auto-pauses after *an influx of commits* (which this very batch-and-push loop produces) and prints the commands to use. Run the one the notice names — `@coderabbitai resume` to re-enable automatic reviews (a *paused* loop will **not** recover from a one-shot `@coderabbitai review`), `@coderabbitai review` for a single pass, `@coderabbitai resolve` to close addressed threads. Don't guess between them; the notice tells you which. A fresh 0-actionable review is green; new findings are the next round → repeat from step 1.
 
 This is what makes the round cap survivable: each round closes a whole *class* and pre-empts its neighbors, so you converge in a round or two instead of bleeding one edge per round into a lockup. The internal loop (10b) is not just a pre-post gate — it runs on **every** round, on the batched changes, before each push.
 

packages/skills/implementing-github-issues/SKILL.md

@@ -550,7 +550,7 @@ Guardrails:
 1. **Batch** every finding in the pass. Don't fix-and-push one at a time — that's exactly what turns one class of issue into N rounds.
 2. **Resolve** them together by the rule above (resolve the class, a test per fix).
 3. **Run the internal review loop** (Phase 10b) over the batched diff — the clean-eyes pass, looped until it surfaces nothing new — so you also catch the *adjacent* edges this round's comments imply before the reviewer does.
-4. **Push once**, then wait for the verdict. "Green" = the reviewer **approves** *or* a fresh review reports **0 actionable comments** — not merely the absence of new comments. A bot reviewer (CodeRabbit) often will **not** flip `CHANGES_REQUESTED → APPROVED` on its own after a push, so the loop can hang waiting for an approval that never comes. **When it's stuck** — every thread addressed but the review decision hasn't moved — bump it: comment `@coderabbitai review` to force a fresh pass (and `@coderabbitai resolve` to close out addressed threads). A fresh 0-actionable review is green; new findings are the next round → repeat from step 1.
+4. **Push once**, then wait for the verdict. "Green" = the reviewer **approves** *or* a fresh review reports **0 actionable comments** — not merely the absence of new comments. A bot reviewer (CodeRabbit) often will **not** flip `CHANGES_REQUESTED → APPROVED` on its own after a push, so the loop can hang waiting for an approval that never comes. **When it's stuck** — every thread addressed but the review decision hasn't moved, or no fresh review appeared — first **read the reviewer's own recent comments for a status notice**, then do exactly what it says. Bots post these: e.g. CodeRabbit auto-pauses after *an influx of commits* (which this very batch-and-push loop produces) and prints the commands to use. Run the one the notice names — `@coderabbitai resume` to re-enable automatic reviews (a *paused* loop will **not** recover from a one-shot `@coderabbitai review`), `@coderabbitai review` for a single pass, `@coderabbitai resolve` to close addressed threads. Don't guess between them; the notice tells you which. A fresh 0-actionable review is green; new findings are the next round → repeat from step 1.
 
 This is what makes the round cap survivable: each round closes a whole *class* and pre-empts its neighbors, so you converge in a round or two instead of bleeding one edge per round into a lockup. The internal loop (10b) is not just a pre-post gate — it runs on **every** round, on the batched changes, before each push.
 

planning/middle-management-build-spec.md

@@ -1356,7 +1356,7 @@ This pulls the review loop forward from Phase 8: it is the *same* `waitFor`/poll
 26. `waitFor` signal integration in the implementation workflow — the park/resume spine, keyed by resume reason (`answered-question` | `review-changes`). The `done` path parks on `epic-N-review-resolved` after `mark-pr-ready` instead of going terminal.
 27. Sentinel-file detection in `classifyStop`.
 28. GitHub poller — for Epics with an active wait, fires the signal on either trigger: a human reply on the issue (asked-question), or a PR review-state transition — `CHANGES_REQUESTED` / `changes-requested` label resumes; the loop ends on **review-resolved**, which is `APPROVED` **or** a fresh review reporting **0 actionable comments**. (A bot reviewer like CodeRabbit often won't flip `CHANGES_REQUESTED → APPROVED` on its own, so the poller must treat a 0-actionable re-review as resolved — otherwise the loop hangs on an approval that never comes.)
-29. Resume logic — re-spawn a fresh agent re-primed per reason: asked-question feeds the human's answer; review-changes pulls **all of the review pass's threads** into `.middle/prompt.md` behind an "address review" brief, increments a round counter, and after the configured cap (**default 5**) without resolution parks in `waiting-human` and stops auto-resuming. **After pushing each round the resume step bumps the reviewer** (`@coderabbitai review`, and `@coderabbitai resolve` to close addressed threads) so a stuck `CHANGES_REQUESTED` gets a fresh verdict instead of hanging the poller.
+29. Resume logic — re-spawn a fresh agent re-primed per reason: asked-question feeds the human's answer; review-changes pulls **all of the review pass's threads** into `.middle/prompt.md` behind an "address review" brief, increments a round counter, and after the configured cap (**default 5**) without resolution parks in `waiting-human` and stops auto-resuming. **After pushing each round the resume step bumps the reviewer** so a stuck `CHANGES_REQUESTED` gets a fresh verdict instead of hanging the poller — but it must **read the reviewer's status notice and issue the prescribed command**, not blindly comment. CodeRabbit auto-pauses after an influx of commits (which the batch-and-push loop itself produces) and posts the commands: `@coderabbitai resume` re-enables automatic review (a *paused* loop never recovers from a one-shot `@coderabbitai review`), `@coderabbitai review` runs a single pass, `@coderabbitai resolve` closes addressed threads. The poller/resume must distinguish "paused" from "reviewing" from "done" so it picks the right bump.
 
 The review-changes brief carries the same per-round procedure the `implementing-github-issues` skill codifies (→ "Addressing review feedback"), so the automated daemon loop and a hand-driven agent behave identically: **batch** every finding in the pass, **resolve the class** (a test per fix), run the **internal review loop** (skill Phase 10b — a clean-eyes review subagent over the batched diff, looped until it surfaces nothing new) so adjacent edges are caught before the reviewer sees them, then **push once** and re-park on `epic-N-review-resolved` to await the next verdict. One round = one whole pass, not one comment — that is what keeps the 5-round cap survivable. The round cap is a per-repo config knob (default 5).