Get the FREE Ultimate OpenClaw Setup Guide →

gh-address-pr-comments

Scanned
npx machina-cli add skill saadjs/agent-skills/gh-address-pr-comments --openclaw
Files (1)
SKILL.md
5.9 KB

GH Address PR Comments

Goal

Resolve actionable PR feedback end-to-end with evidence:

  1. Fetch all PR comments with gh.
  2. Prove meaningful comments with failing regression tests.
  3. Apply minimal fixes.
  4. Run the full test suite.
  5. Commit and push updates.
  6. Post reply comments describing what was fixed in the latest commit(s).
  7. 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

  1. Verify GitHub auth:
    • gh auth status
  2. Ensure a clean working tree before checkout:
    • git status -sb
  3. Check out the PR branch:
    • gh pr checkout "$PR_NUMBER" ${REPO:+--repo "$REPO"}

Workflow

  1. 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
  2. Build a comment checklist.

    • Normalize each comment into:
      • id
      • author
      • location (file/line if present)
      • request (one-sentence requested change)
      • classification (meaningful or not-meaningful)
    • Classify as meaningful only when the comment identifies a verifiable defect, regression risk, missing test, or concrete requirement mismatch.
    • Classify as not-meaningful when the comment is subjective, unclear, duplicate, or contradicted by code/tests.
  3. 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.
  4. 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.
  5. 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.
  6. 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 (or git push -u origin HEAD when no upstream exists)
  7. 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 includes pulls/$PR_NUMBER/comments/<comment_id>/replies and that REPO is owner/name.
    • 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>'
    • 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.
  8. 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>
    • 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).
  9. 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)

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.

Source

git clone https://github.com/saadjs/agent-skills/blob/main/skills/gh-address-pr-comments/SKILL.mdView on GitHub

Overview

gh-address-pr-comments resolves actionable PR feedback end-to-end using the gh CLI. It fetches all comments, classifies them as meaningful or not, adds regression tests for meaningful items, applies minimal fixes, runs the tests, commits, pushes, and posts reply updates to reviewers.

How This Skill Works

The skill uses gh pr view and gh api to gather PR comments, then normalizes each comment into a checklist item with id, author, location, request, and classification. It marks comments as meaningful only when they point to a verifiable defect, regression risk, missing test, or concrete requirement mismatch, and not-meaningful otherwise. It adds regression tests for meaningful items, applies minimal fixes, re-runs targeted tests until they pass, runs the full test suite, commits with a focused message, pushes the branch, and posts replies describing the fixes back to the PR.

When to Use It

  • You have a PR number and want to fetch all PR comments and metadata to start review.
  • You need to determine which comments are actionable and require code changes.
  • You want to add regression tests for meaningful comments before implementing fixes.
  • You must run the full test suite after applying fixes to ensure nothing regressed.
  • You want to post reply updates on the PR describing fixes and push evidence to reviewers.

Quick Start

  1. Step 1: Provide PR_NUMBER and optionally REPO to set the PR context.
  2. Step 2: Run the gh-address-pr-comments workflow to fetch, classify, test, fix, and push.
  3. Step 3: Review the generated PR replies and the pushed commits for traceability.

Best Practices

  • Verify GitHub auth is active and the working tree is clean before starting.
  • Normalize every comment into id, author, location, request, and classification.
  • Classify comments as meaningful only if they reveal a verifiable defect, regression risk, missing test, or concrete requirement mismatch.
  • Keep fixes minimal and targeted to the checklist item; avoid unnecessary refactors.
  • Commit with focused messages that reference the PR and comments, push, and include a summary in PR replies.

Example Use Cases

  • PR 123: fetch comments, identify a missing regression test for a bug in calc function, add the test, implement the fix, run narrow tests, then run the full suite and push.
  • Inline edge-case feedback is judged meaningful, a regression test is added for the edge-case, and a minimal fix is applied.
  • A duplicate or unclear comment is classified as not-meaningful and skipped from the fix flow.
  • If no failing test can be produced, reclassify the comment as not-meaningful or document why a test is not feasible.
  • After pushing, a reply is posted on the PR summarizing the changes and linking to the latest commits.

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers