← ClaudeAtlas

pr-addresslisted

Address PR review comments and loop until CI green and all comments resolved. TRIGGER when user asks to address comments, fix PR feedback, respond to reviewers, or babysit/monitor a PR.
HIDORAKAI002/ai-workspace-archive · ★ 31 · AI & Automation · score 78
Install: claude install-skill HIDORAKAI002/ai-workspace-archive
# PR Address ## Find the PR ```bash gh pr list --head $(git branch --show-current) --repo Significant-Gravitas/AutoGPT gh pr view {N} ``` ## Read the PR description Understand the **Why / What / How** before addressing comments — you need context to make good fixes: ```bash gh pr view {N} --json body --jq '.body' ``` > If GraphQL is rate-limited, `gh pr view` fails. See [GitHub rate limits](#github-rate-limits) for REST fallbacks. ## Fetch comments (all sources) ### 1. Inline review threads — GraphQL (primary source of actionable items) > ⚠️ **WARNING — PAGINATE ALL PAGES BEFORE ADDRESSING ANYTHING** > > `reviewThreads(first: 100)` returns at most 100 threads per page AND returns threads **oldest-first**. On a PR with many review cycles (e.g. 373 threads), the oldest 100–200 threads are from past cycles and are **all already resolved**. Filtering client-side with `select(.isResolved == false)` on page 1 therefore yields **0 results** — even though pages 2–4 contain many unresolved threads from recent review cycles. > > **This is the most common failure mode:** agent fetches page 1, sees 0 unresolved after filtering, stops pagination, reports "done" — while hundreds of unresolved threads sit on later pages. > > One observed PR had 142 total threads: page 1 returned 0 unresolved (all old/resolved), while pages 2–3 had 111 unresolved. Another with 373 threads across 4 pages also had page 1 entirely resolved. > > **The rule: ALWAYS paginate to `hasNextPage == false` rega