Menu
Fetch and summarize review feedback on the active pull request into one prioritized action list. Use when the user asks to "get PR comments", "what did reviewers say", "summarize PR feedback", or "what do I still need to address on this PR".
| name | get-pr-comments |
| description | Fetch and summarize review feedback on the active pull request into one prioritized action list. Use when the user asks to "get PR comments", "what did reviewers say", "summarize PR feedback", or "what do I still need to address on this PR". |
| argument-hint | [<pr number or url>] |
Read-only. Turns scattered PR feedback into a single, prioritized list of what to act on.
$ARGUMENTS may name the PR (a number or URL). If empty, resolve the PR for the current branch:
gh pr view --json number,url,title,headRefName,state
If no PR exists for the branch, say so and stop — there is nothing to summarize.
Pull the three sources of feedback; they live in different places:
# Inline review threads WITH resolution state — use GraphQL. The REST
# pulls/comments endpoint omits isResolved, so it can't tell you what's
# already been addressed.
gh api graphql -F owner=<owner> -F repo=<repo> -F pr=<number> -f query='
query($owner:String!,$repo:String!,$pr:Int!){
repository(owner:$owner,name:$repo){
pullRequest(number:$pr){
reviewThreads(first:100){
pageInfo{hasNextPage endCursor}
nodes{
isResolved isOutdated
comments(first:50){pageInfo{hasNextPage} nodes{path line body author{login}}}
}
}
}
}
}'
# Review summaries and verdicts (APPROVED / CHANGES_REQUESTED / COMMENTED)
gh pr view <number> --json reviews
# Top-level discussion comments
gh pr view <number> --json comments
The caps (100 threads, 50 comments per thread) cover most PRs; if either pageInfo.hasNextPage is true, page with after: <endCursor> until every thread — and every comment within a long thread — is read. Summarizing from a truncated set can silently drop a blocking thread or the latest ask in a busy one.
Skip threads where isResolved is true (already addressed) or isOutdated is true (the referenced code has since changed) — don't re-surface those as open work.
Collapse the raw feedback into one action list. For each item, capture the file:line (for inline comments), who raised it, and what it asks for. Order by how much it blocks merge:
CHANGES_REQUESTED, correctness/security concerns, "this must change before merge."Don't pad the list. Merge duplicate threads that ask for the same thing. Drop resolved/outdated threads.
PR #<n> — <title> (<review state: changes requested / approved / open>)
Blocking (N):
- file:line — <ask> (@reviewer)
Should address (N):
- file:line — <ask> (@reviewer)
Optional / nits (N):
- file:line — <ask> (@reviewer)
Open questions (still need an answer):
- <question> (@reviewer)
End with a one-line read: is this PR blocked, and on what.
To act on the list, hand it to the fix-vs-defer policy — fix the blocking and should-address items inline, decide the nits.
Mark the current uncommitted state as reviewed by updating the review sentinel. Use when you've manually reviewed the substance of your changes and want to commit without running the full /review-cycle:review cycle. Per-state escape hatch, lighter than the project-wide .claude/.no-review-gate opt-out marker.
Run the full automated code review cycle on uncommitted changes. First brings the tree to the project's canonical state (its own format/lint/typecheck). Fans out Codex and the auto-fix reviewers (code quality, tests, error handling, type design) in parallel, applies fixes inline per the embedded policies, and loops up to 4 iterations until clean. Then, once against the final state, runs the report-only reviewers (structural maintainability and spec conformance) and a de-slopify cleanup pass. Updates the review sentinel on completion. Does NOT commit.
Drive a pull request's CI checks to green — watch the check set, diagnose the root failure, apply the smallest fix, route it through review, then commit and push; repeat until green. Use when the user asks to "fix CI", "get the checks green", "loop on CI", or "the PR build is failing".
Resolve merge or rebase conflicts with minimal, correctness-first edits, regenerate lockfiles with tooling, validate the build, and stage the result. Use when the user asks to "fix merge conflicts", "resolve conflicts", or after a merge/rebase leaves the tree conflicted.
Make a pull request easy to review without changing its behavior — a TL;DR that matches the diff, core files separated from generated ones, risks called out, and (only with approval) cleaner commit history. Use when the user asks to "make this easy to review", "tidy this PR", "clean up the commits", or "annotate the diff".
One-time setup for review-cycle. Verifies Codex CLI and multi_agent config, optionally appends comment + fix-vs-defer policies to CLAUDE.md (global or project), and updates .gitignore to exclude per-project sentinel files. Idempotent — safe to run multiple times.