Responding to Copilot Reviews

Contents

• Overview
• When to Use
• The Process
  • Step 1: Fetch Copilot Comments
  • Step 2: Spawn Subagents for Each Comment
  • Step 3: Collect Results and Make Decisions
  • Step 4: Fix in Separate Commits
  • Step 5: Reply to Each Review Comment
• Subagent Task
• Anti-patterns
• Tips

Overview

Structured workflow for responding to GitHub Copilot's automated code review comments on PRs. Key principle: critical evaluation - not all Copilot suggestions are valid.

When to Use

• PR has Copilot review comments to address
• Systematically evaluate automated review feedback
• Respond to multiple review comments on a PR

The Process

Step 1: Fetch Copilot Comments

Retrieve review comments with pagination, filtering to Copilot only:

gh api --paginate repos/{owner}/{repo}/pulls/{pr}/comments \
  | jq '[.[] | select(.in_reply_to_id == null and .user.login == "Copilot")]'

Filter criteria:

• in_reply_to_id == null - Skip already-replied comments (avoid re-replying)

Required fields from each comment:

• id - Comment ID (needed for Step 5 replies)
• path - File path
• line / original_line - Line number (may be null for outdated)
• diff_hunk - Code context (fallback when line is null)
• body - Comment content

Step 2: Spawn Subagents for Each Comment

For each comment, spawn a subagent in parallel using Task tool:

Task tool (subagent_type: "general-purpose", run_in_background: true)
prompt: |
  Evaluate this Copilot review comment:

  COMMENT_ID: {id}
  File: {path}
  Line: {line} (if null, use diff_hunk below)
  Diff Hunk: {diff_hunk}
  Comment: {body}

  1. Read the actual code at {path}
     - If line is valid: read around that line
     - If line is null: use diff_hunk to locate context
  2. Verify whether the suggestion is correct
  3. Use Codex to get a second opinion:
     codex exec "Is this suggestion valid? [comment]. Context: [code snippet]"
  4. Return verdict with COMMENT_ID preserved (required for reply)

CRITICAL:

• Launch all subagents in parallel (single message with multiple Task calls)
• Limit to 5-10 concurrent subagents to avoid rate limits
• Each subagent MUST return the COMMENT_ID in output

Step 3: Collect Results and Make Decisions

Wait for all subagents to complete, then create decision table with COMMENT_ID preserved:

Error handling: If a subagent fails or times out:

• Retry the evaluation manually for that comment
• Or mark as NEEDS_REVIEW and handle synchronously

Step 4: Fix in Separate Commits

For accepted suggestions, create commits:

jj new -m "style: address review comment - [description]"
# Apply fix(es)
jj git push

Commit strategy:

• Default: One commit per fix (easier to revert, clearer history)
• Exception: Batch fixes of the same type in one commit
• NEVER: Mix fixes into original commits

Step 5: Reply to Each Review Comment

Reply directly to the review comment (not as general PR comments):

For accepted suggestions:

gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies \
  -f body="✅ Fixed in commit {hash}"

For rejected suggestions:

gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies \
  -f body="❌ False positive. [reason]"

RULE: Always reply to review comments directly, not as issue comments.

Subagent Task

Each subagent evaluates ONE comment and must:

1. Read the code - Fetch the file and locate the referenced line
   • If line is null or outdated, use diff_hunk to find context
   • Search for unique strings from diff_hunk in the file
2. Understand context - Read surrounding code to understand intent
3. Verify suggestion - Is the Copilot suggestion technically correct?
4. Consult Codex - Get external opinion with codex exec
5. Return verdict - ACCEPT or REJECT with reasoning and COMMENT_ID preserved

Subagent output format:

VERDICT: ACCEPT | REJECT
COMMENT_ID: {id}
FILE: {path}
REASONING: {explanation}
FIX_SUGGESTION: {if ACCEPT, describe the fix}

Why subagents?

• Parallel processing for faster review
• Each comment gets focused attention
• Independent Codex consultations prevent bias
• Clear accountability per comment

Anti-patterns

Tips

• Never skip verification: Step 2 and Step 3 are mandatory - critical verification is the core principle
• Handle outdated comments: When line is null, use diff_hunk or original_line to locate context
• Document rejections well: Future reviewers benefit from clear reasoning
• Preserve COMMENT_ID throughout: Without IDs, you cannot reply to the correct comment in Step 5
• Use gh api over gh pr comment: Direct API gives more control over comment threading