PR Review Response

Context

When an agent fixes code in response to PR review comments (from Copilot, a human reviewer, or any GitHub reviewer), the fix alone is not enough. The reviewer needs to see — on the PR thread itself — which comments were addressed and how. Without replies, comments stay visually unresolved, reviewers must re-read the entire diff to verify fixes, and there's no traceable link between feedback and resolution.

Use this skill whenever:

• You are fixing code based on PR review feedback
• You are addressing Copilot review suggestions
• You are responding to reviewer-requested changes on a PR
• A squad member hands you review comments to resolve

SCOPE

✅ THIS SKILL PRODUCES:

• Reply comments on each review thread explaining the fix
• Optionally resolved threads (via GraphQL when appropriate)
• Commit messages that reference the PR and review context

❌ THIS SKILL DOES NOT PRODUCE:

• The code fixes themselves (that's the agent's domain work)
• New review comments or reviews
• PR descriptions or summaries

Patterns

Step 1: Read the review comments

Using MCP tools (preferred when available):

github-mcp-server-pull_request_read
  method: "get_review_comments"
  owner: "{owner}"
  repo: "{repo}"
  pullNumber: {pr_number}

This returns review threads with metadata: isResolved, isOutdated, isCollapsed, and their associated comments. Each comment has an id you'll need for replies.

Using gh CLI (fallback):

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --paginate

Each comment object contains id, body, path, line, and in_reply_to_id. Top-level comments have no in_reply_to_id — those are the ones you reply to.

Step 2: Fix the code

Make the actual code changes. This is your normal domain work — the skill doesn't prescribe how to fix, only how to communicate the fix.

Track what you changed. For each review comment, note:

• The comment id (top-level, not a reply)
• The file and line referenced
• What you actually changed (brief description)
• The commit SHA after pushing (if available)

Step 3: Reply to each review thread

After fixing and committing, reply to each review comment thread individually.

REST API call (via gh CLI):

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies \
  -f body="Fixed in {sha_short} — {brief description of what was changed}"

Important: {comment_id} must be the ID of the top-level comment in the thread. You cannot reply to a reply — only to the original review comment.

Example replies:

# Specific and traceable
gh api repos/bradygaster/squad/pulls/42/comments/18234/replies \
  -f body="Fixed in a1b2c3d — switched to path.dirname(squadDirInfo.path) for worktree consistency"

# When applying a suggested code change
gh api repos/bradygaster/squad/pulls/42/comments/18235/replies \
  -f body="Applied suggestion — updated error message to include the file path for debuggability"

# When pushing back on a suggestion
gh api repos/bradygaster/squad/pulls/42/comments/18236/replies \
  -f body="Considered but not applied — this path needs to stay absolute because worktree resolution depends on it. See detectSquadDir() in detect-squad-dir.ts."

Step 4: Resolve threads (optional, GraphQL only)

Thread resolution is only available via the GitHub GraphQL API. Use this when your fix fully addresses the comment and no further discussion is needed.

First, get the thread IDs (they're different from comment IDs):

gh api graphql -f query='
  query {
    repository(owner: "{owner}", name: "{repo}") {
      pullRequest(number: {pr_number}) {
        reviewThreads(first: 100) {
          nodes {
            id
            isResolved
            comments(first: 1) {
              nodes { body databaseId }
            }
          }
        }
      }
    }
  }
'

Match thread IDs to comment IDs using databaseId, then resolve:

gh api graphql -f query='
  mutation {
    resolveReviewThread(input: {threadId: "{thread_node_id}"}) {
      thread { id isResolved }
    }
  }
'

When to resolve vs. leave open:

• ✅ Resolve: You fixed exactly what was requested, no ambiguity
• ❌ Don't resolve: You pushed back, applied a different fix, or the comment needs further discussion
• ❌ Don't resolve: The reviewer is a human — let them confirm and resolve themselves

Rule of thumb: Agent-to-agent threads (e.g., Copilot review → agent fix) can be resolved by the fixer. Human reviewer threads should be left for the human to resolve.

Step 5: Commit message traceability

Commit messages should reference the PR context:

fix: address review feedback on PR #{pr_number}

- Switched to path.dirname() for worktree path resolution (comment #18234)
- Updated error message to include file path (comment #18235)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

For single-comment fixes, a shorter format works:

fix: use path.dirname() for worktree consistency (PR #{pr_number} review)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

AGENT WORKFLOW (Summary)

1. READ — Fetch review threads using MCP tool or gh api
2. FIX — Make code changes, tracking comment ID → change mapping
3. COMMIT — Push with traceable commit message referencing PR and comments
4. REPLY — Post individual reply to each thread via gh api .../replies
5. RESOLVE — (Optional) Resolve agent-to-agent threads via GraphQL
6. STOP — Do not batch-reply, do not skip threads, do not resolve human threads