gh-address-pr-comments
Address GitHub Pull Request feedback with the gh CLI. Use when a user provides a PR number and asks to fetch comments, verify which comments are meaningful, add regression tests, implement fixes, run all tests, and push the branch.
GH Address PR Comments
Goal
Resolve actionable PR feedback end-to-end with evidence:
- Fetch all PR comments with
gh. - Prove meaningful comments with failing regression tests.
- Apply minimal fixes.
- Run the full test suite.
- Commit and push updates.
- Post reply comments describing what was fixed in the latest commit(s).
- Re-request review from the original reviewer(s).
Required Input
PR_NUMBER(required)REPO(optional; format:owner/name)
If REPO is missing, infer it with:
REPO="$(gh repo view --json nameWithOwner -q .nameWithOwner)"
Preconditions
- Verify GitHub auth:
gh auth status
- Ensure a clean working tree before checkout:
git status -sb
- Check out the PR branch:
gh pr checkout "$PR_NUMBER" ${REPO:+--repo "$REPO"}
Workflow
-
Fetch comment sources with
gh.- PR metadata and review summaries:
gh pr view "$PR_NUMBER" ${REPO:+--repo "$REPO"} --json number,title,url,headRefName,baseRefName,comments,reviews
- Inline code review comments:
gh api "repos/$REPO/pulls/$PR_NUMBER/comments?per_page=100" --paginate
- Issue-level PR comments:
gh api "repos/$REPO/issues/$PR_NUMBER/comments?per_page=100" --paginate
- PR metadata and review summaries:
-
Build a comment checklist.
- Normalize each comment into:
idauthorlocation(file/line if present)request(one-sentence requested change)classification(meaningfulornot-meaningful)
- Classify as
meaningfulonly when the comment identifies a verifiable defect, regression risk, missing test, or concrete requirement mismatch. - Classify as
not-meaningfulwhen the comment is subjective, unclear, duplicate, or contradicted by code/tests.
- Normalize each comment into:
-
Add regression tests before code fixes for meaningful comments.
- Convert each meaningful comment into an expected behavior statement.
- Add or update the smallest possible test that should fail before the fix.
- Run a narrow test command to confirm failure.
- If no failing test can be produced, re-check classification:
- Downgrade to
not-meaningful, or - Keep as meaningful only when the change is non-testable by nature (for example docs wording), and record why.
- Downgrade to
-
Implement fixes.
- Apply minimal, targeted code changes tied to checklist items.
- Avoid unrelated refactors.
- Re-run the narrow tests after each fix until they pass.
-
Run the full test suite.
- Use the repository standard test command(s).
- If multiple standard suites exist (for example backend + frontend), run all of them.
- Do not continue to commit/push with failing tests.
-
Commit and push.
- Review final diff for comment-to-change traceability.
- Commit with focused message(s), for example:
fix(pr-123): address review comments with regression coverage
- Push branch updates:
git push(orgit push -u origin HEADwhen no upstream exists)
-
Post GitHub reply comments after push.
- Capture latest pushed commits for reference links, for example:
gh pr view "$PR_NUMBER" ${REPO:+--repo "$REPO"} --json commits -q '.commits[].oid'
- For each meaningful addressed comment, post a reply on the same thread when possible:
- Inline review comment reply:
gh api -X POST "repos/$REPO/pulls/$PR_NUMBER/comments/<comment_id>/replies" -f body='<reply>'- If this returns
404, verify the endpoint includespulls/$PR_NUMBER/comments/<comment_id>/repliesand thatREPOisowner/name.
- Inline review comment reply:
- For issue-level PR comments (no inline thread), post a new issue comment that references the original comment URL:
- Prefer:
gh pr comment "$PR_NUMBER" ${REPO:+--repo "$REPO"} --body '<reply>'
- Or API form:
gh api -X POST "repos/$REPO/issues/$PR_NUMBER/comments" -f body='<reply>'
- Prefer:
- Reply body requirements:
- Start with what changed to address the concern.
- Include the latest commit SHA(s) that contain the fix.
- Mention test evidence when applicable.
- Example reply:
Fixed by validating empty payloads in request parsing and adding regression coverage in api/request_parser_test.go. Included in commits abc1234 and def5678; full test suite now passes.
- Capture latest pushed commits for reference links, for example:
-
Re-request review.
- Identify who to re-request from (example: unique review authors):
gh pr view "$PR_NUMBER" ${REPO:+--repo "$REPO"} --json reviews -q '.reviews[].author.login' | sort -u
- Prefer native re-request mechanisms when available:
- Request review again from a GitHub user:
gh pr edit "$PR_NUMBER" ${REPO:+--repo "$REPO"} --add-reviewer <login>
- Request review again from a GitHub user:
- For bot/agent reviewers that use comment-driven triggers, post the trigger comment (example):
gh pr comment "$PR_NUMBER" ${REPO:+--repo "$REPO"} --body '@codex review'
- Guardrail: only ping re-review after fixes are pushed and reply threads are updated (or explicitly skipped with reason).
- Identify who to re-request from (example: unique review authors):
-
Report completion.
- Summarize:
- meaningful comments addressed
- comments rejected as non-meaningful (with brief rationale)
- regression tests added
- full-suite test result
- pushed branch name
- reply comments posted (count and any skipped with reason)
- re-review requested (who was pinged and how)
- Summarize:
Guardrails
- Do not apply comment requests blindly.
- Do not mark a meaningful code comment as resolved without either:
- a regression test that failed before the fix and passes after, or
- a short explicit reason why the comment is non-testable.
- Do not push if the full suite fails.
- Do not finish after push until comment replies are posted (or explicitly skipped with reason).
- Keep changes scoped to comment resolution.