receiving-pr-reviews

Receiving PR Reviews

1. Fetch every unresolved thread, every unresponded review, and Codex's approval state:

   uv run ./.agents/skills/receiving-pr-reviews/scripts/pr_review_threads.py fetch --pr <N>
   

   If the helper cannot use gh and GitHub MCP tools are available, use the lightweight GitHub MCP fallback for this workflow instead. Do not install or reconfigure gh merely to avoid the fallback, and do not run both paths for the same snapshot.

   Read reviews_count, threads_count, unresolved_count and reviewability.blockers together — never treat an empty unresolved array on its own as "nothing to do". A threads_count of 0 means no inline thread landed, not that no review landed: a top-level approval or COMMENTED review surfaces only through reviews_with_body. A non-empty blockers means the empty result set is expected and the fix is on the PR itself — undraft it, resolve the conflicts — not in the review queue.

   reviews_with_body is every review whose feedback lives in the review's own summary text rather than an inline comment. unresponded_reviews narrows that to the ones this run has not answered yet; treat every entry as actionable input. A thread's comments_truncated: true means that one thread has passed 100 comments — page its comments connection directly before concluding anything about it. For codex_approved, see step 7.

2. For each unresolved thread or unresponded review: read it, validate the claim locally, assess against the change goal and repository instructions.

3. Implement, commit, and push a fix only when it improves the product — push before replying, so the SHA named in the reply is inspectable and resolving the thread never outruns what is actually on the remote.

   Confirm that push's CI with checks rather than hand-writing a polling loop:

   uv run ./.agents/skills/receiving-pr-reviews/scripts/pr_review_threads.py checks --pr <N> [--timeout-seconds 270]
   

   status is passed, failed, pending, or none — pending is not green. Without --timeout-seconds this is one snapshot; with it, the command sleeps --interval-seconds between polls and returns as soon as the verdict settles. Read the whole object rather than extracting one field: none alongside reviewability.mergeable: "CONFLICTING" means checks cannot start — GitHub builds no merge ref for a conflicting PR, so no workflow runs — which is what an apparently stalled PR usually is, and no amount of waiting will change it. A draft PR is not that case: workflows do run on drafts unless a workflow opts out, so a draft blocker in reviewability.blockers says nothing about CI and checks keeps waiting through it.

   A bare none right after a push is not yet an answer — GitHub returns the same empty result before it has registered the push's workflow runs as it does for a repo with no CI. checks re-polls a none once to tell them apart, so pass --timeout-seconds when you have just pushed rather than reading the first snapshot as final.

4. Reply on that thread with the disposition — conclusion, evidence, commit SHA, or why no change was warranted:

   uv run ./.agents/skills/receiving-pr-reviews/scripts/pr_review_threads.py reply --pr <N> --comment-id <databaseId> --body '...'
   

5. Resolve the thread:

   uv run ./.agents/skills/receiving-pr-reviews/scripts/pr_review_threads.py resolve --thread-id <id>
   

6. A decision spanning threads (PR sequencing, rebase disposition), or a response to a reviews_with_body/unresponded_reviews entry, goes on the PR itself via gh pr comment <N> -R <owner>/<repo> — the same owner/repo this run used in step 1 — before the work it governs. When answering a specific entry, quote that review's own url field from step 1's output in the comment body. That quoted url, postdating the review, is what clears the review out of unresponded_reviews on the next check; chronological order alone does not.

7. Once all current threads and reviews are addressed, re-check with watch, looping short calls rather than one long block: