Code Review Feedback Handler

Handle GitHub PR review feedback systematically: fetch comments, plan responses, make code changes, and reply to reviewers — all with explicit user approval at each stage.

Prerequisites

• You must be in a git repository with a GitHub remote
• The gh CLI must be authenticated (gh auth status)
• The branch for the PR should be checked out locally

Workflow

Phase 1: Identify the PR

If the user provided a PR URL, extract the owner, repo, and PR number from it.

If no URL was provided, detect the PR from the current branch:

gh pr view --json number,url,title,headRefName

If no PR is found for the current branch, stop and tell the user — you cannot proceed without a PR.

Phase 2: Fetch all feedback

Gather all three sources of PR feedback: inline review threads, review-body comments, and PR-level issue comments.

Inline review threads + review-body comments (single GraphQL call)

gh api graphql -f query='
query($owner: String!, $repo: String!, $number: Int!) {
  repository(owner: $owner, name: $repo) {
    pullRequest(number: $number) {
      reviewThreads(first: 100) {
        nodes {
          id
          isResolved
          isOutdated
          path
          line
          comments(first: 50) {
            nodes {
              id
              databaseId
              author { login }
              body
              path
              line
              startLine
              createdAt
              url
            }
          }
        }
      }
      reviews(first: 50) {
        nodes {
          id
          databaseId
          author { login }
          body
          state
          createdAt
          url
        }
      }
    }
  }
}' -f owner=OWNER -f repo=REPO -F number=NUMBER

Review bodies are a distinct feedback source — reviewers often put feedback in the top-level review body rather than on specific lines. Parse each review body to extract individual actionable items and treat each separately in Phase 3.

PR-level comments

gh pr view NUMBER --json comments --jq '.comments[] | {author: .author.login, body: .body, createdAt: .createdAt, url: .url}'

PR diff (for context when reading feedback)

gh pr diff NUMBER

Phase 3: Filter and categorize

Skip already-resolved threads

Filter out threads where isResolved is true. This is critical for subsequent runs — some feedback may have already been handled.

Exclude outdated/stale comments

Filter out threads where isOutdated is true. Mention how many were excluded (e.g. "Excluded 3 outdated threads where the referenced code has since changed").

Filter review-body comments

Skip review bodies that are empty, contain only a summary with no actionable feedback, or are in DISMISSED state.

For reviews with actionable items, parse the body to extract individual feedback items. Each extracted item should carry:

• The review author and whether they're a bot
• The review id, databaseId, and url (needed for replies in Phase 8)
• The extracted feedback text
• Any file path or line reference mentioned in the text (for grouping in Phase 4)

Identify reviewer type

• AI/bot reviewers: Author login ends with [bot] (e.g. coderabbitai[bot]).
• Human reviewers: All others — responses should be thoughtful.

Categorize feedback by severity

Assign each item one of: Blocking / change request, Suggestion, Nitpick / minor (labeled "nit:", "minor:", etc.), Question, or Praise / informational. Use the review state (CHANGES_REQUESTED) and language cues to determine weight. Blocking items should almost always be actioned; nitpicks only if low-effort and genuinely beneficial.

Phase 4: Present the plan

Before making ANY changes or posting ANYTHING to GitHub, present a structured plan to the user. Group by file when it makes sense.

For each piece of actionable feedback, include:

1. Source: Who left it (note if bot or human), with a link to the comment
2. Category: Blocking, suggestion, nitpick, question, etc.
3. Summary: What the reviewer is asking for
4. Proposed action — one of:
   • Will fix: Describe the code change
   • Push back: Explain why you disagree and draft the reply
   • Clarify: Draft a reply answering the question
   • Acknowledge: Brief response to praise or informational comments
5. Draft reply (if posting one): The exact text, which MUST start with [posted by agent]

If multiple pieces of feedback conflict with each other, flag the conflict to the user.

Phase 5: Iterate on the plan with the user

The user will review your plan. They may approve it as-is, ask you to change how you handle specific items, or discuss trade-offs. Update the plan based on their input and re-present if needed. Do NOT proceed until the user explicitly gives the go-ahead.

Phase 6: Make code changes

Implement all approved code changes.

Rules for this phase:

• Do NOT commit anything. The user will review and commit themselves.
• Do NOT post anything to GitHub yet.
• Do NOT resolve any threads yet.

When done, summarize what was changed and tell the user the code is ready for their review. Iterate until they're satisfied.

Phase 7: Get final go-ahead for GitHub actions

Once the user confirms they're happy with the code changes and are about to commit, ask for explicit confirmation to post replies and resolve threads on GitHub.

Do NOT post or resolve anything until this second confirmation.

Phase 8: Post to GitHub and resolve threads

Execute the approved GitHub actions.

Reply to an inline review comment

gh api repos/OWNER/REPO/pulls/NUMBER/comments/COMMENT_ID/replies -f body="[posted by agent] Your reply here"

Use the databaseId from the GraphQL response as the COMMENT_ID for this REST endpoint.

Reply to review-body feedback

There is no direct "reply to review body" API. Post a PR-level comment that references the review, including a link so readers can trace context. If the review body contained multiple actionable items, batch all responses into a single comment with each item addressed under its own heading or quote block.

gh pr comment NUMBER --body "[posted by agent] Responding to [AUTHOR's review](REVIEW_URL):

Your reply here"

Post a PR-level comment

gh pr comment NUMBER --body "[posted by agent] Your reply here"

Resolve a thread

gh api graphql -f query='
mutation($threadId: ID!) {
  resolveReviewThread(input: {threadId: $threadId}) {
    thread { isResolved }
  }
}' -f threadId=THREAD_ID

Use the thread id from the Phase 2 GraphQL response as THREAD_ID.

Resolution rules

• Fixed straight up: Resolve the thread. No need to also leave a comment — the fix speaks for itself.
• Pushed back: Do NOT resolve. Leave it open so the reviewer can read the response and continue discussion.
• Clarified: Do NOT resolve. Let the reviewer confirm they're satisfied.
• Acknowledged / skipped: Use judgment — resolve if nothing more to discuss.

Every GitHub post MUST begin with [posted by agent]

This is non-negotiable. It must be clear to anyone reading the PR that the comment was written by an AI agent, not the user directly.

Subsequent runs

The user may invoke this skill multiple times as new feedback rounds arrive. On subsequent runs:

• Already-resolved threads are automatically filtered out in Phase 3
• Focus only on new and unresolved comments
• The user may tell you what was already handled — take that into account
• Treat it as a fresh cycle through the same phases

Error handling

• If gh is not authenticated: tell the user to run gh auth login
• If no PR is found for the current branch: stop and ask the user to provide the URL or check they're on the right branch
• If the GraphQL query fails: fall back to gh api repos/OWNER/REPO/pulls/NUMBER/comments (note: this won't include thread resolution status, so warn the user)
• If a reply or resolve action fails: report the error and continue with remaining actions