agent-sh
diff --git a/‎.github/workflows/claude-code-review.yml‎
Lines changed: 46 additions & 14 deletions b/‎.github/workflows/claude-code-review.yml‎
Lines changed: 46 additions & 14 deletions
@@ -56,16 +56,24 @@ jobs:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           REPO: ${{ github.repository }}
           HEAD_SHA: ${{ github.event.pull_request.head.sha }}
+          HEAD_REF: ${{ github.event.pull_request.head.ref }}
           EVENT_ACTION: ${{ github.event.action }}
           PR_NUMBER: ${{ github.event.pull_request.number }}
         run: |
           WORKFLOW_FILE="claude-code-review.yml"
 
+          # Scoped to the PR's branch, not its head SHA. Filtering on head_sha
+          # made this a per-commit cap that reset on every push - so a PR could
+          # take unlimited reviews, three per commit, which is the opposite of
+          # the intent. `branch` matches the PR's head ref and so spans the whole
+          # PR.
           RUN_COUNT=$(gh api \
             -H "Accept: application/vnd.github+json" \
             -H "X-GitHub-Api-Version: 2022-11-28" \
-            "repos/${REPO}/actions/workflows/${WORKFLOW_FILE}/runs?head_sha=${HEAD_SHA}&status=completed" \
-            --jq '[.workflow_runs[] | select(.event == "pull_request" and .conclusion == "success")] | length' || echo "")
+            --paginate \
+            "repos/${REPO}/actions/workflows/${WORKFLOW_FILE}/runs?branch=${HEAD_REF}&status=completed&per_page=100" \
+            --jq '[.workflow_runs[] | select(.event == "pull_request" and .conclusion == "success")] | length' \
+            | awk '{total += $1} END {print total + 0}' || echo "")
 
           RUN_COUNT=${RUN_COUNT:-0}
           if ! echo "$RUN_COUNT" | grep -qE '^[0-9]+$'; then
@@ -75,22 +83,19 @@ jobs:
 
           RUN_COUNT=$((RUN_COUNT + 1))
 
-          # Note this counts SUCCESSFUL runs for THIS commit: the API query
-          # filters on head_sha, so the cap resets on every push. Filtering on
-          # `conclusion == "success"` matters because the concurrency group
-          # cancels superseded runs, a cancelled run reports
-          # `status=completed`, and non-push events (draft -> ready_for_review,
-          # close/reopen) fire on the same sha - so cancellations would
-          # otherwise burn budget slots without ever producing a review. In-flight
-          # runs are still uncounted; the concurrency group prevents overlap.
-          echo "This is run #$RUN_COUNT for commit ${HEAD_SHA:0:8} (event: $EVENT_ACTION)"
+          # Counts SUCCESSFUL runs across the whole PR. `conclusion == "success"`
+          # matters because the concurrency group cancels superseded runs and a
+          # cancelled run still reports `status=completed`, so cancellations would
+          # otherwise burn budget without producing a review. In-flight runs are
+          # uncounted; the concurrency group prevents overlap.
+          echo "This is review #$RUN_COUNT for PR #${PR_NUMBER} (${HEAD_REF}, event: $EVENT_ACTION)"
 
           if [ "$RUN_COUNT" -le 3 ]; then
             echo "should_run=true" >> $GITHUB_OUTPUT
-            echo "[OK] Will run Claude review (run $RUN_COUNT of 3 for this commit)"
+            echo "[OK] Will run Claude review (review $RUN_COUNT of 3 for this PR)"
           else
             echo "should_run=false" >> $GITHUB_OUTPUT
-            echo "[SKIP] Skipping Claude review (already ran 3 times for this commit)"
+            echo "[SKIP] Skipping Claude review (already ran 3 times for this PR)"
           fi
 
       # Toolchain and cache come after the run-count gate: both are pointless
@@ -190,6 +195,33 @@ jobs:
             clippy already gate those. Report only what a maintainer would act on,
             and say so plainly if the diff looks correct.
 
+            **Be exhaustive in one pass.** You get at most 3 reviews per PR, so
+            this may be the only one. For every problem you find, before
+            reporting it, search the diff and the files it touches for every
+            other instance of the same class and report them together as one
+            finding. Do not report one instance and stop.
+
+            Concretely, if you find:
+
+            - a list or allowlist missing an entry, check whether the parallel
+              lists elsewhere are missing it too, and whether that list is
+              missing anything else
+            - a message, comment, or doc line that contradicts the code it
+              describes, grep for the other places making the same claim
+            - a check that handles one direction, ask what the opposite
+              direction does
+            - a fix applied in one file, check whether its sibling files need it
+
+            A finding that says "and the same applies at X, Y, Z" is worth far
+            more than three rounds discovering X, then Y, then Z. If you fix one
+            corner of a class and leave the others, the next push spends another
+            of the three reviews on the same bug.
+
+            State your confidence and how you verified each finding. If you
+            could not verify something - a tool was unavailable, a fixture was
+            impractical - say so explicitly rather than presenting inference as
+            measurement, and say what would close the gap.
+
             Use inline comments for specific lines; one top-level comment for
             overall assessment.
 
@@ -199,4 +231,4 @@ jobs:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           PR_NUMBER: ${{ github.event.pull_request.number }}
         run: |
-          gh pr comment "$PR_NUMBER" --body "[INFO] Claude Code review was skipped as it has already run 3 times for this commit."
+          gh pr comment "$PR_NUMBER" --body "[INFO] Claude Code review was skipped as it has already run 3 times for this PR."